Hi,
Here are a few comments/feedback on the draft:
1. Section 3. Encapsulation in UDP
I'd like to see the source port allocation requirements stated in a more explicit manner. The draft seems to imply the udp source port should vary on a per-flow basis in order to achieve the load-
sharing goal, so maybe we can state exactly that? ie., I would prefer the following sentence to read:
Source Port of UDP
This field contains a 16-bit entropy value that is
generated by the ingress PE router to uniquely identify
an MPLS flow. What algorithm...
2. Section 6 Security Considerations
For the security aspects, I'd like to see a better problem description. To me the problem is not so much of how to address integrity and privacy for MPLS-over-UDP, but rather what _new_ problem is introduced with MPLS-over-UDP that native mpls or other mpls encapsulation solutions doesn't have. In other words, is integrity/privacy a bigger problem for mpls-over-udp than plain mpls,
and why? or how the solution makes security an easier or harder problem? On the surface, the security concern should be no more or less than what's already stated in RFC-4023 (MPLS in IP or GRE).
3. I think the IPSec vs. DTLS discussion can use a bit more clarity without going into too much protocol discussion between the two. I would suggest the following change in the text:
====
In the case where any of the above security issues is concerned, the MPLS-in-UDP tunnels SHOULD be secured with IPsec or DTLS. Both protocols should satisfy the authentication, integrity, and confidentiality security requirements. IPSec was designed as network security mechanism for Internet Protocols, and therefore resides at the network layer. As such, if the tunnel is secured with IPsec, the UDP header would not be visible to P routers anymore in either IPSec tunnel or transport mode. As a result, the meaning of adopting MPLS-in-UDP encapsulation format as an alternative to MPLS-in-GRE and MPLS-in-IP encapsulation formats is lost. By comparison, DTLS is better suited for application security and can better preserve network and transport layer protocol information.
Specifically, if DTLS is used, the destination port of the UDP header will be filled with a value (TBD2) indicating MPLS with DTLS and the source port can still be used as an entropy field for load sharing purposes.
====
Thanks,
Wen
-----Original Message-----
From: IETF-Announce [mailto:ietf-announce-bounces@xxxxxxxx] On Behalf Of The IESG
Sent: Thursday, January 02, 2014 10:14 AM
To: IETF-Announce
Cc: mpls@xxxxxxxx
Subject: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Encapsulating MPLS in UDP'
<draft-ietf-mpls-in-udp-04.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxx mailing lists by 2014-01-16. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting.
Abstract
This document specifies an IP-based encapsulation for MPLS, called
MPLS-in-UDP (User Datagram Protocol).
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ballot/
The following IPR Declarations may be related to this I-D:
http://datatracker.ietf.org/ipr/1941/
http://datatracker.ietf.org/ipr/2198/