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

[Tom Herbert <[e-mail]>]

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.

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

"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



> Brian and Mirja
>
>
>
>> 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