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

[Brian Trammell <[e-mail]>]

Hi, Tom,

> On 06 Jul 2015, at 19:20, Tom Herbert <[e-mail]> wrote:
> 
> On Fri, Jul 3, 2015 at 8:24 AM, Mirja Kühlewind
> <[e-mail]> wrote:
>> 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.
>> 
> 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.

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.

> 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.

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).

> 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.

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
> makes end-to-end authentication or integrity checks much more
> 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
> 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.
>> 
> 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.

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...

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

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.

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

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.

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

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

>> 
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> Von: [e-mail]
>>> Betreff: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt
>>> Datum: 3. Juli 2015 17:19:10 MESZ
>>> An: "Mirja Kuehlewind" <[e-mail]>ch>, "Mirja Kuehlewind" <[e-mail]>ch>, "Brian Trammell" <[e-mail]>ch>, "Brian Trammell" <[e-mail]>
>>> 
>>> 
>>> 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
>> 
>> _______________________________________________
>> Spud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spud