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(_at_)ietf(_dot_)org] On
Behalf Of The IESG
Sent: Thursday, January 02, 2014 10:14 AM
To: IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org mailing lists by 2014-01-16. Exceptionally, comments
may be sent to iesg(_at_)ietf(_dot_)org 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/