Subject: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-magic-numbers-01.txt

From: Tom Herbert <[email-masked]>
Date: Thu, 15 Oct 2015 16:05:30 -0700

Hello,

I posted a new version of UDP Magic Numbers. Previously, this came up
in the context of SPUD  and NVo3. The idea is that middleboxes in a
network may need to parse an encapsulated protocol within UDP. In
order to be able to the this, a middlebox needs to identify packets
with the encapsulation. Identifying based on destination port number
may be infeasible or lead to misinterpretation. A magic number in the
UDP payload can be used to allow identification at middleboxes with a
very high degree of confidence.

Comments are welcome!

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, Oct 15, 2015 at 3:55 PM
Subject: New Version Notification for draft-herbert-udp-magic-numbers-01.txt
To: Tom Herbert <[email-masked]>, Lucy Yong <[email-masked]>

A new version of I-D, draft-herbert-udp-magic-numbers-01.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-udp-magic-numbers
Revision:       01
Title:          UDP Magic Numbers
Document date:  2015-10-15
Group:          Individual Submission
Pages:          12
URL:
https://www.ietf.org/internet-drafts/draft-herbert-udp-magic-numbers-01.txt
Status:
https://datatracker.ietf.org/doc/draft-herbert-udp-magic-numbers/
Htmlized:       https://tools.ietf.org/html/draft-herbert-udp-magic-numbers-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-herbert-udp-magic-numbers-01

Abstract:
   This specification defines magic numbers in UDP which allow a node to
   determine or confirm the protocol contained in a UDP payload. This is
   primarily applicable for encapsulation and transport protocols
   encapsulated within UDP where intermediate devices, such as middle
   boxes, need to parse these protocols for providing service. Magic
   numbers can also be used to multiplex different UDP encapsulated
   protocols over the same UDP port.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ca By <[email-masked]>
Date: Thu, 15 Oct 2015 16:13:46 -0700

Tom,

The motivation seems unclear to me.

The example in the draft talks about using the numbers to flag traffic for
a stateful firewall.

Do you plan to use this magic number for a stateful firewall in your
network?

CB

On Thursday, October 15, 2015, Tom Herbert <[email-masked]> wrote:

> From:  <[email-masked] <javascript:;>>
> To: Tom Herbert <[email-masked] <javascript:;>>, Lucy Yong <
> [email-masked] <javascript:;>>
>
>
>
> Htmlized:
> https://tools.ietf.org/html/draft-herbert-udp-magic-numbers-01
> Diff:

---

From: Tom Herbert <[email-masked]>
Date: Thu, 15 Oct 2015 19:47:12 -0700

On Thu, Oct 15, 2015 at 4:13 PM, Ca By <[email-masked]> wrote:
> The example in the draft talks about using the numbers to flag traffic for a
> stateful firewall.
>
A method to implement a stateful firewall for flows within UDP is a
major part of the SPUD proposal. For UDP encapsulations (GUE, VXLAN,
GRE/UDP) we are assuming that middleboxes may want to do DPI into UDP
payload which may be stateless. For instance, it seems reasonable in
network virtualization that a middlebox may want to filter on the
virtual network identifier in a GUE packet.

Tom

---

From: Ca By <[email-masked]>
Date: Thu, 15 Oct 2015 20:44:56 -0700

On Thursday, October 15, 2015, Tom Herbert <[email-masked]> wrote:

> On Thu, Oct 15, 2015 at 4:13 PM, Ca By <[email-masked] <javascript:;>>
> wrote:
> > Tom,
> >
Do you know of some one that wants to do this? Seems more prudent to filter
at the end points rather than at some middle box that does not yet exist.

I do not support the work of SPUD, I think it is generally a bad idea to
encapsulate data in this way.... Especially in UDP since UDP is a toxic
mess on the Internet. Nearly 100% of the ddos attack traffic I receive is
udp.

> Tom
>
> > CB
> >
> >
> > On Thursday, October 15, 2015, Tom Herbert <[email-masked]
> <javascript:;>> wrote:
> >>
> >> Hello,
> >>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 16 Oct 2015 10:03:57 -0700

Ca,

Please note that this draft is not explicitly advocate the use of UDP
for encapsulation or transport protocols, nor inspection of UDP
payloads by middleboxes. There is already much discussion on the
merits and consequences of those things elsewhere. The intent here is
that if such things are done in the network, then there is robust and
general mechanism to unambiguously identify what a payload contains.

> at the end points rather than at some middle box that does not yet exist.

Middlebox inspection of UDP payload is a major part of SPUD. Also,
BIER encapsulated in UDP (draft-xu-bier-encapsulation-03) would imply
middleboxes that not only inspect a UDP payload but also will modify
it inflight, which is all the more reason why unambiguous
identification of the type of a UDP payload is important.

> encapsulate data in this way.... Especially in UDP since UDP is a toxic mess
> on the Internet. Nearly 100% of the ddos attack traffic I receive is udp.
>
It's not just SPUD, there's now QUIC, SCTP/UDP, GRE/UDP, MPLS/UDP,
GUE, Geneve, VXLAN, BIER-- all of which allow encapsulation of
network/transport protocols over UDP. The proliferation of UDP based
protocols for encapsulation and new transport protocols seems to be
because TCP and UDP are the only two protocols reasonably supported in
hardware, software, and the Internet.

Network operators rate limit UDP because it is not congestion
controlled, but presumably don't rate TCP since it is congestion
controlled. While it is true that UDP is a transport protocol without
congestion control, this is not the same as saying that all UDP
applications are not congestion controlled. For instance, QUIC is
defined be congestion controlled and uses port 443, so it should not
require rate limiting performed for non congestion controlled traffic.
The nuance is that IP protocol numbers have global meaning, but port
numbers do not. For instance, anywhere in the network, IP protocol = 6
is assumed to be TCP and thus congestion controlled. UDP port number
443 may or may not be QUIC. A UDP magic number would be useful to
ensure that a packet sent to UDP port 443 really is QUIC, and hence
know to be congestion controlled protocol.

Thanks for the comments!

Tom

---

From: Ca By <[email-masked]>
Date: Fri, 16 Oct 2015 10:14:26 -0700

On Fri, Oct 16, 2015 at 10:03 AM, Tom Herbert <[email-masked]> wrote:

> mess

Do you have some proof on that?

I rate limit UDP because it is mostly attack traffic and the only way to
keep the network up during the daily barrage of UDP attacks that are common
on the internet.

https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

> controlled, but presumably don't rate TCP since it is congestion

TCP is not rate limited because the application that are associated with it
are not susceptible to abuse from reflection and amplification attacks.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 17 Oct 2015 08:54:17 -0700

> Do you have some proof on that?
Yes, I have seen unthrottled UDP applications inadvertently bring a
network down. But if you prefer I'll say UDP is uncontrolled traffic
to encompass the abuses of it.

> are not susceptible to abuse from reflection and amplification attacks.
Well, TCP SYN attacks are still a major DDOS problem at our servers
and apparently it is possible to abuse TCP similarly
(http://www.christian-rossow.de/publications/tcpamplification-woot2014.pdf).
But my point is that not all UDP applications are necessarily evil.
SCTP/UDP and QUIC should have sufficient handshake to eliminate
reflections and amplification attacks as well as TCP. Such well
controlled UDP applications could differentiated from other by port
number along with a magic number.

Tom

---

From: Ca By <[email-masked]>
Date: Sat, 17 Oct 2015 09:26:17 -0700

> number along with a magic number.

Yeh. But. Who is going to pay for finding the needle you put in the
haystack ?

Not me.

Thus the problem with udp today and the inertia associated with the
existing state of affairs.

That said, i suggest not using udp.

CB

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Oct 2015 11:09:28 -0700

I don't like the idea of magic numbers as protocol identifiers.

The real problem is that you are trying to defeat the behavior of a box
that's trying to defeat you (by rewriting the ports). In that case, I
can easily see this as a game of mutual escalation - you add magic
numbers, they change the numbers, etc.

Those games aren't good for the Internet.

If you want to do something like this, IMO it needs to be done as a
"next protocol" header in UDP so that you can have actual codepoints
rather than magic numbers. I do have a proposal for UDP options that
might accommodate that sort of thing (draft-touch-tsvwg-udp-options).

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 30 Oct 2015 13:20:14 -0700

Hi Joe,

Replies in line.

> numbers, they change the numbers, etc.
I don't believe this related to port rewriting. The purpose of the
magic number is to allow middle boxes to correctly interpret the
contents of the UDP payload. There is no value in rewriting a magic
number in middle boxes.

> If you want to do something like this, IMO it nee(ds to be done as a
The magic number does contain the equivalent of a next protocol
number. It could be used to multiplex different protocol over the same
UDP port, but that is not really the intent.

The UDP options are a good example of the need for magic numbers.
Suppose a middlebox wants to parse UDP options for some reason. The
problem they would encounter is how to positively identify the packets
that contain UDP options that can be parsed. Matching by port number
in the middle of the network is not robust. Matching a magic number
for an application protocol that uses UDP options will, with very high
probability, ensure that the packet in question does indeed contain
UDP options.

There is another use case with UDP transports. It is well known that
many network providers arbitrarily block or rate limit UDP. This
obviously a problem in deploying a new UDP based transport protocols
such as QUIC or SPUD. The rationale of network operators is that UDP
is a huge source of DDOS and since UDP is not congestion controlled,
their only recourse is to restrict UDP. Unfortunately, this means well
managed and congested controlled UDP applications are lumped in with
all of the potentially abused applications. A way out of this could be
to differentiate between well behaved and not well behaved
applications. The magic number would facilitate that differentiation.

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Oct 2015 13:33:21 -0700

> contents of the UDP payload. There is no value in rewriting a magic

Wouldn't the port number sufficiently identify the contents, at least as
far as the endpoints (who are the only ones who can trust that or the
magic number anyway) are concerned?

> that contain UDP options that can be parsed. 

See draft-touch-tsvwg-udp-options

It uses a value for the UDP length field that is not derived from the IP
length field. That will completely identify whether options exist or not.

> Matching by port number

Port numbers indicate application protocols, i.e., the next protocol up
from UDP already.

The only reason you wouldn't trust the UDP port number would be because
it might be rewritten. But then anything that rewrites a port number
you'd need could(will) also rewrite the magic number.

> applications. The magic number would facilitate that differentiation.

Again, you're attempting to do something with the UDP payload that the
UDP port number already supports.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 30 Oct 2015 17:23:20 -0700

>From RFC7605: "It is important to recognize that any interpretation of
port numbers -- except at the endpoints -- may be incorrect, because
port numbers are meaningful only at the endpoints."

Given that, the question becomes what are the consequences if a
middlebox *does* misinterpret a port number. We've already seen
proposals in SPUD and I believe BIER that potentially overwrite UDP
data at middleboxes. So if a middlebox incorrectly interprets a port
and overwrites the UDP data we've now introduced a systematic,
undetectable corruption of the UDP packet in the middle of the network
(the middlebox would update the UDP checksum accordingly).  This is
disastrous and will be a nightmare to debug. The magic number would
mitigate problems like this.

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Oct 2015 17:28:12 -0700

On 10/30/2015 5:23 PM, Tom Herbert wrote:
> middlebox *does* misinterpret a port number.

Then why would it not also misinterpret a magic number? Are you not just
kicking the can down the road?

Remember, a man with one watch knows what time it is. A man with two is
never sure. What do you do when the port number and magic number disagree?

> We've already seen
> data at middleboxes.

And why would they not overwrite the magic number too?

> So if a middlebox incorrectly interprets a port

Magic numbers are horrible ways to try to detect tampering. If you want
integrity protection, use a real method.

Joe