I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-rohc-ipsec-extensions-hcoipsec-o6.txt
Reviewer: Elwyn Davies
Review Date: 11 December 2009
IESG Telechat date: 17 Dec 2009
Summary: Ready with the possible exception of two points.
- This document could be considered to be an update of RFC 4301 in that
it defines optional extensions to the SPD. An implementor of RFC 4301
would be interested to see such extensions whether or not they were
implemented and a 4301-bis might want to pull in the extensions. I
agreed with the authors when reviewing -05 that this was a policy matter
for the ADs/IESG.
- The additional text (regarding the suppression of segmentation when
there is no knowledge of Path MTU) that has been added to the end of
what is now s4.3 is the only reasonable response in an IP4 environment:
Under certain circumstances, IPsec implementations will not
process
(or receive) unprotected ICMP messages, or they will not have a
Path
MTU estimate value. In these cases, the IPsec implementation
SHOULD
NOT attempt to segment the ROHC-compressed packet, as it does not
have full insight into the path MTU in the unprotected domain.
I am less clear that this is right solution for an IPv6 environment. If
I understand correctly, the IPsec layer would know that the channel was
using IPv6. The IPsec layer could decide to assume the Minimum
Guaranteed MTU for IPv6. Presumably the IP layer would be no better
informed because of the suppression of ICMP messages or whatever, so
deferring fragmentation to the IP layer might be more inefficient than
assuming the minimum guarantee and doing segmentation at the IPsec layer
- I am not sufficiently deep into ROHC to know if this is true. Perhaps
a qualification for the IPv6 case is appropriate?
Apart from these two points my issues from -05 hae been addressed. The
significant changes resulting from the introduction of RFC 2119
requirements language appear to be good. (Oh, and I think I might have
had a mention in the acknowledgements).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
