Subject: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Jul 2015 17:24:59 +0200

Hi all,

we’ve just submitted a new use case document. This document describes in more detail the use cases as already presented/discussed at the BoF.

Please review and comment. Also partial reviews of e.g. just one use case are more than welcome. Further if you’d like to contribute to this document, please let use know as well.

For everybody who potentially has additional use cases in mind, I personally would appreciate to see future use case descriptions with a similar structure than use in this document. In found it very helpful to capture the most important points. However, this structure is also open for discussion.

Brian and Mirja

> Anfang der weitergeleiteten Nachricht:
> 
> Von: [email-masked]
> Betreff: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt
> Datum: 3. Juli 2015 17:19:10 MESZ
> An: "Mirja Kuehlewind" <[email-masked]>, "Mirja Kuehlewind" <[email-masked]>, "Brian Trammell" <[email-masked]>, "Brian Trammell" <[email-masked]>
> 
> 
> A new version of I-D, draft-kuehlewind-spud-use-cases-00.txt
> has been successfully submitted by Mirja Kuehlewind and posted to the
> IETF repository.
> 
> Name:		draft-kuehlewind-spud-use-cases
> Revision:	00
> Title:		SPUD Use Cases
> Document date:	2015-07-03
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-kuehlewind-spud-use-cases-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-kuehlewind-spud-use-cases/
> Htmlized:       https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00
> 
> 
> Abstract:
>   The Substrate Protocol for User Datagrams (SPUD) BoF session at the
>   IETF 92 meeting in Dallas in March 2015 identified the potential need
>   for a UDP-based encapsulation protocol to allow explicit cooperation
>   with middleboxes while using new, encrypted transport protocols.
>   This document summarizes the use cases discuss at the BoF and thereby
>   proposes a structure for the description of further use cases.
> 
> 
> 
> 
> 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: Tom Herbert <[email-masked]>
Date: Mon, 6 Jul 2015 10:20:11 -0700

> Please review and comment. Also partial reviews of e.g. just one use case are more than welcome. Further if you’d like to contribute to this document, please let use know as well.
Hi Mirja, thanks for the draft! Here are my comments.

General comments:

It seems to me there are two motivations for SPUD:

1) A common protocol layer for UDP flow based protocols to pass
through stateful firewalls and NAT.
2) A rich inband flow based QoS signaling initiated by end hosts which
can be interpreted by network devices in the path.

The first motivation seems pretty clear, the inability to pass UDP
(really anything besides TCP) through stateful firewalls has impeded
deployment of new L4 protocols.

The second motivation is less clear. Disregarding previously raised
questions around new DoS vectors and whether we can ever trust
anything anyone says on the Internet, I would ask if SPUD (UDP) is the
right layer for this. The need for this signaling doesn't seem to be
specific to UDP transport protocols, but also should applicable to
TCP, SCTP, and other protocols. Barring that these protocols
transition to running over SPUD (unlikely in the foreseeable future),
it seems like such signaling should be implemented in a more common
layer, maybe something like IP options.

Another general question I have is how much leeway should be taken in
relaxing or modifying the end-to-end semantics of UDP. In particular,
I think an important question is rather middleboxes should be
modifying UDP payloads. We've accepted that NAT devices can modify UDP
port numbers, but mucking with the payload seems worse to me. This
makes end-to-end authentication or integrity checks much more
difficult, and if a packet is ever misclassified as SPUD this could
result in data corruption. This issue also comes up in other
proposals, such as BIER, but those seem have more narrow application
(i.e. for multicast, deployed in closed network not the Internet as
SPUD is intended).

> For everybody who potentially has additional use cases in mind, I personally would appreciate to see future use case descriptions with a similar structure than use in this document. In found it ver…
Use of SPUD with NAT should probably be mentioned in the draft.

It might be worthwhile to consider some more specific applications of
firewalls. For example, if a firewall is deployed between a site and
the Internet, we might be more inclined to trust SPUD directives
received from the internal network as opposed to the Internet.

Another potential use case to investigate would be mobile devices
behind a middlebox.

Comments on the draft:

"This state should be bound to something beyond the five-tuple to link
packets together." question here of whether UDP source should be part
of identifying tuple. UDP encapsulation protocols are defining source
port as an entropy field for ECMP, so it might be good to take out
source port in the tuple.

"Further, to maintain state, the sender must explicitly indicate the
start and end of a tube to the path, while the receiver must confirm
connection establishment.". Sender and receiver might be ambiguous
terms, I like initiator and target if this is meant to indicate
perspective roles in the connection establishment.  An alternative
mode could be  request/response communication where the request
creates the state and the response closes it (this is described in
draft-herbert-gue-session-id-00 ).

I believe the mechanisms described in section 2 and the SPUD prototype
protocol could be vulnerable to something like a classic SYN attack.
That is an attacker could spoof open commands in an attempt to DOS at
the middlebox. Part of the defense against this attack is to do 3-WHS.
This might be already implied in the draft at "This, together with the
first packet following the confirmation, provides a guarantee of
return routability", but this isn't sufficient if the attacker can
also spoof that first packet following the confirmation. A solution is
to have the receiver (target) set part of the tube ID which an
attacker could not predict (this is analogous the requirement that
both SYN and ACK numbers must be synchronized before moving to
Established state in TCP). Please look at
draft-herbert-gue-session-id-00 for more on this.

"A SPUD endpoint receiving a SPUD header with timeout information
should reflect this information to the sender". This is a good example
of the trust problem. Why would we trust an endpoint to do this
correctly? Maybe they just always return the smallest possible value
instead without any regard to the cost at the sender or its network
for sending frequent heart beats. In this case, I think it would be
better for the middlebox (local to the sender) to return the timeout
information to the sender using an out of band protocol. Also, this
might not be needed for every flow, in the common case of a node being
behind a single firewall getting the value once would probably
suffice.

"Therefore it has to send heartbeat fairly rapidly, or might assume a
default value of 150ms that is commonly used today." Where does this
value come from? Couldn't such a rate kill battery on a mobile device?

"An application does not benefit from wronly indicating loss- or
latency-sensitivity" Typo :-)... The question here is what are the
consequences if traffic is incorrectly marked. If mis-marking packets
can adversely affect other non-related flows then this mechanism
potentially becomes the basis for a DoS attack. For example, if
someone arbitrarily decides to mark all their packets as low latency,
increasing the latency of other flows or even worse increasing packet
loss for other correctly marked low latency traffic would be a
problem.

Tom

> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Tue, 7 Jul 2015 10:53:29 +0000

Hi Tom, Mirja,

> 1) A common protocol layer for UDP flow based protocols to pass through stateful firewalls and NAT.
> 2) A rich inband flow based QoS signaling initiated by end hosts which can be interpreted by network devices in the path.

I'd also suggest this motivation
 (3) Inband signaling of hints from network devices in the path towards endpoints and/or each other

This would allow (for example) a radio network node to provide hints on cell congestion towards the endpoints, that may be used to pace the content flow accordingly. These would remain hints and not directives, and would require authentication. As Tom says, a key question is the whether to consider IP layer extensions, however I suspect there may be some interoperability issues whereby routers discard IP options, and ICMP is source-destination only. If SPUD can indeed run under TCP then that makes it a more attractive option IMO.

All best
Kevin

Kevin Smith, Vodafone R&D

-----Original Message-----
From: Spud [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: 06 July 2015 18:20
To: Mirja Kühlewind
Cc: Brian Trammell; [email-masked]
Subject: Re: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt

General comments:

1) A common protocol layer for UDP flow based protocols to pass through stateful firewalls and NAT.
2) A rich inband flow based QoS signaling initiated by end hosts which can be interpreted by network devices in the path.

The first motivation seems pretty clear, the inability to pass UDP (really anything besides TCP) through stateful firewalls has impeded deployment of new L4 protocols.

The second motivation is less clear. Disregarding previously raised questions around new DoS vectors and whether we can ever trust anything anyone says on the Internet, I would ask if SPUD (UDP) is the right layer for this. The need for this signaling doesn't seem to be specific to UDP transport protocols, but also should applicable to TCP, SCTP, and other protocols. Barring that these protocols transition to running over SPUD (unlikely in the foreseeable future), it seems like such signaling should be implemented in a more common layer, maybe something like IP options.

Another general question I have is how much leeway should be taken in relaxing or modifying the end-to-end semantics of UDP. In particular, I think an important question is rather middleboxes should be modifying UDP payloads. We've accepted that NAT devices can modify UDP port numbers, but mucking with the payload seems worse to me. This makes end-to-end authentication or integrity checks much more difficult, and if a packet is ever misclassified as SPUD this could result in data corruption. This issue also comes up in other proposals, such as BIER, but those seem have more narrow application (i.e. for multicast, deployed in closed network not the Internet as SPUD is intended).

It might be worthwhile to consider some more specific applications of firewalls. For example, if a firewall is deployed between a site and the Internet, we might be more inclined to trust SPUD directives received from the internal network as opposed to the Internet.

Another potential use case to investigate would be mobile devices behind a middlebox.

Comments on the draft:

"This state should be bound to something beyond the five-tuple to link packets together." question here of whether UDP source should be part of identifying tuple. UDP encapsulation protocols are defining source port as an entropy field for ECMP, so it might be good to take out source port in the tuple.

"Further, to maintain state, the sender must explicitly indicate the start and end of a tube to the path, while the receiver must confirm connection establishment.". Sender and receiver might be ambiguous terms, I like initiator and target if this is meant to indicate perspective roles in the connection establishment.  An alternative mode could be  request/response communication where the request creates the state and the response closes it (this is described in
draft-herbert-gue-session-id-00 ).

I believe the mechanisms described in section 2 and the SPUD prototype protocol could be vulnerable to something like a classic SYN attack.
That is an attacker could spoof open commands in an attempt to DOS at the middlebox. Part of the defense against this attack is to do 3-WHS.
This might be already implied in the draft at "This, together with the first packet following the confirmation, provides a guarantee of return routability", but this isn't sufficient if the attacker can also spoof that first packet following the confirmation. A solution is to have the receiver (target) set part of the tube ID which an attacker could not predict (this is analogous the requirement that both SYN and ACK numbers must be synchronized before moving to Established state in TCP). Please look at
draft-herbert-gue-session-id-00 for more on this.

"A SPUD endpoint receiving a SPUD header with timeout information should reflect this information to the sender". This is a good example of the trust problem. Why would we trust an endpoint to do this correctly? Maybe they just always return the smallest possible value instead without any regard to the cost at the sender or its network for sending frequent heart beats. In this case, I think it would be better for the middlebox (local to the sender) to return the timeout information to the sender using an out of band protocol. Also, this might not be needed for every flow, in the common case of a node being behind a single firewall getting the value once would probably suffice.

"Therefore it has to send heartbeat fairly rapidly, or might assume a default value of 150ms that is commonly used today." Where does this value come from? Couldn't such a rate kill battery on a mobile device?

"An application does not benefit from wronly indicating loss- or latency-sensitivity" Typo :-)... The question here is what are the consequences if traffic is incorrectly marked. If mis-marking packets can adversely affect other non-related flows then this mechanism potentially becomes the basis for a DoS attack. For example, if someone arbitrarily decides to mark all their packets as low latency, increasing the latency of other flows or even worse increasing packet loss for other correctly marked low latency traffic would be a problem.

Tom

>> An: "Mirja Kuehlewind" <[email-masked]>, "Mirja 
>> Kuehlewind" <[email-masked]>, "Brian Trammell" 
>> <[email-masked]>, "Brian Trammell" <[email-masked]>
>>
>>
>> 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: Szilveszter Nadas <[email-masked]>
Date: Tue, 7 Jul 2015 11:49:01 +0000

Hi,

I agree with "I suspect there may be some interoperability issues whereby routers discard IP options". It is also hard for me to imagine (2) without authentication in many cases. We also have more use cases in mind for (2) and (3), but I am not 100% sure, whether that still fits the SPUD scope. I will send the draft about that shortly.

Cheers,
Sz

-----Original Message-----
From: Spud [mailto:[email-masked]] On Behalf Of Smith, Kevin, (R&D) Vodafone Group
Sent: Tuesday, July 07, 2015 12:53
To: Tom Herbert; Mirja Kühlewind
Cc: Brian Trammell; [email-masked]
Subject: Re: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt

Hi Tom, Mirja,

All best
Kevin

-----Original Message-----
From: Spud [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: 06 July 2015 18:20
To: Mirja Kühlewind
Cc: Brian Trammell; [email-masked]
Subject: Re: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt

General comments:

Comments on the draft:

Tom

---

From: Brian Trammell <[email-masked]>
Date: Tue, 7 Jul 2015 15:43:46 +0200

Hi, Tom,

> On 06 Jul 2015, at 19:20, Tom Herbert <[email-masked]> wrote:
> 

Kind of, though it's not *strictly* QoS focused.

There's also (1.5): enable network management functionality which today uses DPI but will no longer function with increasing payload encryption. But the current draft doesn't go into much depth on this point.

> layer, maybe something like IP options.

I tend to think that the signaling vocabulary and encoding(s) should be defined *separately* from the mechanism to bind that encoding into the protocol stack. Taking draft-hildebrand-spud-prototype as an example, one could define a set of CBOR keys that one must understand for a given SPUD application (say, the low latency use case), and then bind those CBOR keys into userspace transports using SPUD, into IPv6 traffic using hop-by-hop and/or destination options (in a world in which those work), etc.

In any case, I think at *minimum* any layer supporting this has to be able to run over UDP, by process of elimination -> you can't always add things to the kernel or get privilege to open a raw socket (i.e. requirement 6.3 in draft-trammell-spud-req).

> port numbers, but mucking with the payload seems worse to me.

First off I've come to accept that the de facto boundary between the network and transport layer in the Internet architecture is four bytes after the end of the IPv4 header-plus-options or the IPv6 headers. The ports are used often enough in forwarding decisions, and protocols that don't have port numbers in those positions are consequently not as able to get through the network as protocols that do. Given the installed base, it's conceptually cleaner to treat these thirty-two bits as belonging to the network layer now.

The eventual idea is to put stuff that middleboxes can look at (and potentially mess with) outside the crypto curtain, while encrypting everything else. The fact that middleboxes can mess with the data makes it inherently less trustworthy, yes, but that's the case with unencrypted traffic in today's Internet anyway.

There's a discussion on the tradeoffs of this sort of "piggyback" signaling in draft-trammell-spud-req (section 7.5).

> This
> difficult

End-to-end authentication and integrity checks would happen in the payload layered on top of SPUD -- signaling between the endpoints that that path doesn't need to see should be encrypted anyway. There are possibly types of information that the endpoints need to expose that also require protection...

> and if a packet is ever misclassified as SPUD this could
> result in data corruption.

This is the rationale behind requirement 6.2 in draft-trammell-spud-req: it has to be easy to recognize a SPUD packet (indeed, we should also state that this recognition requires a bounded error probability).

> This issue also comes up in other

I don't see that the protocols running over SPUD and the protocols running over an encapsulation with this ECMP entropy hack (in the nicest sense of the word?) are trying to solve the same problem... The UDP source port is crucial for return routability to the far endpoint when its stack is implemented in userspace...

> draft-herbert-gue-session-id-00 for more on this.

Thanks for the pointer; yes, we do need something like this mechanism. There are also probably cryptographic approaches here that would be worth looking into, if there *is* indeed already established trust between the endpoints and the overlying transport can share that with SPUD.

> value come from? Couldn't such a rate kill battery on a mobile device?

Yes, which is one of the reasons an explicit signaling protocol here would be a nice thing to have. Agreed that we need to get to vocabulary and incentives to cooperate right.

> loss for other correctly marked low latency traffic would be a

Presuming a well-implemented dual-service system, masses of traffic piling into the low-latency queue would indeed increase loss rate. Of course, the low-latency service is only intended for transport protocols which can already tolerate more loss than TCP, and I'd need to run some experiments with such a thing before I were convinced that an attacker that has the power to overrun the low-latency queue doesn't also already have the ability to cause the same or worse disruption in service in a single-queue system.

Cheers,

Brian

---

From: Youjianjie <[email-masked]>
Date: Tue, 7 Jul 2015 14:03:09 +0000

Hi Kevin,

The following draft describes the use case for item (3), especially for TCP.
https://www.ietf.org/internet-drafts/draft-yw-spud-use-cases-00.txt

Regards,
Jianjie

> -----邮件原件-----
> 发件人: Spud [mailto:[email-masked]] 代表 Smith, Kevin, (R&D)
> Vodafone Group
> 发送时间: 2015年7月7日 18:53
> 收件人: Tom Herbert; Mirja Kühlewind
> 抄送: Brian Trammell; [email-masked]
> 主题: Re: [Spud] Fwd: New Version Notification for
> draft-kuehlewind-spud-use-cases-00.txt
> 
> Hi Tom, Mirja,
> 
> > 2) A rich inband flow based QoS signaling initiated by end hosts which can be
> interpreted by network devices in the path.
> 
> This would allow (for example) a radio network node to provide hints on cell
> congestion towards the endpoints, that may be used to pace the content flow
> accordingly. These would remain hints and not directives, and would require
> authentication. As Tom says, a key question is the whether to consider IP layer
> extensions, however I suspect there may be some interoperability issues
> whereby routers discard IP options, and ICMP is source-destination only. If
> SPUD can indeed run under TCP then that makes it a more attractive option
> IMO.
> 
> All best
> Kevin
> 
> > we’ve just submitted a new use case document. This document describes in
> more detail the use cases as already presented/discussed at the BoF.
> >
> > Please review and comment. Also partial reviews of e.g. just one use case are
> more than welcome. Further if you’d like to contribute to this document,
> please let use know as well.
> >
> 2) A rich inband flow based QoS signaling initiated by end hosts which can be
> interpreted by network devices in the path.
> 
> The first motivation seems pretty clear, the inability to pass UDP (really
> anything besides TCP) through stateful firewalls has impeded deployment of
> new L4 protocols.
> 
> The second motivation is less clear. Disregarding previously raised questions
> around new DoS vectors and whether we can ever trust anything anyone says
> on the Internet, I would ask if SPUD (UDP) is the right layer for this. The need
> for this signaling doesn't seem to be specific to UDP transport protocols, but
> also should applicable to TCP, SCTP, and other protocols. Barring that these
> protocols transition to running over SPUD (unlikely in the foreseeable future), it
> seems like such signaling should be implemented in a more common layer,
> maybe something like IP options.
> 
> relaxing or modifying the end-to-end semantics of UDP. In particular, I think an
> important question is rather middleboxes should be modifying UDP payloads.
> We've accepted that NAT devices can modify UDP port numbers, but mucking
> with the payload seems worse to me. This makes end-to-end authentication or
> integrity checks much more difficult, and if a packet is ever misclassified as
> SPUD this could result in data corruption. This issue also comes up in other
> proposals, such as BIER, but those seem have more narrow application (i.e. for
> multicast, deployed in closed network not the Internet as SPUD is intended).
> 
> > For everybody who potentially has additional use cases in mind, I personally
> would appreciate to see future use case descriptions with a similar structure
> than use in this document. In found it very helpful to capture the most
> important points. However, this structure is also open for discussion.
> >
> It might be worthwhile to consider some more specific applications of firewalls.
> For example, if a firewall is deployed between a site and the Internet, we might
> be more inclined to trust SPUD directives received from the internal network as
> opposed to the Internet.
> 
> "This state should be bound to something beyond the five-tuple to link packets
> together." question here of whether UDP source should be part of identifying
> tuple. UDP encapsulation protocols are defining source port as an entropy field
> for ECMP, so it might be good to take out source port in the tuple.
> 
> "Further, to maintain state, the sender must explicitly indicate the start and
> end of a tube to the path, while the receiver must confirm connection
> establishment.". Sender and receiver might be ambiguous terms, I like initiator
> and target if this is meant to indicate perspective roles in the connection
> establishment.  An alternative mode could be  request/response
> communication where the request creates the state and the response closes it
> (this is described in
> That is an attacker could spoof open commands in an attempt to DOS at the
> middlebox. Part of the defense against this attack is to do 3-WHS.
> This might be already implied in the draft at "This, together with the first
> packet following the confirmation, provides a guarantee of return routability",
> but this isn't sufficient if the attacker can also spoof that first packet following
> the confirmation. A solution is to have the receiver (target) set part of the tube
> ID which an attacker could not predict (this is analogous the requirement that
> both SYN and ACK numbers must be synchronized before moving to Established
> state in TCP). Please look at
> "A SPUD endpoint receiving a SPUD header with timeout information should
> reflect this information to the sender". This is a good example of the trust
> problem. Why would we trust an endpoint to do this correctly? Maybe they just
> always return the smallest possible value instead without any regard to the
> cost at the sender or its network for sending frequent heart beats. In this case,
> I think it would be better for the middlebox (local to the sender) to return the
> timeout information to the sender using an out of band protocol. Also, this
> might not be needed for every flow, in the common case of a node being behind
> a single firewall getting the value once would probably suffice.
> 
> "Therefore it has to send heartbeat fairly rapidly, or might assume a default
> value of 150ms that is commonly used today." Where does this value come
> from? Couldn't such a rate kill battery on a mobile device?
> 
> latency-sensitivity" Typo :-)... The question here is what are the consequences
> if traffic is incorrectly marked. If mis-marking packets can adversely affect
> other non-related flows then this mechanism potentially becomes the basis for
> a DoS attack. For example, if someone arbitrarily decides to mark all their
> packets as low latency, increasing the latency of other flows or even worse
> increasing packet loss for other correctly marked low latency traffic would be a
> problem.
> 
> Tom
> 
> 
> 
> > Brian and Mirja
> >
> >
> >
> >> URL:
> https://www.ietf.org/internet-drafts/draft-kuehlewind-spud-use-cases-00.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-kuehlewind-spud-use-cases/
> >> Htmlized:
> https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00
> >>
> >>
> >> Abstract:

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 7 Jul 2015 07:22:28 -0700

> can be interpreted by network devices in the path.

Point 2 already expanded by Mirja - not only QoS, but any form
of policy.

> layer, maybe something like IP options.

You just mentioned two key goals. I think there are four:

 1) Common connection layer for transport protocols (your 1)
    for signaling application<->network middleboxes
 2) Common policy signaling layer for transport flows (your 2)
    for signaling application<->network middleboxes
 3) 1) and 2) shareable by existing AND novel transport protocols
    [Existing protocols may duplicate some of 1) and 2) but without
     the ability to signal application<->network well0
 4) Ability to build 1)..3) at the application layer
    Aka: Outside the classical OS to app boundary
    Aka: After OS demultiplexing
    Aka: faster developed, deployed, security-fixed, enhanced,...
    than our existing IETF protocol stack model.
    Aka: must be on top of UDP.

I contend your statement that we will not be able to have reliable
transport protocols run over SPUD. Of course, there is a lot of work to
create successfull proliferation: Browsers, RTCweb,
IoT protocol stacks, Cross-OS Open Source stacks are IMHO four key targets
which are necessary and sufficient to make the SPUD strategy work.

Your mentioning of IP options is quite correct in the face of the
historic OS protocol stack. And we need to change this:

OS:
  routing/forwarding (IPv6)
  OS app-demultiplex (UDP)
Base SDK, bound to OS-app:
  connection signaling
  policy/QoS signaling
    (un)reliable/realtime flow managemenet ("transport")
Higher layer SDK:
  Eg: Browser
Higher layer app
  
Cheers
    Toerless

---

From: Tom Herbert <[email-masked]>
Date: Wed, 8 Jul 2015 08:54:05 -0700

> In any case, I think at *minimum* any layer supporting this has to be able to run over UDP, by process of elimination -> you can't always add things to the kernel or get privilege to open a raw soc…
IP is the least common denominator and so use of IP options would be
applicable to all IP protocols, not just a new application based
protocol that currently has zero deployment. This is the appropriate
place for the policy/QoS information information described in the use
cases, and there are already facilities for both hop-by-hop options
and allowing middle boxes to modify options inflight. The ability for
applications and receive and arbitrary list of IP options has long
been supported in kernels (IP_OPTIONS and IP_RECVOPTS socket options),
so I really don't see any argument that kernel can't provide necessary
support.

Tom

---

From: Ken Calvert <[email-masked]>
Date: Wed, 8 Jul 2015 12:25:22 -0400

> so I really don't see any argument that kernel can't provide necessary

Seems like the 40-byte limit in v4 would make it difficult to do some things you might want to do, especially as hash sizes keep growing.

I like the viewpoint someone (Brian, I think) suggested earlier:  the network layer header effectively includes the  UDP header.  So SPUD could be viewed as a way of carrying network layer options (in addition to transport info).

Ken Calvert

---

From: Brian Trammell <[email-masked]>
Date: Wed, 8 Jul 2015 18:27:31 +0200

> On 08 Jul 2015, at 17:54, Tom Herbert <[email-masked]> wrote:
> 
> applicable to all IP protocols,

As to appropriateness, yes, I agree completely.

> not just a new application based
> protocol that currently has zero deployment.

...which I will note is precisely as much deployment as any IP options based approach would have on day zero; the question of how to get the data into the packet is IMO separate from the adoption of the data model of the exposed data itself.

> This is the appropriate
> and allowing middle boxes to modify options inflight.

Indeed. This presumes that new IP options are more realistically widely deployable in the Internet than a new protocol over UDP. I would need to see some data to back that up (indeed, this would fit nicely in a measurement study we're running right now so we may well end up generating that data. :) )

> The ability for

...which at least makes these accessible from platforms which let the apps muck about with socket options.

Thanks, cheers,

Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Jul 2015 13:07:29 -0700

On 7/8/2015 9:27 AM, Brian Trammell wrote:
> Indeed. This presumes that new IP options are more realistically
> widely deployable in the Internet than a new protocol over UDP. I would
> need to see some data to back that up (indeed, this would fit nicely in
> a measurement study we're running right now so we may well end up
> generating that data. :) )

Check the discussions over in v6ops.

There has been a lot of work there trying to deprecate all IPv6 options,
which has at least been successful in limiting the length of the option
chain.

One challenge is that IPv6 options are processed differently than IPv4 -
there's no way to "jump" straight into the transport header to find
ports (for port-based load balancing, e.g.).

I suspect you'll find that IP options are basically a non-starter except
for research purposes.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Jul 2015 13:08:27 -0700

On 7/8/2015 9:25 AM, Ken Calvert wrote:
> I like the viewpoint someone (Brian, I think) suggested earlier:  the
> network layer header effectively includes the  UDP header.

See my other post on this thread; getting at the UDP header from IP can
be cumbersome in IPv6.

> So SPUD
> could be viewed as a way of carrying network layer options (in
> addition to transport info).

Not options you expect core routers to examine, IMO.

Joe

---

From: Brian Trammell <[email-masked]>
Date: Thu, 9 Jul 2015 07:23:01 +0200

hi Joe, all,

> On 08 Jul 2015, at 22:07, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Yep. If the option chain had a small and easily-hardware-determinable set of possible lengths -- which is the case for v4 options -- this would be easier (but still harder to handle on the fast path than the arrangements we're proposing here).

> I suspect you'll find that IP options are basically a non-starter except

For the story on the v4 side, do you know of anything newer than Fonseca et al "IP Options are Not and Option" (tech report version at http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's ten years old -- but given where the engineering effort has gone during that decade, I doubt strongly much has changed here.

Cheers,

Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Jul 2015 10:36:52 -0700

> hi Joe, all,
...
> Yep. If the option chain had a small and
> easily-hardware-determinable
> set of possible lengths -- which is the case for v4 options -- this
> would be easier (but still harder to handle on the fast path than the
> arrangements we're proposing here).

IPv4 options can be jumped over in one step using the IHL field. There's
no such field for IPv6 - routers have to walk the chain of headers one
by one.

> For the story on the v4 side, do you know of anything newer than
> Fonseca et al "IP Options are Not and Option" (tech report version at
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's
> ten years old -- but given where the engineering effort has gone during
> that decade, I doubt strongly much has changed here.

Not much. Those old studies have been used in other WGs to drive
documents (IMO, unfortunately).

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 9 Jul 2015 14:04:46 -0700

> which has at least been successful in limiting the length of the option
Looking at the 6man documents, it seems like there is still an active
interest in IPv6 options. I know there is currently work being done on
implementing the segment routing option.

> ports (for port-based load balancing, e.g.).

The IPv6 label flow can be used to provide the entropy needed for ECMP
(like in RFC6438). With flow labels, devices would not need to do DPI
for purposes of ECMP. This solves the issue not only for devices that
don't want to parse over extension headers, but also allows flow-based
ECMP with protocols other than just UDP and TCP. Several vendors are
already providing support for flow labels and ECMP, and we intend to
start setting flow labels by default in end hosts (Linux at least).

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Jul 2015 14:10:30 -0700

> implementing the segment routing option.

Yes - that's one of my concerns with the rush to deprecate them ;-)

> for purposes of ECMP. 

While I agree with your logic, the other issue is that the flow labels
aren't set properly AND existing ops is based on port-directed forwarding.

I'm not suggesting I agree with this; IMO, anything that digs into a
packet deep enough to find the transport header is acting like an
endpoint and ought to expect to do the work needed to find that header.

Joe

---

From: Brian Trammell <[email-masked]>
Date: Fri, 10 Jul 2015 12:44:38 +0200

> On 09 Jul 2015, at 19:36, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> IPv4 options can be jumped over in one step using the IHL field.

yes, |set| = 1.

> There's

Right. It seems to me the way out of this (which is not just a problem for boxes that want to muck about in transport protocols, but ones that want to properly process hop by hop options) would be to define a new (small) set of IPv6 options headers that themselves would (1) not be combinable and (2) have a fixed length, allowing the next-header field to be _treated_ in constant time / with relatively few gates as the IHL field.

I haven't followed 6man, though I presume this approach or approaches like it have been discussed there ad nauseam.

The fixed-lengthness of these new v6 options headers would make them problematic for freely extensible options, though one could use these to stick common fast path options in the "fixed" point of the header, and otherwise point to space elsewhere in the packet for things that can happen slowly. You eat the cost of following pointers and doing the more expensive deframing only if you need to in this case.

> documents (IMO, unfortunately).

I've been thinking about whether it would be worth the effort to do an updated IP options transparency study.

We revisited the safety of ECN in part because there were plausible processes for the situation to have changed -- the biggest problems that caused the Internet to be ECN-unsafe involved what were basically single-packet exploits against routers, and needed to be fixed for reasons *other* than making the feature work. (ECN *support* is another question, the answer to which is less cheerful.)

I can't think of a comparable process making new/experimental options support less linked to connectivity risk in edge networks -- if nobody uses them (because they don't work) then if you try to use them and they don't work, it's your fault. That would unfortunately seem to be a rather stable state.

Coming back to the layering question:

It does seem to me that what we're (the we that wrote the two documents starting this thread) trying to do is explicitly reinforce the boundary between the network layer and the transport layer, where this is defined as "things the path needs to see versus things only endpoints need to see". Asking nicely (i.e., publishing RFCs) did not work in this case: the transport ports are de facto part of the network layer now, and short of blowing the Internet up and starting over I can't see a way to get them back. So now we are left with enforcing the boundary cryptographically, leaving some space in the "new network layer" (in this case, IP + UDP (for ports) + SPUD) for those things now commonly done within the network.

If we can do this in the _current_ network layer (IPv6 (with options) with some alternate way to handle NAT + DTLS, or we find a portal to an alternate universe where end-to-end IPsec is widely deployable and manageable), then great, let's do that. I'm pessimistic enough to believe that that hasn't been a realistic prospect at any time during this century, though.

Cheers,

Brian

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2015 09:19:19 -0700

> It does seem to me that what we're (the we that wrote the two documents starting this thread) trying to do is explicitly reinforce the boundary between the network layer and the transport layer, wh…
This "new network layer" breaks down at fragmentation. Only the first
fragment carries port numbers and the embedded network layer
information in the payload. Other fragments will carry neither, but
still can carry IP options, DSCP, TTL, ECN marking, flow labels in
IPv6.

An alternate possibility would be to embed IP options within UDP. So a
packet might look like IP-UDP-IP options-payload. This allows us to
use native options (say in our data center where we can control
things), but maybe to use embedded IP options in UDP on paths in the
Internet where we see options are being dropped. SFC-in-UDP
(https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00)
proposes a similar model, although I don't believe they allow
middleboxes to modify or to be regularly looking the headers.

> If we can do this in the _current_ network layer (IPv6 (with options) with some alternate way to handle NAT + DTLS, or we find a portal to an alternate universe where end-to-end IPsec is widely dep…
I don't understand what the issue is with crypto here. SSL/TLS are
widely deployed with use of NAT, and we are certainly using encrypted
tunnels over the Internet.

Tom

---

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Jul 2015 09:25:09 -0700

On Fri, Jul 10, 2015 at 3:44 AM, Brian Trammell <[email-masked]> wrote:

> We revisited the safety of ECN in part because there were plausible
> processes for the situation to have changed -- the biggest problems that
> caused the Internet to be ECN-unsafe involved what were basically
> single-packet exploits against routers, and needed to be fixed for reasons
> *other* than making the feature work. (ECN *support* is another question,
> the answer to which is less cheerful.)
>
> I can't think of a comparable process making new/experimental options
> support less linked to connectivity risk in edge networks -- if nobody uses
> them (because they don't work) then if you try to use them and they don't
> work, it's your fault. That would unfortunately seem to be a rather stable
> state.
>
>

​From a research design point of view, I think you could construct such a
study so that your test nodes tried both IP options​ and SPUD, so I think
it is worth thinking about quite seriously.  While it is not the main point
of them, you might be able to talk the RIPE and MLAB folks into adding code
to their test devices to enable these checks.

More data is always good,

Ted

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jul 2015 10:14:59 -0700

Hi, Brian,

...
>> IPv4 options can be jumped over in one step using the IHL field.

Well, it's actually also because the offset is in the default header and
nowhere else. The number of options varies, as does the length of many
options.

> Right. It seems to me the way out of this (which is not just a 
> problem for boxes that want to muck about in transport protocols, but
> ones thatwant to properly process hop by hop options) would be to
> define a new(small) set of IPv6 options headers that themselves would
> (1) not be combinable and (2) have a fixed length, allowing the
> next-header field to be _treated_ in constant time / with relatively
> few gates as the IHL field.

There are several hurdles, not the least of which is that the length of
HBH options can change in transit.

You don't really need a fixed length to solve this, or even a fixed set.
The options can even be mutable.

What you really need is a "jump to transport" header that comes before
all the others, and that is maintained by any device that adds, deletes,
or changes the length of an option.

The real problem there isn't doing that; its knowing whether you've
traversed a router that obeys those rules without dropping packets at
routers that don't. That would kill IPv6.

> I haven't followed 6man, though I presume this approach or
> approaches like it have been discussed there ad nauseam.

See above.

> The fixed-lengthness of these new v6 options headers would make them 
> problematic for freely extensible options, though one could use these
> to stick common fast path options in the "fixed" point of the header,
> and otherwise point to space elsewhere in the packet for things that
> can happen slowly. You eat the cost of following pointers and doing
> the more expensive deframing only if you need to in this case.

The real issue, AFIACT, is detecting the behavior of legacy devices that
wouldn't know to follow these rules - without having them drop the
packet because it is an unknown option (i.e., you can set "drop if
unknown", but that would be bad; if you don't set that bit, then you
can''t detect when changes occur easily).

> I've been thinking about whether it would be worth the effort to do
> an updated IP options transparency study.

The IETF has a persistent problem with extensibility. Vendors don't make
money supporting capabilities not in current use, but that ossifies the
protocols badly.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jul 2015 10:31:11 -0700

Hi, Tom,

> still can carry IP options, DSCP, TTL, ECN marking, flow labels in

Right. Which goes to the point that port numbers are NOT part of the
network layer.

Those who want to filter on port numbers are operating network devices
that act on behalf of endpoints - which is fine, but also means they
really ought to be reassembling the network-layer fragments.

I.e., the benefit of port filtering needs to come with the work of
reassembly. Or, "with great (filtering) power, comes great (don't break
the Internet) responsibility".

> An alternate possibility would be to embed IP options within UDP.

That would be a tunnel, and you might look at GUE.

However, you'd have the problem of the relationship of the inner and
outer options and how to maintain them as consistent if they're related.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Jul 2015 13:45:14 -0700

IMHO, IP options do not get us anywhere.

I want a solution that works against the lowest common denominator
of APIs for applications that i have across not only platfornms,
but also application development environments. I have UDP APIs on
a lot more SDKs that UDP + IP options. I bet if i looked, i wouldn't
find IP optoins in a lot of interpreted language SDKs.

Even if supported by language SDK, its an OS issue whether IP optoins
are supported. I remember that some investigation for a project we did
2? years back now resulted in us finding that at C level system APIs,
android for example was not supporting IP router alert for a UDP socket
for IPv6, even though it supported it for IPv4 (i hope i remember these
details correctly). And its just one example.

If all of this stuff is fine, i am totally not persuaded that IP
options are going to be accepted by network operators. There is no
way to guarantee to a network operator that packets with IP options are
NOT punted and cause performance impacts.

We went through this exercise with ECN, and still haven't moved ahead.
After 10 years or so. Where is the stealth data-collection facility in
eg: firefox that tries randomn ECN flows not only to see whether they
pass through, but also checking latency & jitter to validate that
these ECN packets where not punted in routers when they did pass through ?

I am not saying we shouldn't have a glorified plan for STUN that ALSO
includes the architecture for doing it correctly for the
1980's Internet architecture, but please lets not make this plan A.

The Internet architecture has evolved on so many fronts. Can we not
learn in the network/transport layer structure too how to get the
best solutions for reality ?

Just saying.

Toerless

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jul 2015 14:44:44 -0700

+1, for somewhat different reasons, notably the problem deploying new IP
options and layer separation.

This really hints that UDP isn't quite sufficient without its own
options. There seems only one place to do this - using the UDP length
field.

E.g., let's say you have a 1500B IP packet with a 20B IP header, leaving
1480 for UDP. But instead of saying that UDP's Length is 1280, we say
it's 1400; in that case, the last 80 bytes could be used as a 'trailer
option area'.

This is somewhat like UDP-lite, except that instead of declaring the
length to indicate "checksum coverage", it would just indicate the UDP
payload vs. extended header, and it would use the existing UDP protocol
number (17) rather than that of UDPlite (136).

---
The reason why this mechanism can use the current UDP protocol number is
that we're not changing the semantics of UDP or the length of the data
delivered to the application vs. the existing UDP length field.

Because we're still assuming that the UDP checksum covers only the
length indicated in the UDP header, there should be no inconsistency
with "mismatching pseudoheaders" - I think. I'll check with the UDPlite
crowd (unless any are already on this list - Gorry?)
---

I'm still not convinced it's safe, though. It would not be covered by
the UDP checksum. I have no idea whether existing stacks would handle it
correctly (i.e., ignoring the extra bytes) vs. shortening the IP packet
to make the lengths match.

NOTE: this appears valid per RFC1122 and RFC768, but I haven't tried it
to see whether it makes various OSes blow up yet...

Hmmm.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2015 15:19:53 -0700

> it's 1400; in that case, the last 80 bytes could be used as a 'trailer
You get UDP data on a UDP socket, so 1400 bytes is returned. Returning
the extra bytes would be a simple kernel and API change (at least in
Linux). Besides that, I imagine that HW vendors probably want the
options to be in the headers due to the HW limitations of packet
processing.

> crowd (unless any are already on this list - Gorry?)

IIRC there was a proposal to contort the UDP checksum to become
something closer to a UDP-lite checksum. The idea was to indicate this
mode by setting a UDP length less than 8, and inferring the actual
length of the UDP payload from the IP total length. Conceptually, this
same hack could be used to add options to UDP.

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Jul 2015 15:29:05 -0700

On 7/10/2015 3:19 PM, Tom Herbert wrote:
> You get UDP data on a UDP socket, so 1400 bytes is returned.

Sure - to the user.

> Returning
> Linux).

You'd keep that within "UDP". If you want to get at that portion, it'd
be like accessing a raw IP socket.

> Besides that, I imagine that HW vendors probably want the

They just want a quick way to find them. ;-)

> same hack could be used to add options to UDP.

Yes, that's what I am proposing. The difference with UDP-lite is that I
would not be returning the extra UDP header option space to the user;
UDP-lite treats that space as "not covered by the checksum" but also
returned to the user.

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 13 Jul 2015 13:42:59 +0200

+1

Now this extra space is for me the place where you put a SPUD header (no matter how this header looks like). I personally was seen SPUD over UDP also as a way to make UDP extensible. So you could also add end-to-end information to SPUD e.g. timestamp information, if these information are useful for different overlaying protocols…

The little 'hack' you describe below is great to address the discover problem: How do I know the other end is SPUD enable…? - I don’t care…

Mirja

> Am 11.07.2015 um 00:29 schrieb Joe Touch <[email-masked]>:
> 
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Jul 2015 08:11:02 -0700

> can''t detect when changes occur easily).
Hi Joe,

Trying to bring up new protocols or features with legacy devices is a
problem that appears in several different contexts. For example we see
this when bringing up IPv6, using UDP on the Internet, running SCTP or
other protocols. In the absence of negotiation with all the relevant
devices or explicit knowledge that all the devices in the path support
the new feature, the typical solution is to try using the feature and
see what the effects are. If we see that packets are being dropped
(lack of acknowledgments) or error messages are seen, then we know
backoff to some "simpler" mode that is known to work. For instance,
use TCP instead of UDP when we see UDP is not making forward progress
for an application (Christian mentioned this in reference to Skype and
gaming protocols). This works as long as devices are dropping packets
because of things they don't understand. Presumably this method could
be employed for hosts to send IP options on the Internet, that is try
sending options and if there are problems stop sending them to that
destination (by definition, options should never required!).

Tom

---

From: Brian Trammell <[email-masked]>
Date: Mon, 20 Jul 2015 13:30:32 +0200

> On 10 Jul 2015, at 18:19, Tom Herbert <[email-masked]> wrote:
> 
> This "new network layer" breaks down at fragmentation.

One can argue (indeed, I do) that in-network fragmentation is essentially a deprecated feature of the network layer. The current version of IP doesn't support it, and AFAICT avoiding fragmentation is current practice in modern transport protocol design.

> Only the first
> packet might look like IP-UDP-IP options-payload.

This is an intriguing possibility, if there is an advantage to reusing IP options handling code.

> This allows us to
> proposes a similar model,

It looks a lot like innerspace (http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01), too.

> although I don't believe they allow

What does "allow" mean in this context?

> I don't understand what the issue is with crypto here.

We want the transport protocol headers to be encrypted, in order to enforce the network/transport layer boundary. (That's what I would mean by "allow". :) )

> SSL/TLS are widely deployed with use of NAT,

...which allows mucking about in the transport layer, and using *all* transport layer metadata to track/fingerprint/etc.

> and we are certainly using encrypted

My understanding of most deployed encrypted tunnels which (also) use tunnel-mode IPsec is that it has a fallback to a UDP encap to handle NAT, but I could be mistaken there.

Cheers,

Brian

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Jul 2015 09:22:38 -0700

On 7/20/2015 4:30 AM, Brian Trammell wrote:
>>> It does seem to me that what we're (the we that wrote the two 
>>> documents starting this thread) trying to do is explicitly
>>> reinforce the boundary between the network layer and the
>>> transport layer, where this is defined as "things the path needs
>>> to see versus things only endpoints need to see". Asking nicely
>>> (i.e., publishing RFCs) did not work in this case: the transport
>>> ports are de facto part of the network layer now, and short of
>>> blowing the Internet up and starting over I can't see a way to
>>> get them back. So now we are left with enforcing the boundary 
>>> cryptographically, leaving some space in the "new network layer"
>>> (in this case, IP + UDP (for ports) + SPUD) for those things now
>>> commonly done within the network.
>>>
> One can argue (indeed, I do) that in-network fragmentation is
> essentially a deprecated feature of the network layer.

If you think that network devices need to see transport ports, then it
doesn't matter where the fragmentation occurs. Source fragmentation -
which is still very much a part of the network layer, and needs to be* -
causes just as much of a problem.

> The current
> version of IP doesn't support it, and AFAICT avoiding fragmentation is
> current practice in modern transport protocol design.

In-network, yes. Source, no.

> It looks a lot like innerspace (http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01), too.

Yes and no. UDP has a length field, which means it's actually possible
to use space in an IP payload that isn't part of the UDP frame without
compliant UDP implementations breaking.

That's the real issue with innerspace; it's inside the TCP payload.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 20 Jul 2015 09:46:09 -0700

> compliant UDP implementations breaking.

It's a nice possible trick, but it would break the ability to build an
app purely on top of unmodified UDP APIs. Those APIs do not provide you
with the ability to create a UDP packet with UDP payload + "metadata"
payload after the UDP length. So you'd need to get support for this API extensions
again in all OSs and programming language SDKs. 8 years minimum. Worse yet,
there are likely  a good set of firewalls that would drop these packets.

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Jul 2015 09:53:06 -0700

On 7/20/2015 9:46 AM, Toerless Eckert wrote:
> app purely on top of unmodified UDP APIs.

An unmodified UDP API, by definition, would not be able to do anything
except use vanilla UDP.

> Those APIs do not provide you
> again in all OSs and programming language SDKs. 8 years minimum. 

It didn't take that long for MPTCP.

> Worse yet,

Firewalls typically either look at UDP ports or part of the UDP content.
It might complicate firewalls that try to parse the entire IP payload as
if it were UDP, i.e., a device that didn't process the UDP length field
correctly. But that's a bug - we really can't build protocols to operate
over devices that do such things.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Jul 2015 16:19:24 -0700

Hi, all,

I just posted a draft on "Transport Options for UDP"

It's tagged as TSVWG for obvious reasons. I encourage those of you
interested in this to discuss it on the TSVWG mailing list.

(although I appreciate it may be useful to SPUD, it's not SPUD-specific).

Joe

-----------------------------------------
A new version of I-D, draft-touch-tsvwg-udp-options-00.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	00
Title:		Transport Options for UDP
Document date:	2015-07-20
Group:		Individual Submission
Pages:		8
URL:
https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-00.txt
Status:
https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-00

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP to provide a
   location, syntax, and semantics for transport layer options.

The IETF Secretariat