ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: [IPsec] FW: Last call comments for ROHCoIPsec: draft-ietf

[IPsec] FW: Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec

From: <Pasi.Eronen_at_nospam>
Date: Tue Sep 15 2009 - 18:03:54 GMT
To: <ipsec@ietf.org>


(Forwarding to IPSECME list, too. I would encourage other WG members to review these drafts and comment, too. -Pasi)

> -----Original Message-----
> From: Eronen Pasi (Nokia-NRC/Helsinki)
> Sent: 14 September, 2009 12:13
> To: ietf@ietf.org; 'rohc@ietf.org'
> Cc: 'ertekin_emre@bah.com'
> Subject: Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec,
> draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-
> extensions-hcoipsec
>
> I've reviewed the ROHCoIPsec draft set (not wearing any hats), and
> have couple of comments. Most important first:
>
> 1) None of the drafts really describe the reason why the ROHC ICV is
> included. It was not present in the early drafts, and was added after
> long and complex discussions. I would strongly encourage summarizing
> those discussions in one of the drafts -- otherwise, the reader cannot
> really figure out why the ROHC ICV is included (since the packets are
> already protected by the AH/ESP ICV), and what risks omitting the ROHC
> ICV might have.
>
> 2) ipsec-extensions, Section 3.3, doesn't really correctly describe
> the MTU-related processing in RFC 4301. The three cases refer to IPsec
> implementations that both process unprotected ICMP messages and
> actually receive them (they're often filtered in the network), and
> thus have a Path MTU estimate value. But an IPsec implementation that
> doesn't process (or receive) unprotected ICMP messages does not even
> have a Path MTU estimate value...
>
> 3) According to RFC 4224, ROHC segmentation does not work over
> reordering channels. Thus, it seems suggesting that ROHC segmentation
> could be used instead of pre-encryption fragmentation (e.g.
> ipsec-extensions, Section 3.3) -- and in general, allowing
> segmentation at all -- seems misguided (it's unnecessary complexity
> that would be IMHO best left out).
>
> 4) None of the drafts have any RFC 2119 keywords (MUST/SHOULD/etc).
> They SHOULD use those to make it less ambiguous what is the required
> behavior (and what is optional) to claim compliance with these drafts.
>
> 5) In ikev2-extensions, Section 2.1.2 it is not very clear which of
> the attributes are just one-way notifications (the sender of the
> attribute tells the other end what it can handle), and which are
> negotiated (the initiator tells the other end what it supports; the
> responder then selects one, and tells what it selected).
>
> I would suggest adding text like "Note that different ATTRIBUTE_NAME
> value can be used in each direction" for those attributes that are
> just one-way (I think at least MAX_CID, ROHC_PROFILE -- for MRRU and
> ROHC_ICV_LEN, I don't know which way they're supposed to work).
>
> 6) ikev2-extensions, Section 2.1.2, says "The key for this Integrity
> Algorithm is computed using the same method as is used to compute
> IPsec's Integrity Algorithm key ([IKEV2], Section 2.17)." I don't
> think this is sufficient to get interoperable implementations; more
> details are needed.
>
> In addition, there's couple of places that probably need some
> clarifications and/or minor fixes:
>
> 7) ikev2-extensions, Section 2.1.2, ROHC_ICV_LEN: The text talks about
> "announcing their preference"; how is the actual ICV length determined
> from these preferences?
>
> 8) ikev2-extensions, Section 2.1.2, ROHC_INTEG: Should also describe
> what happens if the responder doesn't accept any of the algorithms
> proposed by the initiator (not doing ROHC at all would be one obvious
> alternative; NO_PROPOSAL_CHOSEN another).
>
> 9) ikev2-extensions, Section 2.1.1, says "The most significant bit in
> the
> field is the Attribute Format (AF) bit." No, according to Figure 2
> "AF" is a separate field, not part of the "ROHC Attribute Type" field.
>
> 10) ipsec-extensions, Section 3.2, says "The authentication data must
> not be included in the calculation of the ICV." This is very vague,
> considering that we have several different authentication data/ICVs
> here. Is the intent to say "The ROHC ICV field is not included in the
> calculation of the ROHC ICV", or something else?
>
> 11) ikev2-extensions, Section 4: "6-65536 Unassigned" should be
> "6-32767 Unassigned".
>
> Best regards,
> Pasi



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec