Subject: [Gen-art] Gen-art review of draft-rohc-ipsec-extensions-hcoipsec-06.txt

From: Elwyn Davies <[email-masked]>
Date: Fri, 11 Dec 2009 10:28:52 +0000

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).

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 16 Dec 2009 12:51:15 +0000

Hi

<snipped agreed pieces>

First of all I see that Pasi has registered a COMMENT regarding the use
of segmentation at all so this discussion may be irrelevant.

Ertekin, Emre [USA] wrote:
> > >      NOT attempt to segment the ROHC-compressed packet, as it does
>
> > not
>
> > assuming the minimum guarantee and doing segmentation at the IPsec
>
> > layer
>
>  
>
> In certain cases, I agree.  However, in others (see below),
> segmentation to 1280 bytes might not be the best solution.
>
The point I was making is that if the IP layer on the source node can't
get any definite knowledge of a larger MTU it will fragment the packet
to 1280 octets anyway (because of how IPv6 is supposed to work) - it
doesn't have any choice whether or not there might be a low MTU tunnel
buried in the path.  Is it then better for the IPsec/ROHC to do the
segmentation?  Would this result in a more compact representation?  I am
not exactly sure if the cases you note where the IPsec layer doesn't
have positive information about the MTU also result in the IP layer not
knowing - I think the IP layer will alos be ignorant.

As Pasi says the actual use cases for ROHC may mean that relevant
packets aren't that big anyway so this may well be a tiny corner case.
>
>  
>
> > - I am not sufficiently deep into ROHC to know if this is true.
>
> > Perhaps
>
> Traditional ROHC is applied on a hop-by-hop basis; in these cases, the
> compressor and decompressor implementations have a pretty good
> understanding of the MTU for the ROHC channel. 
>
>  
>
> For ROHCoIPsec it is not straightforward, as the compression channel
> may be established across an arbitrary network.  So even if we are
> compressing IPv6 packets, this doesn't necessarily mean that the PMTU
> between compressor and decompressor is 1280. Take for instance the
> following scenario:
>
>  
>
> ---------------    ----------     ----------------------------   
>  ----------     ---------------
>
> | IPv6 IPsec  |----| Router |-----|arbitrary network cloud   |-----|
> Router |-----| IPv6 IPsec  |
>
> | Compressor  |    |        |     |    e.g., PMTU = 1100     |     |
>        |     | Decompressor|
>
> ---------------    ----------     ----------------------------    
> ----------     ---------------
>
>  
>
> The arbitrary network cloud might consist of IPv4 hops, where the MTU
> is less than 1280.  If the compressor initially segments the packet to
> 1280 bytes, this ROHCoIPsec segment is fragmented again in the core
> network (PMTU=1100).  Rather, in this case, it would've been better to
> leave the packet untouched initially, and only fragmented the packet
> within the core.
>
>  
>
> In certain situations though (e.g., if the network was pure IPv6, or
> if ROHCoIPsec was instantiated over a single hop), I agree that
> segmentation might be a better solution. 
>
>  
>
> In summary, because there is uncertainty about the PMTU, I would
> recommend that we leave this statement as SHOULD NOT.
>
In the IPv6 case the uncertainty is not there - it has to be assumed to
be 1280 octets in the absence of positive information to the contrary.

/Elwyn