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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 tsv-dir@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]