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

[<[e-mail]>]

> 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

IPv6 doesn't have an IP header checksum. So with an error in the
header the packet can go anywhere.


> 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

... or a munged header, and forwards to a different application on a different port.

See RFC 6936 section 3, which goes through the scenarios -  but plays light
on the side-effects. My beef is with:

   A protocol or application that uses the zero UDP checksum method must
   ensure that the lack of checksum does not affect the protocol
   operation.  This includes being robust to receiving an unintended
   packet from another protocol or context following corruption of a
   destination or source address and/or port value.  It also includes
   considering the need for additional implicit protection mechanisms
   required when using the payload of a UDP packet received with a zero
   checksum.

Lack of a UDP checksum in one protocol can affect the operation of other
protocols minding their own business, until they receive and try to handle
a corrupted packet from the first protocol because port or address is
corrupted. There are a lot of applications that presume that the data they
are given is error-free, and they presume that rogue data is not injected into
their conversation.

I mean, if you're going to use a zero UDP checksum, and your application
messes up and gives itself corrupt data, fine. More fool you. By analogy
as a risk, it's like speeding while talking on a cellphone and crashing into a tree.
But if your lack of checksum means you affect other applications who have
to now protect themselves against your data, you're effectively now crashing
into and harming other people. They weren't in armoured cars to protect
against this? They had no right to be on the road!

Zero UDP checksums are hit-and-run accidents waiting to happen.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Curtis Villamizar [[e-mail]]
Sent: 21 January 2014 20:14
To: Eggert, Lars
Cc: Stewart Bryant; Wood L  Dr (Electronic Eng); [e-mail]; Joel Jaeggli; [e-mail]
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

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