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

[Szilveszter Nadas <[e-mail]>]

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:[e-mail]] 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; [e-mail]
Subject: Re: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt

Hi Tom, Mirja,

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

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:[e-mail]] On Behalf Of Tom Herbert
Sent: 06 July 2015 18:20
To: Mirja Kühlewind
Cc: Brian Trammell; [e-mail]
Subject: Re: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt

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

_______________________________________________
Spud mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spud
_______________________________________________
Spud mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spud