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]>
"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