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]>
[e-mail] writes:
 
>  
> > [Alia] Excellent - so if we can describe filtering on the correct
>   fields to enforce this constrained scope, then the concerns about
>   congestion control may be alleviated. 
>  
> For intended private use within a network, I think you'd be fine;as
> with congestion, crossing the public Internet poses more of a
> problem. I don't see how filtering comes in to enforce this. 


Minor clarification here:

The filtering is intended to reduce the possibility of an MPLS in UDP
in IPv6 packet from going out a provider LSR with a bad IPv6 address
and creating a high traffic accidental DoS attack on a random IPv6
address.

Blocking all traffic from the provider infrastructure prefix with MPLS
over UDP port number would accomplish this as long as the IPv6 source
address was not corrupted and outside the prefix or the destination
UDP port number was not corrupted.  So for example, all packets with a
single bit error that would otherwise exit the provider's
infrastructure would be blocked by the filter.

This is not intended to block a malicious user.  A malicious user
would not bother adding the MPLS encapsulation in the first place as
it does nothing to improve their throughput.

Additional suggestions:

We can also recommend that hosts and routers that are not primarily
intended to be used in a provider infrastructure not implement this
protocol.

Other than that the SHOULD implement congestion control and SHOULD use
the UDP checksum seems to me to be sufficient.  

It is only the high end routers that don't have the whole packet in
memory to run a UDP checksum where making it zero is needed.
Infeasibility certainly qualifies as a circumstance that meets going
against a SHOULD.

If MPLS over UDP starts showing up on lower end routers that could end
up on enterprise networks or worse yet consumer routers or hosts, then
a congestion control for UDP draft would have to be written and
advanced.  If so, it might be best to cover any form of tunneling over
UDP rather than just MPLS over UDP.


> > [Alia] Are you actually suggesting that it is highly likely for both
>   the destination IP and UDP port to be simultaneously corrupted on a
>   significant flow of packets where each link already has a FCS
>   covering the entire packet? 
>  
> It is possible. The FCS only covers the link, and the zero UDP
> checksum removes any check across the entire path. 
>  
> > [Alia] We have vast existence proof that MPLS label stacks, also
>   covered only by link FCS, that this is not the case. 
>  
> MPLS is scoped within the link between MPLS-aware devices. This
> tunnelling use is along the entire path. The scope is different. How
> are MPLS discards or missent packets measured? 
>  
> > [Alia] Can you clearly articulate what you see as the threat
>   scenario and the necessary scale and probability to be meaningful
>   here? 
>  
> 'Threat scenario' is language about mitigating a threat to your
> traffic. Here, your traffic with a zero UDP checksum poses the threat
> - to everything else. 
>  
> Probability of threat is non-zero, but unknown, because networks are
> not instrumented for it. We have discussed Stone's results and other
> anecdotal evidence in this thread. 
>  
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: Alia Atlas [[e-mail]]
> Sent: 22 January 2014 02:34
> To: Wood L  Dr (Electronic Eng)
> Cc: [e-mail]; [e-mail]; [e-mail]; Eggert, Lars
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
>  
> Lloyd,
>  
> On Tue, Jan 21, 2014 at 8:04 PM, <[e-mail]<mailto:[e-mail]>> wrote:
> Curtis,
>  
> the 'intended for use within a service provider' and not for mass use sounds reasonable,
> and scoping in this way may also alleviate some congestion control concerns.
>  
> [Alia] Excellent - so if we can describe filtering on the correct fields to enforce this constrained scope, then the concerns about congestion control may be alleviated.
>  
> But outgoing packet filtering, when you're trying to catch a corrupted port,
> and the port is not what you think it is? That's going to do a partial job
> of corrupted addresses in IPv6 at best. (v4 has header checksums,
> ports in v4 and v6 are open to corruption sans UDP pseudo-header
> check.)
>  
> [Alia] Are you actually suggesting that it is highly likely for both the destination IP and UDP port to be simultaneously corrupted on a significant flow of packets where each link already has a FCS covering the entire packet?
>  
> [Alia] We have vast existence proof that MPLS label stacks, also covered only by link FCS, that this is not the case.  Naturally the top label is manipulated but the rest of the label stack is just passed through and not looked at.
>  
> Not convinced by providers already blocking inbound traffic on a new port -
> particularly given discussion of handling entropy with varying ports
> in another thread.
>  
> [Alia] For defense, isn't it a case of block ports by default and only open the destination ports that are explicitly needed?  That's how firewalls that I've seen work; perhaps others have a common counterexample?  The entropy is put into the source port, which isn't relevant here.
>  
> So, I don't think filtering is a useful solution here to the problem posed
> by zero UDP checksums. (An actual UDP checksum solves it, of course.)
>  
> [Alia] Can you clearly articulate what you see as the threat scenario and the necessary scale and probability to be meaningful here?
>  
> Regards,
> Alia
>  
>  
> regards
>  
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: Curtis Villamizar [[e-mail]<mailto:[e-mail]>]
> Sent: 22 January 2014 00:24
> To: Wood L  Dr (Electronic Eng)
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
>  
> Lloyd,
>  
> Since MPLS over UDP is intended to be used within a provider, how
> about if we recommend the following:
>  
>   If no MPLS over UDP is intended to go outside a service provider,
>   then packet filters should be added to block traffic with the UDP
>   port number for MPLS over UDP to prevent misconfiguation or packet
>   error to cause MPLS over UDP packets to escape,
>  
> If either the IP destination address or the UDP destination port were
> corrupted, then the packet would not leave.  The former because the
> intended destination within the provider would get the packet.  The
> latter because with the UDP port intact the provider's filter would
> block it.
>  
> This would also prevent ordinary users from making use of MPLS over
> UDP, which with its absense of congestion control is causing some
> objections.
>  
> Providers would already be blocking traffic coming into their net with
> this UDP port, particularly to their own infrastructure.  The filters
> might cover only their own addresses allowing users to make use of
> MPLS over UDP, or could block it entirely.
>  
> This is in line with Alia's suggestion that we define a profile of
> intended use being for service providers internal use.
>  
> Curtis
>  
>  
> In message <[e-mail]<mailto:[e-mail]>>
> [e-mail]<mailto:[e-mail]> writes:
> >
> > > 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]<mailto:[e-mail]>]
> > Sent: 21 January 2014 20:14
> > To: Eggert, Lars
> > Cc: Stewart Bryant; Wood L  Dr (Electronic Eng); [e-mail]<mailto:[e-mail]>; Joel Jaeggli; [e-mail]<mailto:[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]<mailto:[e-mail]>>
> > "Eggert, Lars" writes:
> >
> > > Hi,
> > >
> > > On 2014-1-21, at 12:50, Stewart Bryant <[e-mail]<mailto:[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
> _______________________________________________
> mpls mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls