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

[Youjianjie <[e-mail]>]

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:[e-mail]] 代表 Smith, Kevin, (R&D)
> Vodafone Group
> 发送时间: 2015年7月7日 18:53
> 收件人: Tom Herbert; Mirja Kühlewind
> 抄送: Brian Trammell; [e-mail]
> 主题: 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