Re: ´ð¸´: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Xuxiaohu writes:
 
> Hi all,
>  
> Thanks a lot for your comments.
>  
> I wonder whether the following text is OK to you:
>  
>    Since the MPLS-in-UDP encapsulation causes MPLS packets to be
>    forwarded through "UDP tunnels", the congestion control guidelines
>    for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be
>    followed. Specifically, MPLS can carry a number of different
>    protocols as payloads. When an UDP tunnel is used for MPLS payload
>    traffic that is known at configuration time to be IP-based and
>    congestion-controlled, the UDP tunnel SHOULD NOT employ its own
>    congestion control mechanism, because congestion losses of tunneled
>    traffic will trigger an congestion response at the original senders
>    of the tunneled traffic. When an UDP tunnel is used for MPLS
>    payload traffic that is known at configuration time not to be
>    IP-based and congestion-controlled, the UDP tunnel SHOULD employ an
>    appropriate congestion control mechanism as described in
>    [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such
>    encapsulation technology only within a SP network or networks of an
>    adjacent set of co-operating SPs, rather than over the
>    Internet. Furthermore, packet filters should be added to block
>    traffic with the UDP port number for MPLS over UDP to prevent MPLS
>    over UDP packets to escape from the service provider networks due
>    to misconfiguation or packet errors.
>  
> Best regards,
> Xiaohu

Xiaohu,

Looks good.

A few nits:

s/an congestion response/a congestion response/

s/Note that it STRONGLY RECOMMENDED/Note that it is STRONGLY RECOMMENDED/

s/to deploy such encapsulation technology
 /that such encapsulation technology be deployed/

s/UDP packets to escape from/UDP packets from escaping/

I suggest that you also add a paragraph saying that UDP checksums
SHOULD be used in all cases where it is feasible to do so.  Try to
capture the reasoning behind the tsvwg recommendations that UDP
checksums be used whenever it is possible to do so.  You can
optionally add wording from past email outlining the known cases where
adding UDP checksums are infeasible (such as cut-through routing).

thanks.

Curtis


> > -----ÓʼþÔ­¼þ-----
> > ·¢¼þÈË: mpls [mailto:[e-mail]] ´ú±í Eggert, Lars
> > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 15:52
> > ÊÕ¼þÈË: [e-mail]
> > ³­ËÍ: Joel Jaeggli; [e-mail]
> > Ö÷Ìâ: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
> > in UDP) to Proposed Standard
> > 
> > This is not at all the argument I am making. My emails have not touched at all
> > on the issue of zero checksums.
> > 
> > My point is that UDP encapsulation changes the potential *reach* of
> > congestion-uncontrolled traffic that was otherwise limited to L2 networks.
> > 
> > Lars
> > 
> > On 2014-1-21, at 21:14, Curtis Villamizar <[e-mail]> wrote:
> > 
> > >
> > > In message <[e-mail]>
> > > "Eggert, Lars" writes:
> > >
> > >> Hi,
> > >>
> > >> On 2014-1-21, at 12:50, Stewart Bryant <[e-mail]> wrote:
> > >>> In terms of congestion and misdelivery it is interesting looking at
> > >>> the number of horses that are already bounding around in the paddock
> > >>> outside the stable:
> > >>>
> > >>> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> > >>
> > >> there is a big difference between encapsulation in IP and
> > >> encapsulation in UDP. Everything encapsulated with "obscure" IP
> > >> protocol numbers will get dropped by default at NATs and firewalls,
> > >> whereas UDO traffic happily traverses them. The reach of UDP traffic
> > >> is much broader.
> > >>
> > >> Lars
> > >
> > >
> > > Stray UDP packets carrying MPLS getting to grandma's firewall is
> > > really stretching the argument but ...
> > >
> > > When encapsulating in UDP, the UDP checksum might be zero but the IP
> > > checksum can still be filled in so the IP destination is checked and
> > > grandma need not worry about these packets.  But ...
> > >
> > > Grandma's firewall would block since there is no state established on
> > > the firewall with the opposite port pair pattern.  But ...
> > >
> > > Even if it went through when the packet reached grandma's subnet the
> > > payload is junk bound to an unused port.  Maybe it hits grandma's DNS
> > > server and is interpreted as a badly malformed DNS request.
> > >
> > > So grandma seems safe from these bad packets.
> > >
> > > Lack of UDP checksum should at worst mean that the destination gets a
> > > packet with a munged payload, pulls off the IP and UDP headers and
> > > continues to forward.  At worst has the wrong MPLS label and gets
> > > blackholed in the provider network somewhere.  If it ends up at the
> > > correct MPLS egress, if IP, the IP checksum is checked.  If a TCP or
> > > UDP payload carried in that IP got munged the packet could end up at
> > > the destination with a bad TCP or UDP checksum and get dropped.
> > >
> > > Curtis