Subject: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 1 Dec 2008 01:52:06 +0000

I've reviewed this document as part of the transport area  
directorate's ongoing effort to review key IETF documents. These  
comments were written primarily for the transport area directors, but  
are copied to the document's authors for their information and to  
allow them to address any issues raised. The authors should consider  
this review together with any other last-call comments they receive.  
Please always CC [email-masked] if you reply to or forward this  
review.

In summary, this draft seems to be on the right track but has some  
open issues, as discussed below.

The NAT keep-alive interval (Section 5.3 and 7) is set to 110 seconds  
by default, unless configured by the home agent in a binding  
acknowledgement. While the default interval seems a safe choice, it's  
not clear why it was chosen, or when it's appropriate for a home  
agent to signal an alternative interval. The draft would benefit from  
an explanation of this choice, and further discussion of the issues  
inherent in choosing an appropriate keep-alive interval (Section 3.5  
of RFC 5405 considers this point, and might be appropriate to  
reference).

The NAT detection mechanism specified in Section 5.2 relies on the  
NAT rewriting the source address of the outer IPv4 header, but not  
the IPv4 address carried in the binding update payload. I'm not  
familiar with the way in which mobile IPv6 uses IPsec ESP, but if  
it's used in a way that provides integrity protection but not  
confidentiality, issues may arise with NAT devices that rewrite IPv4  
addresses in the UDP payload, causing the integrity check to fail  
(this is why STUN [RFC5389] provides an XOR-MAPPED-ADDRESS attribute  
to obfuscate the IP address).

It's not clear that the use with ECN is fully specified. Section  
5.1.1 notes that it's "RECOMMENDED that the ECN information is copied  
between the inner and outer header as defined in [RFC3168]" - is the  
intent that the full-functionality option defined in RFC 3168 is  
recommended? If so, it would be useful to state that explicitly. It  
also seems that UDP encapsulation will prevent the use of ECN over  
the tunnel, since the UDP API doesn't allow access to the ECN bits,  
and cause different ECN (and hence congestion) behaviour depending on  
the encapsulation method used. This should be called out in the draft.

Processing of other IP header fields (e.g. the diffserv field and  
TTL) when encapsulated in UDP tunnels also seems poorly defined. The  
intent, presumably, is for the choice of tunnelling mechanism to be  
hidden from higher-levels, but the exact en-/de-capsulation steps  
needed to achieve this must be specified for the UDP encapsulation.  
For example, when is the TTL of the encapsulated packet decremented?

Finally, the use of multiple UDP tunnelling schemes (vanilla or with  
TLV-header) seems undesirable, and it would be useful to document why  
this is necessary, for those not familiar with the working group  
history.

Regards,
-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Colin Perkins <[email-masked]>
Date: Mon, 1 Dec 2008 08:52:40 +0000

Hesham,

Thanks - one minor follow-up inline.
Colin

On 1 Dec 2008, at 08:29, Hesham Soliman wrote:
> Colin,
>
> Thank you for the review. Please see some comments inline.
>
>
> => Thanks for the reference. I'll include that in the new rev. The  
> interval was chosen based on recommendations from people with  
> experience in NAT deployments and the WG agreed with it. But the  
> reference will certainly help the reader.
>
> => Well, I'm not sure how a NAT can do that. You mean the NAT will  
> parse the binding update message deep inside the IPv6 extension  
> header in the inner IP packet? This is where the original address  
> is preserved. To do that, a NAT would have to understand the  
> various MIPv6 options, and if it did, it would know not to do  
> that :) The inner header is IPv6, so a NAT should not touch that.

My understanding from the STUN work is that NATs have been observed  
which rewrite any sequence of four aligned bytes matching the source  
IP address, irrespective of its location within the packet (section  
15.2 of RFC 5389).

>> recommended? If so, it would be useful to state that explicitly.
>
> => Yes. I think we can explicitly mention that. This was done to  
> follow the same rules which are done for IP in IP encapsulation, as  
> per RFC 4213.
>
> It
> => Ok, although I think this might not be an issue with many  
> implementations as UDP encapsulation may be done in the kernel with  
> the rest of the MIPv6 implementations (typically anyway). I'll add  
> your comment to the draft.
>
> => It is decremented in the same way that it's done for IP in IP  
> tunnelling. I can add that.
>
> => Well, I personally agree with you. However, there was a  
> concensus call in the WG about this particular issue and it was  
> decided (narrowly) that we should include support for this. Based  
> on my understanding, some people wanted to be able to efficiently  
> use GRE tunnelling. While this is not useful for MIPv6 mobile nodes  
> (typically GRE tunnelling is done in the network), people wanted to  
> be able to use this specification for PMIPv6, which uses MIPv6  
> without the mobile node's involvement. Hence, the supposed need for  
> GRE tunnelling. If you ask me why GRE tunnelling is needed at all  
> in IPv6 then I'm not the right person to represent that opinion  
> because I'm completely against it :)
> I hope this helps.
>
> Hesham
>