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

From: Hesham Soliman <[email-masked]>
Date: Mon, 01 Dec 2008 19:29:02 +1100

Colin, 

Thank you for the review. Please see some comments inline.

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

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

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

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

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

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

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

> 
> 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?

=> It is decremented in the same way that it's done for IP in IP tunnelling.
I can add that. 

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

=> 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

> Regards,

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2008 21:51:08 +0200

Thanks for your review, Colin.

I agree that fixes or better explanations of the background should be 
given for the points that you raised. It seems that you and Hesham are 
making progress on what needs to be added to the document, great!

The only item that I too am somewhat worried about in your list is the 
address replacement by broken NATs and the tricks used to prevent that. 
I feel that the best way to deal with that is to document this as a 
potential problem -- the protocol already has tools to provide a far 
better obfuscation technique than XOR -- just turn on encryption if this 
turns out to be a problem and the device in question cannot be ripped 
out of the network. Do we have any information about how widespread such 
NATs might be? RFC 5389 just says "some NATs".

Jari

---

From: Colin Perkins <[email-masked]>
Date: Wed, 3 Dec 2008 09:42:44 +0000

On 2 Dec 2008, at 19:51, Jari Arkko wrote:
> I agree that fixes or better explanations of the background should  
> be given for the points that you raised. It seems that you and  
> Hesham are making progress on what needs to be added to the  
> document, great!
>
> The only item that I too am somewhat worried about in your list is  
> the address replacement by broken NATs and the tricks used to  
> prevent that. I feel that the best way to deal with that is to  
> document this as a potential problem -- the protocol already has  
> tools to provide a far better obfuscation technique than XOR --  
> just turn on encryption if this turns out to be a problem and the  
> device in question cannot be ripped out of the network.

Agreed.

> Do we have any information about how widespread such NATs might be?  
> RFC 5389 just says "some NATs".

Not really, but something that broken can't be common: it'd cause too  
many obvious problems.

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