Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-in-udp-10: (with DISCUSS)

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Jan 2015 17:49:45 -0000

Hi Martin,

Speaking as a contributor to this I-D and recused...

I think you have a valid point, but the details are a bit wrong.

> The UDP source port is randomly chosen and I guess not further retained
> (*) for receiving incoming MPLS-over-UDP packets. In turn this means that
> "returning" packets are sent to the MPLS/UDP port number.
> 
> (*) nobody is listening on that UDP port.

I think this is no different from when the port is assigned through entropy. That is, a source port is assigned for use on the outward flow with no assumption that returning packets will use the same port number as the destination port. Indeed, the destination port is always "MPLS" on traffic flowing in both directions.

This might require "knowledge" to be configured into a firewall if it finds itself in the path.

> This will cause issues when NATs/firewalls are in-between, as the return
> traffic, i.e., the traffic incoming from the public part of the NAT, is
> not matching any NAT binding that was created before by an outgoing
> packet. Similar for firewalls as no state was created when the packet
> traversed the firewall.
> 
> NATs are probably not a big issue in a carrier net, but firewalls will
> for sure. I guess this should be mentioned as an operational note.

If you think a warning should be added, that is pretty simple to do (and possibly gels with the warning about zero checksum).

(Is the addition of such a warning a Discuss? Who cares! We can add the note whatever :-)

Adrian

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 22 Jan 2015 17:41:25 +0100

Adrian,

We are on-track :)

I will clear when there is text.

   Martin

---

From: "Black, David" <[email-masked]>
Date: Mon, 26 Jan 2015 07:54:31 +0000

I just talked to Martin at the IAB SEMI workshop in Zurich.  The following
text addition to the start of Section 4 will suffice to resolve his Discuss
on the mpls-in-udp draft:

OLD
   This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded
   through "UDP tunnels".  When performing MPLS-in-UDP encapsulation by
   the encapsulator, the entropy value would be generated by the
   encapsulator and then be filled in the Source Port field of the UDP
   header.  The Destination Port field is set to a value (TBD1)
   allocated by IANA to indicate that the UDP tunnel payload is an MPLS
   packet.
NEW
   This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded
   through "UDP tunnels".  When performing MPLS-in-UDP encapsulation by
   the encapsulator, the entropy value would be generated by the
   encapsulator and then be filled in the Source Port field of the UDP
   header.  The Destination Port field is set to a value (TBD1)
   allocated by IANA to indicate that the UDP tunnel payload is an MPLS
   packet.  Each UDP tunnel is unidirectional, as MPLS-in-UDP traffic
   is sent to the IANA-allocated UDP Destination Port, and in particular,
   is never sent back to any port used as a UDP Source Port (which serves
   solely as a source of entropy).  This is at odds with a common
   middlebox (e.g., firewall) assumption that bidirectional traffic uses
   a common pair of UDP ports. As a result, arranging to
   pass bidirectional MPLS-in-UDP traffic through middleboxes may
   require separate configuration for each direction of traffic.

I would also add a paragraph break after this change.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> > > -----Original Message-----
> > > From: mpls [mailto:[email-masked]] On Behalf Of Martin Stiemerling
> > > Sent: Friday, January 23, 2015 12:41 AM
> > > To: [email-masked]; 'The IESG'
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-in-udp-10:
> > > (with DISCUSS)
> > >
> > > Adrian,
> > >
> > > We are on-track :)
> > >
> > > >> (*) for receiving incoming MPLS-over-UDP packets. In turn this means
> > > >> that "returning" packets are sent to the MPLS/UDP port number.
> > > >>
> > > > I think this is no different from when the port is assigned through entropy.
> > > That is, a source port is assigned for use on the outward flow with no
> > > assumption that returning packets will use the same port number as the
> > > destination port. Indeed, the destination port is always "MPLS" on traffic flowing
> > > in both directions.
> > > >
> > > >> This will cause issues when NATs/firewalls are in-between, as the
> > > >> return traffic, i.e., the traffic incoming from the public part of
> > > >> the NAT, is not matching any NAT binding that was created before by
> > > >> an outgoing packet. Similar for firewalls as no state was created
> > > >> when the packet traversed the firewall.
> > > >>
> > > >> NATs are probably not a big issue in a carrier net, but firewalls
> > > >> will for sure. I guess this should be mentioned as an operational note.
> > > >
> > > > If you think a warning should be added, that is pretty simple to do (and
> > > possibly gels with the warning about zero checksum).
> > > >
> > > _______________________________________________
> > > mpls mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls