From nobody Sat Aug 8 02:17:06 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB1D1B2ABF for ; Sat, 8 Aug 2015 02:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHOMA2CVnftI for ; Sat, 8 Aug 2015 02:17:02 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBF61AD372 for ; Sat, 8 Aug 2015 02:17:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3168ED9305; Sat, 8 Aug 2015 11:17:00 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QuqoVb8r3yfz; Sat, 8 Aug 2015 11:16:59 +0200 (MEST) Received: from [192.168.178.33] (x5f716afa.dyn.telefonica.de [95.113.106.250]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BB05DD9302; Sat, 8 Aug 2015 11:16:58 +0200 (MEST) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 8 Aug 2015 11:16:57 +0200 Message-Id: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> To: spud@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Ted Hardie , "Black, David" , Eric Rescorla , Joe Hildebrand , Jana Iyengar , Brian Trammell , Ken Calvert Subject: [Spud] Questions based on draft-trammell-spud-req-00 X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 09:17:05 -0000 Hi all, based on the discussion in section of draft-trammell-spud-req-00, we = (the current group of authors) have phrased some questions we would like = get further feedback from you! For some/most questions we already provided an answer which reflects = part of the discussions we had on this so far. However, none of the = provided answers are final and in a couple of cases we also don=E2=80=99t = have consensus between the small group of us authors. To further proceed = here we would like to get more input from the broader community to = hopefully find a way to evolve! Please go ahead and provide feedback to some or all of the questions! If = you want to further discuss only one aspect of the questions below, = please think about changing the subject of your mail, such that we have = a chance to separate different discussions. Thanks and have a nice weekend! Mirja =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 1) Tradeoffs in tube identifiers ---- a) What the scope of a tube? Is the tube scoped to the 5-tuple, 4-tuple, = or even 3-tuple or can even two different flows have the same tube ID = (privacy vs. mobility)? =E2=80=94> 5-tuple, with unidirectional the default. Note that this = means the tube-id itself cannot be used to do mobility. A return flow = may use the same tube-id, if it wants to signal that it is part of the = same exchange, but it is not required to do so.=E2=80=8B (5-tuple + tube = id =3D 6-tuple; maybe 7-tuples for per-path-element communication as = well?) b) Does SPUD need to send a start message for each tube (independent of = the semantics or the overlying protocol)? =E2=80=94> Yes, e.g. if you have multiple MPTCP subflows each has its = own tube ID. However, maybe this is should only be aSHOULD. It's a = useful message when you expect it to be used to start initiating state = in middleboxes, but there may=E2=80=8B be conditions where the treatment = requested for the flow means that this is not required. c) Can one packet have more than one tube ID? =E2=80=94> No 2) Property binding --- a) Should it be possible to bind properties (only) to a tube or (also) = to single packets? =E2=80=94> Only to a tube. If you need to have a packet that should = have different treatment, it needs a new tube-id.=E2=80=8B Therefore = start new tube should be cheap. b) Can properties bound to a tube be changed later on during the = connection? -> Probably not. Also start a new tube in this case as new tube should = be cheap. 3) Tradeoffs in integrity protection --- a) Should SPUD provide support to use the authentication mechanism of = the overlying transport for SPUD information provided by an endpoint to = check the authenticity and integrity when the information arrive at the = other endpoint? =E2=80=94> Yes, if supported by the overlying protocol b) How can packet-mangling (middleboxes changing accidental or = intentionally information provided by others, both middblebox and = endpoints) by on-path ndes be detected? -> Lying can potentially be detected if information can be verify over a = different mechanism. However it might not be possible to detect who = provided these wrong information. Off-path devices would need to know = the tube id to provide wrong information which may be unlikely. =E2=80=8B=20 c) If a trust relationship already exists that would allow to = authenticate information provided by a middlebox, does SPUD need to = provided further support for this case?=20 -> Yes? (Similar as question a) d) Is there a value in SPUD having its own (encrypted) end-2-end = channel? -> Not fully clear yet, maybe not; Encrypted end-2-end infos can either = be handled by the overlying (encrypted) protocol, or an encryption = boundery within SPUD to provided end-2-end information we can be = commonly used by multiple protocols. However (encrypted) end-2-end = information might be an own overlying protocol (maybe even another shim = layer) and not SPUD itself. 4) Return routability and feedback =E2=80=94- a) 2WHS vs. 3WHS? =E2=80=94> SPUD should/must (?) provide a 2WHS, that means an ACK in = response to the initial packet should be generated by SPUD even if the = overlying protocol does not support this semantic. Note this mean the = ACK may only have a SPUD header but no overlying protocol data. This = would make all SPUD flows/tubes bidirectional. Further SPUD should also = provided the semantics for an 3WHS but may only send a third packet if = the overlying protocol implements it or there is another reason for the = application to explicitly request a SPUD-only 3WHS. b) Does the semantics of the SPUD protocol need to provide an explicit = start signal as well as start/ack signal? -> Yes, start is needed to distinguish start and middle of a tube; ack = is needed to finally set up state. However, not clear yet if all SPUD = tubes MUST send a start signal or only SHOULD. If a start was received, = however, a ACK must be sent=E2=80=A6? c) Should it be possible to send multiple START signal on the same tube = (e.g to re-initiate state)? -> Not clear if this is really needed c) Is a stop flag needed/useful? =E2=80=94> Yes (faster state tear-down), but the overlying protocol must = be resilient to it not being sent, not being received.=E2=80=8B 5) In-band, out-of-band, piggybacked, and interleaved signaling =E2=80=94- a) Do all packets of a flow (where one packet already has a spud header) = need to have a SPUD header or could there be single packets in an = spud-enabled flow that don=E2=80=99t have one? -> Not clear; maybe not and packets on the five-tuple that don't have a = tube identifier aren't assigned any tube.=E2=80=8B b) Do all SPUD packets need to have overlying protocol data? =E2=80=94> No, e.g. start packet c) Do all SPUD information have to fit into one packet? =E2=80=94> probably yes (and other should be out-of-band using an = overlying transport) but not clear yet d) Can a middlebox generate SPUD packets? -> not clear yet, alternative is that the endpoint provides a = place-holder that can be filled by middlebox (and reflected by the = receiving endpoint) which implies all middlebox information need to be = requested by the sending endpoint; probably doesn=E2=80=99t work for = e.g. error messages and therefore the system must allow them to generate = them, but we also have to recognize that they may be consumed by the = path before reaching their intended destination.=E2=80=8B Further it = makes it difficult to do async signaling of changes. We at least need the ability for path elements to send pdec's when = they've got the capability. e) Can a middlebox request application declaration information from an = endpoint and/or provide unrequested path declaration information? -> Not clear yet, to avoid amplification attacks maybe apply the packet = conservation principle here, e.g. a middlebox can generate a packet/an = error message if it drops a packet..? f) Should middlebox information be reflected over the receiver or can = they also be send directly to the sender (and might take a different = route)? -> Maybe there should be a possibility to sent directly to the sender; = for unidirectional flows the receiver may not have a bearer flow to = carry the message back and thus would generate spud-only packets which = maybe quite a bit overhead. However reflection over the receiver should = be preferred. g) Must SPUD information be provided reliably or are those information = always unreliable? -> hopefully unreliable is enough as we want an incrementally deployable = solution From nobody Mon Aug 10 00:28:28 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C620C1ACD11 for ; Mon, 10 Aug 2015 00:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.511 X-Spam-Level: X-Spam-Status: No, score=-11.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ygfb8iYENwbT for ; Mon, 10 Aug 2015 00:28:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16991ACD0D for ; Mon, 10 Aug 2015 00:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14210; q=dns/txt; s=iport; t=1439191703; x=1440401303; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=i/AGIZIeVEIoXqoEhnz2uNO7Lrvq3xmJNcmwGW3Vyh0=; b=TDG7MTEfYLXCE4OIuANaqqGJaAQZGxpeg7P4OP2dk/JPpWJICIo3wAWL 1xotk3G8giBOAWQNNYERYImj+hYYLuFM+13jLs4AkTCW701K1oB56mpZL 83OldgHllacpzXDXN15IaRcDTP1gR2LQWI2aZdaB2sx1MCRpNxx6+G2/1 8=; X-IronPort-AV: E=Sophos;i="5.15,643,1432598400"; d="scan'208";a="17206156" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 10 Aug 2015 07:28:23 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t7A7SMCa000535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 07:28:22 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7A7SK3Y008518; Mon, 10 Aug 2015 00:28:21 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7A7SJEn008517; Mon, 10 Aug 2015 00:28:19 -0700 Date: Mon, 10 Aug 2015 00:28:19 -0700 From: Toerless Eckert To: Mirja =?iso-8859-1?Q?K=FChlewind?= Message-ID: <20150810072819.GH1667@cisco.com> References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Ted Hardie , "Black, David" , Eric Rescorla , Joe Hildebrand , spud@ietf.org, Jana Iyengar , Ken Calvert , Brian Trammell Subject: Re: [Spud] Questions based on draft-trammell-spud-req-00 X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 07:28:26 -0000 On Sat, Aug 08, 2015 at 11:16:57AM +0200, Mirja Kühlewind wrote: > Please go ahead and provide feedback to some or all of the questions! If you want to further discuss only one aspect of the questions below, please think about changing the subject of your mail, such that we have a chance to separate different discussions. > > ????????????????????????????????????????????? > 1) Tradeoffs in tube identifiers > ---- > > a) What the scope of a tube? Is the tube scoped to the 5-tuple, 4-tuple, or even 3-tuple or can even two different flows have the same tube ID (privacy vs. mobility)? > ???> 5-tuple, with unidirectional the default. Note that this means the tube-id itself cannot be used to do mobility. A return flow may use the same tube-id, if it wants to signal that it is part of the same exchange, but it is not required to do so.??? (5-tuple + tube id = 6-tuple; maybe 7-tuples for per-path-element communication as well?) My preference for Tube-ID is to identify a single bidirectional multipath or mobile transport connection consisting of one or more 5-tuple flows between two endpoints. I can't see how we could have network elements understand multipath/mobile connections without such a common identification. Sure, this means SPUD would need to define a common multipath/mobility layer, but thats a good thng. And this can be done incrementally. SPUD can start first defining just single 5-tuple mechanisms, as long as w don't block the way to make it support multipath/mobility. And transport protocols like MP-TCP that want to continue work unchanged can always choose different Tube-IDs for their different 5-tuples. Likely at future loss of best interaction with the network though. Unidirectional, you have to specify what you really want: a) SPUD signaling is built such that a network device only seeing a single direction of the flow (asymmetric routing as common in the internet) still gets all SPUD signaling information. For example, each endpoint could just reflect the other sides last SPUD message. I think this is useful but difficult, and current midpoints don't expect to be able to work under these conditions anyhow. SO it might be a useful value add to make midpoints support SPUD.. b) SPUD signaling is bidirectional but allows to identify separate information for both direction. I definitely think this is useful, but i don't see why both directions would need separate Tube-IDs. c) SPUD signaling is unidirectional only for a unidirectional only traff flow. This makes things quite difficult, especially anything security. I would reserve thinking about purely unidirectional signaling for multicast if you ever want to support that - because those flows are intrinsically unidirectional. In Unicast i wouldn't bother. > b) Does SPUD need to send a start message for each tube (independent of the semantics or the overlying protocol)? > ???> Yes, e.g. if you have multiple MPTCP subflows each has its own tube ID. However, maybe this is should only be aSHOULD. It's a useful message when you expect it to be used to start initiating state in middleboxes, but there may??? be conditions where the treatment requested for the flow means that this is not required. Well, with my preference there needs to be a start message for every 5-tuple of a Tube-ID. > c) Can one packet have more than one tube ID? > ???> No Ack. > 2) Property binding > --- > > a) Should it be possible to bind properties (only) to a tube or (also) to single packets? > ???> Only to a tube. If you need to have a packet that should have different treatment, it needs a new tube-id.??? Therefore start new tube should be cheap. > > b) Can properties bound to a tube be changed later on during the connection? > -> Probably not. Also start a new tube in this case as new tube should be cheap. The ICE/RTCweb experience is quite clear that we need to minimize the in-network flow-state requirements, so opening up multiple tubes for a potential large number of sub-flows is not an option. Network devices have per-flow and per-packet operations. SPUD must allow to exploit both of those capabilities. If SPUD continues to be a layer with per-packet overhead (header), it would be a big waste of such a layer to not have per-packet properties but only per-flow properties. In that case SPUD should not have per-packet header, but just some additional packets carrying flow properties, eg: in the way some of our drafts proposed to expand STUN/ICE signalling. > 3) Tradeoffs in integrity protection > --- > a) Should SPUD provide support to use the authentication mechanism of the overlying transport for SPUD information provided by an endpoint to check the authenticity and integrity when the information arrive at the other endpoint? > ???> Yes, if supported by the overlying protocol Yes. > b) How can packet-mangling (middleboxes changing accidental or intentionally information provided by others, both middblebox and endpoints) by on-path ndes be detected? > -> Lying can potentially be detected if information can be verify over a different mechanism. However it might not be possible to detect who provided these wrong information. Off-path devices would need to know the tube id to provide wrong information which may be unlikely. > ??? SPUD SHOULD/MUST have a way for middleboxes to officially insert/modify information as a way of explicit communication from network to endpoint. Together with 3a) this means something like: There is immutable and mutable SPUD information/signaling elements. middleboxes are only allowed to touch/create mutable elements. Higher layer transport authenticity/integrity checks will only include the immutable SPUD information. Trust relationship between the middlebox and the endpoints (if necessary) is done through different ways. > c) If a trust relationship already exists that would allow to authenticate information provided by a middlebox, does SPUD need to provided further support for this case? > -> Yes? (Similar as question a) Yes would be lovely, but i can't come up with a good example of this right now, and i wouldn't want to burden SPUD with stuff i have no idea on how to do ;-) > d) Is there a value in SPUD having its own (encrypted) end-2-end channel? > -> Not fully clear yet, maybe not; Encrypted end-2-end infos can either be handled by the overlying (encrypted) protocol, or an encryption boundery within SPUD to provided end-2-end information we can be commonly used by multiple protocols. However (encrypted) end-2-end information might be an own overlying protocol (maybe even another shim layer) and not SPUD itself. Rule of thumb is not to re-invent security solutions unnecessary. To me this means i'd first look in how to make SPUD work with dTLS, and it seems most easy to use SPUD as an underlay and figure out how to include the immutable pieces of SPUD into the dTLS security layer and the mutable not. Once we have such a solution i wonder what else we'd be missing. (beside middlebox<->endpoint trust/authentication of course, but thats a different matter). > 4) Return routability and feedback > ???- > > a) 2WHS vs. 3WHS? > ???> SPUD should/must (?) provide a 2WHS, that means an ACK in response to the initial packet should be generated by SPUD even if the overlying protocol does not support this semantic. Note this mean the ACK may only have a SPUD header but no overlying protocol data. This would make all SPUD flows/tubes bidirectional. Further SPUD should also provided the semantics for an 3WHS but may only send a third packet if the overlying protocol implements it or there is another reason for the application to explicitly request a SPUD-only 3WHS. I think we want 3WHS for two reasons: a) Allow upper layer protocols that use 3WHS to include their 3WHS metadata into SPUD 3WHS to make SPUD as RTT efficient as any protocols it carries - while still allowing middleboxes to just have to deal with a single 3WHS of SPUD. b) Leverage 3WHS to do happy eyeballs / (multipath) selection correctly: You start off exploring potentially in parallel multiple 5-tuples with SYN/SYN-ACK and then the initiator sends the ACK only for those 5-tuples(s) it wants to use. > b) Does the semantics of the SPUD protocol need to provide an explicit start signal as well as start/ack signal? > -> Yes, start is needed to distinguish start and middle of a tube; ack is needed to finally set up state. However, not clear yet if all SPUD tubes MUST send a start signal or only SHOULD. If a start was received, however, a ACK must be sent???? I'd make it a MUST because it looks easier. I can't see how SHOULD would make it easier. > c) Should it be possible to send multiple START signal on the same tube (e.g to re-initiate state)? > -> Not clear if this is really needed a) Start per (Tube-ID,5-tuple). b) re-start: rerouting makes a tube go across a firewall middlebox that has no tube-id state. It should be allowed to modify drop packets and send SPUD-ICMP "re-start". This would trigger re-start process (eg: 3WHS repeat). > c) Is a stop flag needed/useful? > ???> Yes (faster state tear-down), but the overlying protocol must be resilient to it not being sent, not being received.??? Sure. > 5) In-band, out-of-band, piggybacked, and interleaved signaling > ???- > > a) Do all packets of a flow (where one packet already has a spud header) need to have a SPUD header or could there be single packets in an spud-enabled flow that don???t have one? > -> Not clear; maybe not and packets on the five-tuple that don't have a tube identifier aren't assigned any tube.??? See above. If you don't want to support per-packet attributes, then you can go with a model that we started with STUN -SPUD is just signaling packets identifies by a signature in the packet and data packets of the same 5 tuple(s) are not encumbered. I did vote for per-packet signaling capability. > b) Do all SPUD packets need to have overlying protocol data? > ???> No, e.g. start packet Right. > c) Do all SPUD information have to fit into one packet? > ???> probably yes (and other should be out-of-band using an overlying transport) but not clear yet per-packet SPUD header should be small, eg<= 64 byte. SPUD signaling only packets can be up to 1280. total amount of per-tube signaling information could exceed 1280 by being split up across multiple SPUD signaling only packets, but not sure if thats needed any time soon. > d) Can a middlebox generate SPUD packets? > -> not clear yet, alternative is that the endpoint provides a place-holder that can be filled by middlebox (and reflected by the receiving endpoint) which implies all middlebox information need to be requested by the sending endpoint; probably doesn???t work for e.g. error messages and therefore the system must allow them to generate them, but we also have to recognize that they may be consumed by the path before reaching their intended destination.??? Further it makes it difficult to do async signaling of changes. SPUD-ICMP: Do what we should (according to IETF architecture) do with ICMP via SPUD-ICMP messages so that SPUD stacks/apps can rely on their non-privileged UDP (SPUD) sockets to send/receive those SPUD-ICMP. I'd like to say: by default, don't come up with SPUD-ICMP messages/message-exchange that would not be permitted as ICMP messages. But the current thinking of what ICMP should be permitted to do may be too stringent. Eg: wonder if in my above SPUD-ICMP "re-start" message would be permitted to be sent as ICMP not to the originator of the filtered packet but the recipient... > We at least need the ability for path elements to send pdec's when they've got the capability. 'pdec' ? > e) Can a middlebox request application declaration information from an endpoint and/or provide unrequested path declaration information? > -> Not clear yet, to avoid amplification attacks maybe apply the packet conservation principle here, e.g. a middlebox can generate a packet/an error message if it drops a packet..? Lets be clear about responsibilties here: Middleboxes such as HTTP proxies break packet conservation all the time when operating at transport flow level (eg: additional HTTP/HTML headers etc..). Nobody blames TCP. SPUD will not force middleboxes to do any amplification. If a middlebox chooses to do so, its in its realm of responsiblity to protect itself and the good endpoints against those attacks. So yes, middleboxes can request additional information, but SPUD does not fore them to. And we can reuse a bunch of the ideas we'd put into prior protocol work to minimize the need to do so. > f) Should middlebox information be reflected over the receiver or can they also be send directly to the sender (and might take a different route)? > -> Maybe there should be a possibility to sent directly to the sender; for unidirectional flows the receiver may not have a bearer flow to carry the message back and thus would generate spud-only packets which maybe quite a bit overhead. However reflection over the receiver should be preferred. Not sure i mean what "reflection to receiver" means. IMHO: middlebox adds information as mutable data to existing SPUD packet, eg: 3WHS SYN. receiver then reflects thast information back to sender. Flow can perfectly be unidirectional, SPUD does not care, SPUD expects bidirectional signaling. > g) Must SPUD information be provided reliably or are those information always unreliable? > -> hopefully unreliable is enough as we want an incrementally deployable solution Is TCP 3WHS reliable ? Same thing. Aka: as long as we have something like a middlebox "re-start" to re-request information (both from middleboxes and endpoints), i am sure we can come up with the most lightweight soft-state approach. Cheers Toerless > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon Aug 10 10:53:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C1B1B2D19 for ; Mon, 10 Aug 2015 10:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxdKs-N12JBf for ; Mon, 10 Aug 2015 10:53:08 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EECA1B2D0D for ; Mon, 10 Aug 2015 10:52:50 -0700 (PDT) Received: by wicne3 with SMTP id ne3so31536074wic.0 for ; Mon, 10 Aug 2015 10:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=OXjHPviadzQhSYvMe0x7aZCjHcT6DJZ34WTCup9LnwI=; b=SU8ZsOpzGF440H/iz3f3jyH/qiFVYUVNXvDOSSEmGsnOwFuPOhxhFSuGlrRLIYLlmF qsNwMtu1gP6NJn5+WWR3XXetK76T279QH1jSz2h8DWZU3FGnXDh2D0PaesxoW0E4BzmQ q4r03aDbixm7n2Sd/Jj0/49otg6y6dp7/Etn/nuIxB44Dfdld0WfPOmCJ9mB4OvUfJL0 NMMqQ5ML96HVFeBgGqPaM7KbqzM3U3hgAb9B+tcHY6NgqkqumXFaHS63ve/SfPX7+Q42 xMunTKTzzZcgflj56+2hxXk39LAalpzDYU1C/0oTnmE0UAMHPfc4Gs+XmapbZT01EPx0 ILaw== MIME-Version: 1.0 X-Received: by 10.194.108.232 with SMTP id hn8mr45792430wjb.154.1439229169350; Mon, 10 Aug 2015 10:52:49 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Mon, 10 Aug 2015 10:52:49 -0700 (PDT) Date: Mon, 10 Aug 2015 10:52:49 -0700 Message-ID: From: Ted Hardie To: Toerless Eckert Content-Type: multipart/alternative; boundary=047d7bf198a063c183051cf8a74d Archived-At: Cc: Eric Rescorla , "Black, David" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Joe Hildebrand , "spud@ietf.org" , Jana Iyengar , Ken Calvert , Brian Trammell Subject: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:53:11 -0000 --047d7bf198a063c183051cf8a74d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, I've split off a small chunk here to focus on the multipath/mobility question. On Mon, Aug 10, 2015 at 12:28 AM, Toerless Eckert wrote: > > My preference for Tube-ID is to identify a single bidirectional multipath > or > mobile transport connection consisting of one or more 5-tuple flows betwe= en > two endpoints. > > =E2=80=8BFirst, I'm guessing that you want a single tube-id for multiple fl= ows because you want to tell the network that they are part of a single, multipath whole. If I have guessed that wrong and you have a different view, can you please explain?=E2=80=8B > I can't see how we could have network elements understand multipath/mobil= e > connections without such a common identification. Sure, this means SPUD > would > need to define a common multipath/mobility layer, but thats a good thng. > > =E2=80=8BI think we need to understand what the network will do with this information. At the moment, if SPUD can tell the network something about the treatment desired (e.g. drop preferred over buffering) and tell it that about a specific flow, I think we have made progress in being more explicit. But telling the network something like "this flow and that flow are related in that some higher layer would see them as part of the same stream" doesn't actually directly help any particular network element know what to do. It may infer what to do based on the idea of multipath, but it seems generally more effective to be direct. If you can be direct, to put this another way, there is no need to leak to the network element anything about the shape of the flow. The same seems to me true for the mobility case. The layer at which to do session replacement seems to me the encrypted transport above SPUD; that provides better confidentiality. Now, if the API allows that higher layer to know what SPUD identifiers were assigned, then it may exercise the session replacement by saying "This new tube replaces the former tube identified by tube-id:XXX", but that has to be said in the cryptographically protected session and backed by something else (shared cryptographic credentials with the previous tube, most likely) to be accepted. But the use of a tube-id there is just an optimization for the higher layer protocol not generating its own identifiers, and it is completely opaque to SPUD itself. > And this can be done incrementally. SPUD can start first defining just > single 5-tuple mechanisms, as long as w don't block the way to make it > support > multipath/mobility. > > And transport protocols like MP-TCP that want to continue work unchanged > can always choose different Tube-IDs for their different 5-tuples. Likel= y > at future loss of best interaction with the network though. > > Unidirectional, you have to specify what you really want: > > a) SPUD signaling is built such that a network device only seeing a singl= e > direction of the flow (asymmetric routing as common in the internet) > still gets all SPUD signaling information. > > =E2=80=8BIf by "all" you mean "all of it passing it", then sure; if you m= ean "all" as in anything related to the tube, then I don't agree. If I relate information about the=E2=80=8B tube that is consumed by a path element on t= he forward path, then I don't see why it would be echoed to the reverse path at all. > For example, each endpoint > could just reflect the other sides last SPUD message. I think this is > useful but difficult, and current midpoints don't expect to be able to > work under these conditions anyhow. SO it might be a useful value add > to make midpoints support SPUD.. > > =E2=80=8BI don't think I understand what value you think there is here. > b) SPUD signaling is bidirectional but allows to identify separate > information for both direction. > > I definitely think this is useful, but i don't see why both directions > would need separate Tube-IDs. > > c) SPUD signaling is unidirectional only for a unidirectional only traff > flow. > > This makes things quite difficult, especially anything security. I > would reserve thinking about purely unidirectional signaling for multicas= t > if you ever want to support that - because those flows are intrinsically > unidirectional. In Unicast i wouldn't bother. > > =E2=80=8BI find myself on the complete opposite end of this--I think app-= to-path signalling is inherently unidirectional for unicast traffic. You may have very different path requests for forward and reverse paths and you may have unidirectional unicast flows. regards, Ted=E2=80=8B --047d7bf198a063c183051cf8a74d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

I've split off= a small chunk here to focus on the multipath/mobility question.
<= div class=3D"gmail_extra">
On Mon, Aug 10, 20= 15 at 12:28 AM, Toerless Eckert <eckert@cisco.com> wrote:
=

My preference for Tube-ID is to identify a single bidirectional multipath o= r
mobile transport connection consisting of one or more 5-tuple flows between=
two endpoints.


=E2=80=8BFirst, I'm guessing that y= ou want a single tube-id for multiple flows because you want to tell the ne= twork that they are part of a single, multipath whole.=C2=A0 If I have gues= sed that wrong and you have a different view, can you please explain?=E2=80= =8B

=C2=A0
I can't see how we could have network elements understand multipath/mob= ile
connections without such a common identification. Sure, this means SPUD wou= ld
need to define a common multipath/mobility layer, but thats a good thng.

=E2=80=8BI think we need to understand = what the network will do with this information.=C2=A0 At the moment, if SPU= D can tell the network something about the treatment desired (e.g. drop pre= ferred over buffering) and tell it that about a specific flow, I think we h= ave made progress in being more explicit.=C2=A0 But telling the network som= ething like "this flow and that flow are related in that some higher l= ayer would see them as part of the same stream" doesn't actually d= irectly help any particular network element know what to do.=C2=A0 It may i= nfer what to do based on the idea of multipath, but it seems generally more= effective to be direct.=C2=A0 If you can be direct, to put this another wa= y, there is no need to leak to the network element anything about the shape= of the flow.=C2=A0

The same seems to me true for t= he mobility case. The layer at which to do session replacement seems to me = the encrypted transport above SPUD; that provides better confidentiality.= =C2=A0 Now, if the API allows that higher layer to know what SPUD identifie= rs were assigned, then it may exercise the session replacement by saying &q= uot;This new tube replaces the former tube identified by tube-id:XXX",= but that has to be said in the cryptographically protected session and bac= ked by=C2=A0 something else (shared cryptographic credentials with the prev= ious tube, most likely) to be accepted. But the use of a tube-id there is j= ust an optimization for the higher layer protocol not generating its own id= entifiers, and it is completely opaque to SPUD itself.
=C2=A0
And this can be done incrementally. SPUD can start first defining just
single 5-tuple mechanisms, as long as w don't block the way to make it = support
multipath/mobility.

And transport protocols like MP-TCP that want to continue work unchanged can always choose different Tube-IDs for their different 5-tuples.=C2=A0 Li= kely
at future loss of best interaction with the network though.

Unidirectional, you have to specify what you really want:

a) SPUD signaling is built such that a network device only seeing a single<= br> direction of the flow (asymmetric routing as common in the internet)
still gets all SPUD signaling information.

=E2=80=8BIf by "all" you mean &qu= ot;all of it passing it", then sure; if you mean "all" as in= anything related to the tube, then I don't agree.=C2=A0 If I relate in= formation about the=E2=80=8B tube that is consumed by a path element on the= forward path, then I don't see why it would be echoed to the reverse p= ath at all.
=C2=A0
For example, each endpoint
could just reflect the other sides last SPUD message. I think this is
useful but difficult, and current midpoints don't expect to be able to<= br> work under these conditions anyhow. SO it might be a useful value add
to make midpoints support SPUD..

=E2=80=8BI don't think I understand wha= t value you think there is here.
=C2=A0
b) SPUD signaling is bidirectional but allows to identify separate
information for both direction.

I definitely think this is useful, but i don't see why both directions<= br> would need separate Tube-IDs.

c) SPUD signaling is unidirectional only for a unidirectional only traff fl= ow.

This makes things quite difficult, especially anything security. I
would reserve thinking about purely unidirectional signaling for multicast<= br> if you ever want to support that - because those flows are intrinsically unidirectional. In Unicast i wouldn't bother.

=E2=80=8BI find my= self on the complete opposite end of this--I think app-to-path signalling i= s inherently unidirectional for unicast traffic.=C2=A0 You may have very di= fferent path requests for forward and reverse paths and you may have unidir= ectional unicast flows.

regards,

Ted=E2=80=8B

--047d7bf198a063c183051cf8a74d-- From nobody Mon Aug 10 11:27:55 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90B1B3BFC for ; Mon, 10 Aug 2015 11:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEqHx5R4_zp0 for ; Mon, 10 Aug 2015 11:27:51 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6F61B3B2C for ; Mon, 10 Aug 2015 11:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5474; q=dns/txt; s=iport; t=1439231210; x=1440440810; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sG1BeXAdrs4MDJgsuecYhF8TLpLA/thfPMEw/J1Ozi4=; b=WqDMwxIYPOE1KFg//mODqIrkWE5yUG9pJiX7xwVs4ak7PlpWQlvNX5Zk DHX7aEOliAno3JfjeBvu1A9Fi7a3RbRdrZ6CCDTVKWQKJtjHJ2P+HyIjU 4TkHF4OF3TpunJr6y4EU1rKJbI1jKZsQToShJbBbRotX099UAMWI7afx8 o=; X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="scan'208";a="177388495" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Aug 2015 18:26:50 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7AIQnCp012918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 18:26:49 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7AIQnBP015167; Mon, 10 Aug 2015 11:26:49 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7AIQmZb015164; Mon, 10 Aug 2015 11:26:48 -0700 Date: Mon, 10 Aug 2015 11:26:48 -0700 From: Toerless Eckert To: Ted Hardie Message-ID: <20150810182648.GU1667@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Eric Rescorla , "Black, David" , Mirja =?iso-8859-1?Q?K=FChlewind?= , Joe Hildebrand , "spud@ietf.org" , Jana Iyengar , Ken Calvert , Brian Trammell Subject: Re: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:27:53 -0000 On Mon, Aug 10, 2015 at 10:52:49AM -0700, Ted Hardie wrote: > ???First, I'm guessing that you want a single tube-id for multiple flows > because you want to tell the network that they are part of a single, > multipath whole. If I have guessed that wrong and you have a different > view, can you please explain???? Correct guess. > > I can't see how we could have network elements understand multipath/mobile > > connections without such a common identification. Sure, this means SPUD > > would need to define a common multipath/mobility layer, but thats a good thng. > > > ???I think we need to understand what the network will do with this > information. a) Simplification of multi-path/mobility end-to-end operations. The Tube-ID becomes the identifier for the multi-path flow. Its how additional 5-tuples indicate which flow they belong to. (thats pure end-to-end). b) Diagnostics. Operator, management tools, statistics gatherings, troubleshooting. As in: may also help the user if something goes wrong and there is a common layer helping to idenfiy sub-flows of a connection. c) ability to do less per-sub-flow signaling by using state data from another sub-flow. d) Ability to do resource tracking/assignment across a multi-path/mobile flow. > It may infer what to do based on the idea of multipath, but it > seems generally more effective to be direct. If you can be direct, to put > this another way, there is no need to leak to the network element anything > about the shape of the flow. I don't follow. > The same seems to me true for the mobility case. The layer at which to do > session replacement seems to me the encrypted transport above SPUD; that > provides better confidentiality. Look at it the other way: application will try to game the network by using more flows to get more bandwidth. So networks may want to limit number of flows per subscriber or the like (ip-prefix, location, however you want to bucketie flows) to counter that abuse. How do we allow for applications to still do multi-path/mobility without running into the trap of being throttled because they use more flows ? By giving a network visibile identification of a flow that includes mobility/multipath. Thats that the Tube-ID could ideally be IMHO. > Now, if the API allows that higher layer > to know what SPUD identifiers were assigned, then it may exercise the > session replacement by saying "This new tube replaces the former tube > identified by tube-id:XXX", but that has to be said in the > cryptographically protected session and backed by something else (shared > cryptographic credentials with the previous tube, most likely) to be > accepted. But the use of a tube-id there is just an optimization for the > higher layer protocol not generating its own identifiers, and it is > completely opaque to SPUD itself. For the end-to-end operations, use of SPUD signaling elements creates commonality which IMHO is a good thing. And of course it does enable network elements to easie interact with it. > > a) SPUD signaling is built such that a network device only seeing a single > > direction of the flow (asymmetric routing as common in the internet) > > still gets all SPUD signaling information. > > > > ???If by "all" you mean "all of it passing it", then sure; if you mean "all" > as in anything related to the tube, then I don't agree. If I relate > information about the??? tube that is consumed by a path element on the > forward path, then I don't see why it would be echoed to the reverse path > at all. I was not expressing an opinion of whether this should or should not be supported by SPUD, i was just trying to classify an option, so no reason yet to agree or disagree ;-) What i meant to characterize is simple that currently middleboxes only work for TCP if they see packets for both directions of a connection. So a) means features in SPUD that would allow middleboxes to only see one direction of a bidirectional flow and still see all SPUD signaling elements, eg: because each signaling element is reflected back in the other direction (or at least the ones necessary to have a middlebox understand the current state of the connection). > > ???I don't think I understand what value you think there is here. Today the locations for middleboxes are engineered so that they see bidirectional traffic. With this features, middleboxes could more easily be deployed in parts of the topology subject to hot-potato routing. > > ???I find myself on the complete opposite end of this--I think app-to-path > signalling is inherently unidirectional for unicast traffic. You may have > very different path requests for forward and reverse paths and you may have > unidirectional unicast flows. But there is no unidirectional traffic signaling to set up a "connection" even for a unidirectional flow. And even if you want to set up a unidirectional flow, its always one and the same app that owns the sockets for both directions, so it looks a lot more logical to me to have just a single bidirectional Tube-ID and just indicate the characteristics of both directions via different attributes. Another way to look at it: Show me a single transport protocol today that can set up for the same 5 tuple two separate & independent unidirectional flows. I am not aware of any. Why introduce it with SPUD ? Cheers Toerless From nobody Mon Aug 10 11:44:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406CC1B2DA0 for ; Mon, 10 Aug 2015 11:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knhPY3GN81D2 for ; Mon, 10 Aug 2015 11:44:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A961B29CC for ; Mon, 10 Aug 2015 11:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2035; q=dns/txt; s=iport; t=1439232233; x=1440441833; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=MbR6/2YZp4oFO1qaV+JjGV/1N/n+gJs8f5LjxIsRBIE=; b=g8uTm3BLGS1A/W8C+ALpmOLQR/1p2DhAXwYOKoMbxDuVN7e4Lsq53bh0 eKjlpGh8MjFy5UkbsU5EV3fp2ChqgoAkCFnpK4z3SGfJTjkiGJxOeVSzu cMvOYf9v+7EM4Y9XjhXVBnC0Qy8sK/C+4i1ZA7QKsBfuWD8S0sYBNabY6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AoAwCa78hV/5RdJa1dgxuBPb03CYd+AoE2OBQBAQEBAQEBgQqEIwEBAQMBOisJBAcFCwsYCSUPBUkTiCYIz3ABAQEBAQEBAQEBAQEBAQEBAQEBAQEXi1GEMQ1LB4MYgRQFjUmHQoxgA5l9JoIPHBWBXh4zgQaBRgEBAQ X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="scan'208";a="23078389" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Aug 2015 18:43:52 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t7AIhpgn021861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 18:43:52 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7AIhp46016262; Mon, 10 Aug 2015 11:43:51 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7AIhpJd016261; Mon, 10 Aug 2015 11:43:51 -0700 Date: Mon, 10 Aug 2015 11:43:51 -0700 From: Toerless Eckert To: Christian Huitema Message-ID: <20150810184351.GA16123@cisco.com> References: <20150810183509.GV1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150810183509.GV1667@cisco.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:44:05 -0000 Sigh... resending. spud@ietf.org mailing list owner hansn't bumped up the Cc limit... On Mon, Aug 10, 2015 at 06:13:28PM +0000, Christian Huitema wrote: > I don't know what Toerless really means, but I am a bit concerned by the use of a "unique identifier" here. Specifically, I am concerned with the privacy implications of using unique identifiers. If the same identifier is used with multiple 5 tuples, then it can be used to tie together these tuples. There are cases when it doesn't matter too much, e.g. when just the client port changed, presumably after a NAT remapping. But if the client IP address changes, the unique identifier provides a neat way to track successive locations of a mobile device. Sure, thats the purpose. As i said too, nobody forces higher layer protocols to reuse the same Tube-ID. They would do it, when it gives any of the benefits that i've listed in my last reply to Ted. > I understand that using a unique identifier simplifies the device greatly. For example, a load balancer can use the unique identifier to ensure that packets are always routed to the "right" context. But we can do better than that. In fact, we should, because without a good alternative protocol designers will just pick the simple design, without worrying too much about privacy. The alternative is to design a privacy preserving way to bind two contexts together. forgot the load balancing example , thanks. > That shouldn't be too hard. For example, the client could send a "tying" parameter encrypted with the server public key, tying the new context to a previous one. But we probably want to start this kind of design sooner rather than later, especially if we care about privacy. Well, the problem with the security is always how to establish a trust relationship between middlebox and endpoints. As i mentioned, there should be some good resistance to reinvent the wheel, but i don't think threre is a good wheel yet. > > -- Christian Huitema -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Aug 10 11:44:49 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100EE1B29C7 for ; Mon, 10 Aug 2015 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0suwnUV9qbb for ; Mon, 10 Aug 2015 11:44:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127F01B29D9 for ; Mon, 10 Aug 2015 11:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1439232285; x=1440441885; h=date:from:to:cc:subject:message-id:mime-version; bh=pW/ydYxqIvFcDFtWUclOJZqrKB+TE32Jm+6LaumA2oY=; b=Blf6sWilmN4GLHLbW9dP0IAPVNf1I++gzDQKl8V9DzJKDI/15aPy3OzG oEEh+a/X2ewaDyzol0ExnEqvvHvBICZBx16Uq4kaRp8DPCCm3lExGGlUl h50tvdnh3fm+9iVQWRWCSLiXFIi2/A+uzLOh7jaWsx3K4ji3nJhhh2tc5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaBQB/8MhV/4ENJK1dgxuBPcU+gTg7EQEBAQEBAQGBCoQmKxM/PBoaBUkTiC7PcAEBAQEBAQQBAQEBAQEBARqQWoMfgRQFjUmHQm6LcgOBSYQlkCmDZiaCQIFeHjOCTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="scan'208";a="17450585" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2015 18:44:45 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7AIiixi010000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 18:44:45 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7AIiiiv016339; Mon, 10 Aug 2015 11:44:44 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7AIiipw016338; Mon, 10 Aug 2015 11:44:44 -0700 Date: Mon, 10 Aug 2015 11:44:44 -0700 From: Toerless Eckert To: Christian Huitema Message-ID: <20150810184444.GB16123@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Cc: spud@ietf.org Subject: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:44:48 -0000 [another resend due to spud mailin list setup, sorry] As a generic side thought based on Christians concern about privacy (why would an app want to show a shared Tube-ID across multipath/mobile flows for example). To me, the problem is best explained on the following workflow: "Here is your new ID card". "Why would i want to have an ID card, everybody who checks ID cards is evil" "You do not have to show your ID card if you don't want to" "Lets go to the bar" "ID card please" "Booze or anonymity... that's the question" "Lets choose booze" So, whats missing in SPUD (or any prior endpoint<->network) signaling is the signaling element "If you do not show ID card, you will not get booze" or "if you do not use a cross-subflow Tube-ID, your load-sharing, mobility or multipath performance will suck or not work". Using the same Tube-ID is just one example. This interaction really applies to any possible signaling element: The anonymity freak will argue to his death that he doesn't want to provide information to the network... unless the network can persuade him that the benefit of showing outweights the loss of anonymity. This is primarily a question of creating a data-model of what the network can offer and tie that to a data model for what to show to get it.... Cheers Toerless -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Aug 10 13:20:41 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8361B3AE5 for ; Mon, 10 Aug 2015 11:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usw7K8LwhuPS for ; Mon, 10 Aug 2015 11:13:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CADE1B3ADF for ; Mon, 10 Aug 2015 11:13:34 -0700 (PDT) Received: from DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) by DM2PR0301MB0783.namprd03.prod.outlook.com (10.160.97.154) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 10 Aug 2015 18:13:30 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 10 Aug 2015 18:13:28 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0225.018; Mon, 10 Aug 2015 18:13:28 +0000 From: Christian Huitema To: Ted Hardie , Toerless Eckert Thread-Topic: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00) Thread-Index: AQHQ05Vw+WSYmKkHj06313z2YHHBGp4FhbrQ Date: Mon, 10 Aug 2015 18:13:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.160.23] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:Wn/3Ai/AIpq0HwH8w8+vgLBMKzQQovBKfHMTyGlUIejYbIIgl5Zj4yLorMLxkPZI2gClMpIedc8P85PoJUoPrTce3x/ga0dJTBYQnE7OsvnGG0bXlx75ETrfOC0zF1jK/zsCM+2Vmrt4jOzPhZAAlw==; 24:dWtwTeObpFP8q9akKIkgE3tMwpjKt08gSBmP+P/4hwsQVqx7WjFNBIHa9yUNIOUz5YmoNxYP1IQqLkjyCcK92NMkrRQbhFg+LEQoraSk09I=; 20:ffcQPTKs3I2t7bc//PTf2HIB9FnD00uQBWu27//t+DPDmFW6+vLQoAreDN5emDmlDuDJ7rtPW/WuaI9O6KfczA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0783; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 06640999CA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(189002)(199003)(74316001)(10290500002)(19580405001)(5003600100002)(5001770100001)(2900100001)(68736005)(97736004)(92566002)(19580395003)(81156007)(5002640100001)(86612001)(5001860100001)(10090500001)(2950100001)(5001960100002)(77156002)(8990500004)(189998001)(62966003)(76576001)(5005710100001)(10400500002)(101416001)(5001830100001)(77096005)(2656002)(105586002)(50986999)(54356999)(4001540100001)(106116001)(76176999)(122556002)(86362001)(33656002)(230783001)(87936001)(66066001)(102836002)(64706001)(106356001)(40100003)(99286002)(46102003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 18:13:28.3734 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0783; 2:paLoipge0ZHTqMPcQcUrRgTxqvA+UKBSwOdZMowOd87ctdewCzK5mjj8UcU3f+qd; 3:N9epN2GW6XEW277C4PFXUfpdUxrmdRlmT9A3tQORwL8HcN76jcI7MijmGzQyPFpRGQbDktyDiQwlQNCDMqjxFaAT8zkB1a7xAF0A+gEHiNMNi003gsj+vd6x1oateJh80VRAymsFVbJXGLTxg1wG1Q==; 25:qiTagXsCfSiONpF+b82HqbSD72IzT0Ht5L+WQ84teLxNaxjnircbnGhUQK0Zwa/QiZ6rLd8e4tXBFcr7TWuIlFun4Hd0JSIDzIodNk40wunfpTgMgPJ9oRedMzm6UIyvgfBDPnZ//mOEgAbeupeb15gzBGmxG6tAXS/xyaefr6vCMZe+OXwPYjbfyzamrLADqvHM9CRU7dvae9boOCXoeGKKtUqWV253F/QifSBtbQgTCq67m6Ft7721sgjzJ5AHfbmtoU1eG8TNmbSbGeTRdw==; 23:nqS2fDvscID+hrb+owW6T+qeCE+uSxVgl39MiuUmqHf1MFGhzGhlWWj6Em7K2Z5U1KgorK5L9opJlU/UMSScxh+IjJ2uz7LtbhhCxsnGFD8Lhtukao1LDmVqJtIL54DqnOF9OFuxDYk0JsuIov0K5/upFh8TyHKbRBT1ojWztNdADeE1yM/cIqeUCjIxoR1XTCdNUhJFk5l4CJDfojzTAWvnie+w+W9DaSXY56MSBEBjusE0FjH5KTLJpHZNj0fn X-OriginatorOrg: microsoft.com Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 13:20:38 -0700 Cc: Eric Rescorla , "Black, David" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Joe Hildebrand , "spud@ietf.org" , Jana Iyengar , Ken Calvert , Brian Trammell Subject: Re: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:13:37 -0000 T24gTW9uZGF5LCBBdWd1c3QgMTAsIDIwMTUgMTA6NTMgQU0sIFRlZCBIYXJkaWUgd3JvdGU6DQoN Cj4gLi4uDQo+IEkndmUgc3BsaXQgb2ZmIGEgc21hbGwgY2h1bmsgaGVyZSB0byBmb2N1cyBvbiB0 aGUgbXVsdGlwYXRoL21vYmlsaXR5IHF1ZXN0aW9uLg0KPg0KPiBPbiBNb24sIEF1ZyAxMCwgMjAx NSBhdCAxMjoyOCBBTSwgVG9lcmxlc3MgRWNrZXJ0IDxlY2tlcnRAY2lzY28uY29tPiB3cm90ZToN Cj4NCj4+IE15IHByZWZlcmVuY2UgZm9yIFR1YmUtSUQgaXMgdG8gaWRlbnRpZnkgYSBzaW5nbGUg YmlkaXJlY3Rpb25hbCBtdWx0aXBhdGggb3INCj4+IG1vYmlsZSB0cmFuc3BvcnQgY29ubmVjdGlv biBjb25zaXN0aW5nIG9mIG9uZSBvciBtb3JlIDUtdHVwbGUgZmxvd3MgYmV0d2Vlbg0KPj4gdHdv IGVuZHBvaW50cy4NCj4NCuKAiz4gRmlyc3QsIEknbSBndWVzc2luZyB0aGF0IHlvdSB3YW50IGEg c2luZ2xlIHR1YmUtaWQgZm9yIG11bHRpcGxlIGZsb3dzIGJlY2F1c2UgeW91IA0KPiB3YW50IHRv IHRlbGwgdGhlIG5ldHdvcmsgdGhhdCB0aGV5IGFyZSBwYXJ0IG9mIGEgc2luZ2xlLCBtdWx0aXBh dGggd2hvbGUuwqAgSWYgSSBoYXZlIA0KPiBndWVzc2VkIHRoYXQgd3JvbmcgYW5kIHlvdSBoYXZl IGEgZGlmZmVyZW50IHZpZXcsIGNhbiB5b3UgcGxlYXNlIGV4cGxhaW4/4oCLDQoNCkkgZG9uJ3Qg a25vdyB3aGF0IFRvZXJsZXNzIHJlYWxseSBtZWFucywgYnV0IEkgYW0gYSBiaXQgY29uY2VybmVk IGJ5IHRoZSB1c2Ugb2YgYSAidW5pcXVlIGlkZW50aWZpZXIiIGhlcmUuIFNwZWNpZmljYWxseSwg SSBhbSBjb25jZXJuZWQgd2l0aCB0aGUgcHJpdmFjeSBpbXBsaWNhdGlvbnMgb2YgdXNpbmcgdW5p cXVlIGlkZW50aWZpZXJzLiBJZiB0aGUgc2FtZSBpZGVudGlmaWVyIGlzIHVzZWQgd2l0aCBtdWx0 aXBsZSA1IHR1cGxlcywgdGhlbiBpdCBjYW4gYmUgdXNlZCB0byB0aWUgdG9nZXRoZXIgdGhlc2Ug dHVwbGVzLiBUaGVyZSBhcmUgY2FzZXMgd2hlbiBpdCBkb2Vzbid0IG1hdHRlciB0b28gbXVjaCwg ZS5nLiB3aGVuIGp1c3QgdGhlIGNsaWVudCBwb3J0IGNoYW5nZWQsIHByZXN1bWFibHkgYWZ0ZXIg YSBOQVQgcmVtYXBwaW5nLiBCdXQgaWYgdGhlIGNsaWVudCBJUCBhZGRyZXNzIGNoYW5nZXMsIHRo ZSB1bmlxdWUgaWRlbnRpZmllciBwcm92aWRlcyBhIG5lYXQgd2F5IHRvIHRyYWNrIHN1Y2Nlc3Np dmUgbG9jYXRpb25zIG9mIGEgbW9iaWxlIGRldmljZS4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgdXNp bmcgYSB1bmlxdWUgaWRlbnRpZmllciBzaW1wbGlmaWVzIHRoZSBkZXZpY2UgZ3JlYXRseS4gRm9y IGV4YW1wbGUsIGEgbG9hZCBiYWxhbmNlciBjYW4gdXNlIHRoZSB1bmlxdWUgaWRlbnRpZmllciB0 byBlbnN1cmUgdGhhdCBwYWNrZXRzIGFyZSBhbHdheXMgcm91dGVkIHRvIHRoZSAicmlnaHQiIGNv bnRleHQuIEJ1dCB3ZSBjYW4gZG8gYmV0dGVyIHRoYW4gdGhhdC4gSW4gZmFjdCwgd2Ugc2hvdWxk LCBiZWNhdXNlIHdpdGhvdXQgYSBnb29kIGFsdGVybmF0aXZlIHByb3RvY29sIGRlc2lnbmVycyB3 aWxsIGp1c3QgcGljayB0aGUgc2ltcGxlIGRlc2lnbiwgd2l0aG91dCB3b3JyeWluZyB0b28gbXVj aCBhYm91dCBwcml2YWN5LiBUaGUgYWx0ZXJuYXRpdmUgaXMgdG8gZGVzaWduIGEgcHJpdmFjeSBw cmVzZXJ2aW5nIHdheSB0byBiaW5kIHR3byBjb250ZXh0cyB0b2dldGhlci4gDQoNClRoYXQgc2hv dWxkbid0IGJlIHRvbyBoYXJkLiBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBjb3VsZCBzZW5kIGEg InR5aW5nIiBwYXJhbWV0ZXIgZW5jcnlwdGVkIHdpdGggdGhlIHNlcnZlciBwdWJsaWMga2V5LCB0 eWluZyB0aGUgbmV3IGNvbnRleHQgdG8gYSBwcmV2aW91cyBvbmUuIEJ1dCB3ZSBwcm9iYWJseSB3 YW50IHRvIHN0YXJ0IHRoaXMga2luZCBvZiBkZXNpZ24gc29vbmVyIHJhdGhlciB0aGFuIGxhdGVy LCBlc3BlY2lhbGx5IGlmIHdlIGNhcmUgYWJvdXQgcHJpdmFjeS4NCg0KLS0gQ2hyaXN0aWFuIEh1 aXRlbWENCg0KDQoNCg0K From nobody Mon Aug 10 13:20:43 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABD41B3C3C for ; Mon, 10 Aug 2015 11:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyg_5pc8gSdb for ; Mon, 10 Aug 2015 11:35:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E045A1B3C1F for ; Mon, 10 Aug 2015 11:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1899; q=dns/txt; s=iport; t=1439231710; x=1440441310; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gaYY6dVrZE0Wvqmcc8nTXQskinOTgDIoPY+ALpB8Mmk=; b=bsfvbwJvzEnuP/br0/eAneJjF9DgsuIkssjXrhK+npSoJzW7IPYBhcie XcW0kBlTD9ER3kxn9pUQpRRLa1dBSS+zrhTgNysg4/Zf/rOJmC6KryoQ+ SL4CSZVJJ+B/q0/KE7BqA68l4WpDxetRNwLY/a4fOzVWBfi3g/BBgaBRX k=; X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="scan'208";a="17440144" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 10 Aug 2015 18:35:10 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t7AIZ9Lo001652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 18:35:10 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7AIZ9h2015670; Mon, 10 Aug 2015 11:35:09 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7AIZ9H1015669; Mon, 10 Aug 2015 11:35:09 -0700 Date: Mon, 10 Aug 2015 11:35:09 -0700 From: Toerless Eckert To: Christian Huitema Message-ID: <20150810183509.GV1667@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 13:20:38 -0700 Cc: Ted Hardie , "Black, David" , Eric Rescorla , Mirja =?iso-8859-1?Q?K=FChlewind?= , Joe Hildebrand , "spud@ietf.org" , Jana Iyengar , Ken Calvert , Brian Trammell Subject: Re: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:35:12 -0000 On Mon, Aug 10, 2015 at 06:13:28PM +0000, Christian Huitema wrote: > I don't know what Toerless really means, but I am a bit concerned by the use of a "unique identifier" here. Specifically, I am concerned with the privacy implications of using unique identifiers. If the same identifier is used with multiple 5 tuples, then it can be used to tie together these tuples. There are cases when it doesn't matter too much, e.g. when just the client port changed, presumably after a NAT remapping. But if the client IP address changes, the unique identifier provides a neat way to track successive locations of a mobile device. Sure, thats the purpose. As i said too, nobody forces higher layer protocols to reuse the same Tube-ID. They would do it, when it gives any of the benefits that i've listed in my last reply to Ted. > I understand that using a unique identifier simplifies the device greatly. For example, a load balancer can use the unique identifier to ensure that packets are always routed to the "right" context. But we can do better than that. In fact, we should, because without a good alternative protocol designers will just pick the simple design, without worrying too much about privacy. The alternative is to design a privacy preserving way to bind two contexts together. forgot the load balancing example , thanks. > That shouldn't be too hard. For example, the client could send a "tying" parameter encrypted with the server public key, tying the new context to a previous one. But we probably want to start this kind of design sooner rather than later, especially if we care about privacy. Well, the problem with the security is always how to establish a trust relationship between middlebox and endpoints. As i mentioned, there should be some good resistance to reinvent the wheel, but i don't think threre is a good wheel yet. > > -- Christian Huitema From nobody Mon Aug 10 13:20:44 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745D11B3C90 for ; Mon, 10 Aug 2015 11:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ocr-8Qc266e for ; Mon, 10 Aug 2015 11:41:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527221B3C81 for ; Mon, 10 Aug 2015 11:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1278; q=dns/txt; s=iport; t=1439232109; x=1440441709; h=date:from:to:cc:subject:message-id:mime-version; bh=QVDZmf11uJ/mm3ywHJLyTQqAA67tkHqYs2WvbK1p0Nw=; b=fk6f7EJqLmdIdnva8qggoWSxdzvl8dmNm/i8hdihvMvYFCpXf86B2G7O JGiK4w2DNsrI61xfBzyVrQBQpQWJMTfe1H3FD2YvNf/HbeprZIBGPQVOK lvJzYA2zEhBNdoDkD/8gHlqYiXbtnIQYmQ4b5Zs7gx03fbLKMmiXbXnH2 Q=; X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="scan'208";a="23012586" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 10 Aug 2015 18:41:48 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t7AIfmcD008912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 18:41:48 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7AIflXN016099; Mon, 10 Aug 2015 11:41:47 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7AIflGO016098; Mon, 10 Aug 2015 11:41:47 -0700 Date: Mon, 10 Aug 2015 11:41:47 -0700 From: Toerless Eckert To: Christian Huitema Message-ID: <20150810184147.GW1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 13:20:38 -0700 Cc: Ted Hardie , "Black, David" , Eric Rescorla , Mirja =?iso-8859-1?Q?K=FChlewind?= , Joe Hildebrand , "spud@ietf.org" , Jana Iyengar , Ken Calvert , Brian Trammell Subject: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:41:50 -0000 As a generic side thought based on Christians concern about privacy (why would an app want to show a shared Tube-ID across multipath/mobile flows for example). To me, the problem is best explained on the following workflow: "Here is your new ID card". "Why would i want to have an ID card, everybody who checks ID cards is evil" "You do not have to show your ID card if you don't want to" "Lets go to the bar" "ID card please" "Booze or anonymity... that's the question" "Lets choose booze" So, whats missing in SPUD (or any prior endpoint<->network) signaling is the signaling element "If you do not show ID card, you will not get booze" or "if you do not use a cross-subflow Tube-ID, your load-sharing, mobility or multipath performance will suck or not work". Using the same Tube-ID is just one example. This interaction really applies to any possible signaling element: The anonymity freak will argue to his death that he doesn't want to provide information to the network... unless the network can persuade him that the benefit of showing outweights the loss of anonymity. This is primarily a question of creating a data-model of what the network can offer and tie that to a data model for what to show to get it.... Cheers Toerless From nobody Mon Aug 10 13:20:45 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A923E1B3CBF for ; Mon, 10 Aug 2015 12:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOnbsbGos5ws for ; Mon, 10 Aug 2015 12:12:14 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8499C1B3CAA for ; Mon, 10 Aug 2015 12:12:13 -0700 (PDT) Received: by wicne3 with SMTP id ne3so148249311wic.1 for ; Mon, 10 Aug 2015 12:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xxEldHxsbt/8QPKNWx3rDvvjcYrpEVN2gf2x0QGO6vw=; b=OzXLpojj03vA6/fZ4iLTAMKZmVcSU3MJ7coPGfq0Ng0XHtUyiScubk7QMJtg0LsSKU RQUMjTWwMk/lDgHK7RyblYYk+cu+mTpporpj/OdZAqw7z1diVgN8oD6AJkkP8oDcdAtR ejqhV3/mV0a9Axvm6YqtRNzf1guS+rS6Z3BKl9yRyDVPMKtxOaHTegQmV86WcPTg56LB 8m60zIzRPZvInCP1bUlF+uvFnnbVaK6HAAtIeEm5yIrwNkchddSzOrzpvYu2P15qANwO W17bPM0NMHAU7OfGQnFQ+ASAX6tZi64kmtjS1yaVm7f+NHkynUzK7FL3gB2jFmsvAkfT /wcg== MIME-Version: 1.0 X-Received: by 10.195.13.200 with SMTP id fa8mr47066563wjd.9.1439233932257; Mon, 10 Aug 2015 12:12:12 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Mon, 10 Aug 2015 12:12:12 -0700 (PDT) In-Reply-To: <20150810184147.GW1667@cisco.com> References: <20150810184147.GW1667@cisco.com> Date: Mon, 10 Aug 2015 12:12:12 -0700 Message-ID: From: Ted Hardie To: Toerless Eckert Content-Type: multipart/alternative; boundary=047d7bb0417247f12b051cf9c322 Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 13:20:38 -0700 Cc: Eric Rescorla , "Black, David" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Joe Hildebrand , "spud@ietf.org" , Christian Huitema , Ken Calvert , Brian Trammell , Jana Iyengar Subject: Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 19:12:15 -0000 --047d7bb0417247f12b051cf9c322 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, On Mon, Aug 10, 2015 at 11:41 AM, Toerless Eckert wrote: > As a generic side thought based on Christians concern about privacy > (why would an app want to show a shared Tube-ID across multipath/mobile > flows for example). > > To me, the problem is best explained on the following workflow: > > "Here is your new ID card". > "Why would i want to have an ID card, everybody who checks ID cards is > evil" > "You do not have to show your ID card if you don't want to" > "Lets go to the bar" > "ID card please" > "Booze or anonymity... that's the question" > "Lets choose booze" > > =E2=80=8BYou've just demonstrated a bad workflow. To drink booze in many jurisdictions, you need to be of a certain age. Associating that age with a token that can be shown (of-booze-consuming-age) is enough to meet the requirement; showing an identity is most assuredly not required. There are states that change your ID card when you pass that age, for example; it is a horizontal picture in one and =E2=80=8Ba vertical in the o= ther. When asked for proof of age, you can show just the picture and be granted entrance, without showing your name, home address, or other identifying characteristics. What we are looking for in SPUD is a set of declarative statements that can be made from the application to the network about the network treatment desired and from the network to the application about the network treatment provided. Anything beyond that is not just surplus to requirements, it's dangerous because you can end up subverting the security properties of the overlying protocol (which is what the application sees and is relying on). My two cents, in any case, Ted > So, whats missing in SPUD (or any prior endpoint<->network) signaling is > the > signaling element "If you do not show ID card, you will not get booze" or > "if you do not use a cross-subflow Tube-ID, your load-sharing, mobility o= r > multipath > performance will suck or not work". > > Using the same Tube-ID is just one example. This interaction really appli= es > to any possible signaling element: The anonymity freak will argue to his > death that he doesn't want to provide information to the network... unles= s > the network can persuade him that the benefit of showing outweights the > loss of anonymity. > > This is primarily a question of creating a data-model of what the network > can offer > and tie that to a data model for what to show to get it.... > > Cheers > Toerless > --047d7bb0417247f12b051cf9c322 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

<= div class=3D"gmail_quote">On Mon, Aug 10, 2015 at 11:41 AM, Toerless Eckert= <eckert@cisco.com> wrote:
= As a generic side thought based on Christians concern about privacy
(why would an app want to show a shared Tube-ID across multipath/mobile flo= ws for example).

To me, the problem is best explained on the following workflow:

"Here is your new ID card".
"Why would i want to have an ID card, everybody who checks ID cards is= evil"
"You do not have to show your ID card if you don't want to" "Lets go to the bar"
"ID card please"
"Booze or anonymity... that's the question"
"Lets choose booze"


=E2=80=8BYou've just demonstrated a= bad workflow.=C2=A0 To drink booze in many jurisdictions, you need to be o= f a certain age.=C2=A0 Associating that age with a token that can be shown = (of-booze-consuming-age) is enough to meet the requirement; showing an iden= tity is most assuredly not required.

There are state= s that change your ID card when you pass that age, for example; it is a hor= izontal picture in one and =E2=80=8Ba vertical in the other.=C2=A0 When ask= ed for proof of age, you can show just the picture and be granted entrance,= without showing your name, home address, or other identifying characterist= ics.

What we are looking for in SPUD is a set of dec= larative statements that can be made from the application to the network ab= out the network treatment desired and from the network to the application a= bout the network treatment provided.=C2=A0 Anything beyond that is not just= surplus to requirements, it's dangerous because you can end up subvert= ing the security properties of the overlying protocol (which is what the ap= plication sees and is relying on).

My two cents, in = any case,

Ted



=C2=A0
So, whats missing in SPUD (or any prior endpoint<->network) signaling= is the
signaling element "If you do not show ID card, you will not get booze&= quot; or
"if you do not use a cross-subflow Tube-ID, your load-sharing, mobilit= y or multipath
performance will suck or not work".

Using the same Tube-ID is just one example. This interaction really applies=
to any possible signaling element: The anonymity freak will argue to his death that he doesn't want to provide information to the network... unl= ess
the network can persuade him that the benefit of showing outweights the
loss of anonymity.

This is primarily a question of creating a data-model of what the network c= an offer
and tie that to a data model for what to show to get it....

Cheers
=C2=A0 =C2=A0 Toerless

--047d7bb0417247f12b051cf9c322-- From nobody Mon Aug 10 13:20:47 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536E11B2EDC for ; Mon, 10 Aug 2015 12:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65IpggtKPRwd for ; Mon, 10 Aug 2015 12:40:26 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5CC1B2ED0 for ; Mon, 10 Aug 2015 12:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3588; q=dns/txt; s=iport; t=1439235628; x=1440445228; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=YfS0Qdw9Aq3BxvbkU4xG23rexqW4jbK8akdhDyQb/3g=; b=QRw3SAOD5byUAkVBKn69IgwsxUu9ymOerpRwpM8NeTQrYQSXcpU0Z8bG WCvGVBmRTnqa4NMn3ItYRZqXH17VEtgfYfqBji0KpD+Esk+FRHkikOzlC zKEPTu73Z6tYF9Xesw/6B2P9wRtKt0guVmwPblNJulohtUAknaTYnwPcZ w=; X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="scan'208";a="177330611" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 10 Aug 2015 19:40:27 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t7AJeP4A022808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 19:40:26 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7AJeJ0R019933; Mon, 10 Aug 2015 12:40:19 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7AJeJgk019930; Mon, 10 Aug 2015 12:40:19 -0700 Date: Mon, 10 Aug 2015 12:40:18 -0700 From: Toerless Eckert To: Ted Hardie Message-ID: <20150810194018.GX1667@cisco.com> References: <20150810184147.GW1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 13:20:38 -0700 Cc: Eric Rescorla , "Black, David" , Mirja =?iso-8859-1?Q?K=FChlewind?= , Joe Hildebrand , "spud@ietf.org" , Christian Huitema , Ken Calvert , Brian Trammell , Jana Iyengar Subject: Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 19:40:28 -0000 ;-) Thanks for detailling the minimum requirements for the example exchange. But my point was really about showing the only after you know why you would have to show it. If i read your reply correctly, you are reconfirming that the current goal in SPUD is to show tokens whether or not they are needed and without knowing what benefit you would get when you show them. Its like carrying that vertical or hirozontal picture card openly without knowing that you'll have a benefit from it. Thats what i think is one of the main reasons why we have this ongoing discussion between privacy and spud sides. If spud had the framework to tell the how what to show and what benefit it would then get, i am arguing the pushback would be a lot smaller. Cheers Toerless On Mon, Aug 10, 2015 at 12:12:12PM -0700, Ted Hardie wrote: > Howdy, > > On Mon, Aug 10, 2015 at 11:41 AM, Toerless Eckert wrote: > > > As a generic side thought based on Christians concern about privacy > > (why would an app want to show a shared Tube-ID across multipath/mobile > > flows for example). > > > > To me, the problem is best explained on the following workflow: > > > > "Here is your new ID card". > > "Why would i want to have an ID card, everybody who checks ID cards is > > evil" > > "You do not have to show your ID card if you don't want to" > > "Lets go to the bar" > > "ID card please" > > "Booze or anonymity... that's the question" > > "Lets choose booze" > > > > > ???You've just demonstrated a bad workflow. To drink booze in many > jurisdictions, you need to be of a certain age. Associating that age with > a token that can be shown (of-booze-consuming-age) is enough to meet the > requirement; showing an identity is most assuredly not required. > > There are states that change your ID card when you pass that age, for > example; it is a horizontal picture in one and ???a vertical in the other. > When asked for proof of age, you can show just the picture and be granted > entrance, without showing your name, home address, or other identifying > characteristics. > > What we are looking for in SPUD is a set of declarative statements that can > be made from the application to the network about the network treatment > desired and from the network to the application about the network treatment > provided. Anything beyond that is not just surplus to requirements, it's > dangerous because you can end up subverting the security properties of the > overlying protocol (which is what the application sees and is relying on). > > My two cents, in any case, > > Ted > > > > > > > So, whats missing in SPUD (or any prior endpoint<->network) signaling is > > the > > signaling element "If you do not show ID card, you will not get booze" or > > "if you do not use a cross-subflow Tube-ID, your load-sharing, mobility or > > multipath > > performance will suck or not work". > > > > Using the same Tube-ID is just one example. This interaction really applies > > to any possible signaling element: The anonymity freak will argue to his > > death that he doesn't want to provide information to the network... unless > > the network can persuade him that the benefit of showing outweights the > > loss of anonymity. > > > > This is primarily a question of creating a data-model of what the network > > can offer > > and tie that to a data model for what to show to get it.... > > > > Cheers > > Toerless > > -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Aug 10 13:20:50 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3B71B3A65 for ; Mon, 10 Aug 2015 13:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m1AYlhvJbve for ; Mon, 10 Aug 2015 13:02:41 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A281C1A88D7 for ; Mon, 10 Aug 2015 13:02:40 -0700 (PDT) Received: by wicne3 with SMTP id ne3so35359855wic.0 for ; Mon, 10 Aug 2015 13:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=drQ3mQwocHyeWr5ADNPlNIidxFmOFoIRndZY551v4MU=; b=CU7w1zOwJISlbsktycO55cZkYJCpCnSxSmiIQaQvlZg59iO9huWTtA/kkmWNIcXi2T p47lsR32cufdvaYwnxcjNAnf5hk7EhlEYsJ69JZjebhmu8Wkf688NHqOU8408TIY65E4 NZb0YOcpIkRN2RZpyzXDhnffBrBFRSikPmowAdKaDM1C+xxqebiv1sDucEEqeHZY4Z+7 THW05wsgDamj06yZZa/Kjh7Ivpjnrk9SDv3oLX0Xi0Qnb3AeYpzcEj+lNZUH7bgayEQm 7mYhfe5UQCG7ipfmpKmqaiAN2vqqNkyWosRYOIZs8PNtyF4GZRKxTu3YO9Q4ZcYk7q1a aovA== MIME-Version: 1.0 X-Received: by 10.180.109.161 with SMTP id ht1mr29175461wib.10.1439236959302; Mon, 10 Aug 2015 13:02:39 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Mon, 10 Aug 2015 13:02:39 -0700 (PDT) In-Reply-To: <20150810194018.GX1667@cisco.com> References: <20150810184147.GW1667@cisco.com> <20150810194018.GX1667@cisco.com> Date: Mon, 10 Aug 2015 13:02:39 -0700 Message-ID: From: Ted Hardie To: Toerless Eckert Content-Type: multipart/alternative; boundary=e89a8f23568bb4fca4051cfa7766 Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 13:20:38 -0700 Cc: Eric Rescorla , "Black, David" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Joe Hildebrand , "spud@ietf.org" , Christian Huitema , Ken Calvert , Brian Trammell , Jana Iyengar Subject: Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:02:43 -0000 --e89a8f23568bb4fca4051cfa7766 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2015 at 12:40 PM, Toerless Eckert wrote: > ;-) Thanks for detailling the minimum requirements for the example > exchange. But my point was really about showing the > only after you know why you would have to show it. > If i read your reply correctly, you are reconfirming > that the current goal in SPUD is to show tokens whether or not they are > needed > and without knowing what benefit you would get when you show them. Its li= ke > carrying that vertical or hirozontal picture card openly without knowing > that you'll have a benefit from it. > > =E2=80=8BSo, let's assume that the request is from an application like a = WebRTC application working inside a browser. It wants to tell the network that a specific set of packets are grouped together (they are a tube) even when there are other packets on the same five-tuple. For the ones within the tube, it would prefer packet drop on delay, rather than buffering. Sure, it could wait until every middlebox along the way reported its likely treatment of the tube before specifying what it wanted, but it is faster and more reasonable to make the declarative statement when the desire is expressed. That's more like, "show the picture when you are entering bar, rather than waiting to see if a bouncer asks for your ID"=E2=80=8B. Yes, the bouncer m= ight look at you and pass you based on inference, but why rely on that? Ted > Thats what i think is one of the main reasons why we have this ongoing > discussion > between privacy and spud sides. If spud had the framework to tell > the how what to show and what benefit it would then get, i am arguing > the pushback would be a lot smaller. > > Cheers > Toerless > > On Mon, Aug 10, 2015 at 12:12:12PM -0700, Ted Hardie wrote: > > Howdy, > > > > On Mon, Aug 10, 2015 at 11:41 AM, Toerless Eckert > wrote: > > > > > As a generic side thought based on Christians concern about privacy > > > (why would an app want to show a shared Tube-ID across multipath/mobi= le > > > flows for example). > > > > > > To me, the problem is best explained on the following workflow: > > > > > > "Here is your new ID card". > > > "Why would i want to have an ID card, everybody who checks ID cards i= s > > > evil" > > > "You do not have to show your ID card if you don't want to" > > > "Lets go to the bar" > > > "ID card please" > > > "Booze or anonymity... that's the question" > > > "Lets choose booze" > > > > > > > > ???You've just demonstrated a bad workflow. To drink booze in many > > jurisdictions, you need to be of a certain age. Associating that age > with > > a token that can be shown (of-booze-consuming-age) is enough to meet th= e > > requirement; showing an identity is most assuredly not required. > > > > There are states that change your ID card when you pass that age, for > > example; it is a horizontal picture in one and ???a vertical in the > other. > > When asked for proof of age, you can show just the picture and be grant= ed > > entrance, without showing your name, home address, or other identifying > > characteristics. > > > > What we are looking for in SPUD is a set of declarative statements that > can > > be made from the application to the network about the network treatment > > desired and from the network to the application about the network > treatment > > provided. Anything beyond that is not just surplus to requirements, it= 's > > dangerous because you can end up subverting the security properties of > the > > overlying protocol (which is what the application sees and is relying > on). > > > > My two cents, in any case, > > > > Ted > > > > > > > > > > > > > So, whats missing in SPUD (or any prior endpoint<->network) signaling > is > > > the > > > signaling element "If you do not show ID card, you will not get booze= " > or > > > "if you do not use a cross-subflow Tube-ID, your load-sharing, > mobility or > > > multipath > > > performance will suck or not work". > > > > > > Using the same Tube-ID is just one example. This interaction really > applies > > > to any possible signaling element: The anonymity freak will argue to > his > > > death that he doesn't want to provide information to the network... > unless > > > the network can persuade him that the benefit of showing outweights t= he > > > loss of anonymity. > > > > > > This is primarily a question of creating a data-model of what the > network > > > can offer > > > and tie that to a data model for what to show to get it.... > > > > > > Cheers > > > Toerless > > > > > -- > --- > Toerless Eckert, eckert@cisco.com > --e89a8f23568bb4fca4051cfa7766 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10, 2015 at 12:40 P= M, Toerless Eckert <eckert@cisco.com> wrote:
;-) Thanks for detailling the = minimum requirements for the example
exchange. But my point was really about showing the <insert right token&= gt;
only after you know why you would have to show it.
=C2=A0
If i read your reply correctly, you are reconfirming
that the current goal in SPUD is to show tokens whether or not they are nee= ded
and without knowing what benefit you would get when you show them. Its like=
carrying that vertical or hirozontal picture card openly without knowing that you'll have a benefit from it.

=E2=80=8BSo, let's assume that the requ= est is from an application like a WebRTC application working inside a brows= er.=C2=A0=C2=A0 It wants to tell the network that a specific set of packets= are grouped together (they are a tube) even when there are other packets o= n the same five-tuple.=C2=A0 For the ones within the tube, it would prefer = packet drop on delay, rather than buffering.=C2=A0 Sure, it could wait unti= l every middlebox along the way reported its likely treatment of the tube b= efore specifying what it wanted, but it is faster and more reasonable to ma= ke the declarative statement when the desire is expressed.

That's more like, "show the picture when you are entering b= ar, rather than waiting to see if a bouncer asks for your ID"=E2=80=8B= .=C2=A0 Yes, the bouncer might look at you and pass you based on inference,= but why rely on that?

Ted


=C2=A0
Thats what i think is one of the main reasons why we have this ongoing disc= ussion
between privacy and spud sides. If spud had the framework to tell
the how what to show and what benefit it would then get, i am arguing
the pushback would be a lot smaller.

Cheers
=C2=A0 =C2=A0 Toerless

On Mon, Aug 10, 2015 at 12:12:12PM -0700, Ted Hardie wrote:
> Howdy,
>
> On Mon, Aug 10, 2015 at 11:41 AM, Toerless Eckert <eckert@cisco.com> wrote:
>
> > As a generic side thought based on Christians concern about priva= cy
> > (why would an app want to show a shared Tube-ID across multipath/= mobile
> > flows for example).
> >
> > To me, the problem is best explained on the following workflow: > >
> > "Here is your new ID card".
> > "Why would i want to have an ID card, everybody who checks I= D cards is
> > evil"
> > "You do not have to show your ID card if you don't want = to"
> > "Lets go to the bar"
> > "ID card please"
> > "Booze or anonymity... that's the question"
> > "Lets choose booze"
> >
> >
> ???You've just demonstrated a bad workflow.=C2=A0 To drink = booze in many
> jurisdictions, you need to be of a certain age.=C2=A0= Associating that age with
> a token that can be shown (of-booze-consuming-age) is enough to meet t= he
> requirement; showing an identity is most assuredly not required.
>
> There are states that change your ID card when you pass that age, for<= br> > example; it is a horizontal picture in one and ???a vertical in= the other.
> When asked for proof of age, y= ou can show just the picture and be granted
> entrance, without showing your name, home address, or other identifyin= g
> characteristics.
>
> What we are looking for in SPUD is a set of declarative statements tha= t can
> be made from the application to the network about the network treatmen= t
> desired and from the network to the application about the network trea= tment
> provided.=C2=A0 Anything beyond that is not just surplus to requiremen= ts, it's
> dangerous because you can end up subverting the security properties of= the
> overlying protocol (which is what the application sees and is relying = on).
>
> My two cents, in any case,
>
> Ted
>
>
>
>
>
> > So, whats missing in SPUD (or any prior endpoint<->network)= signaling is
> > the
> > signaling element "If you do not show ID card, you will not = get booze" or
> > "if you do not use a cross-subflow Tube-ID, your load-sharin= g, mobility or
> > multipath
> > performance will suck or not work".
> >
> > Using the same Tube-ID is just one example. This interaction real= ly applies
> > to any possible signaling element: The anonymity freak will argue= to his
> > death that he doesn't want to provide information to the netw= ork... unless
> > the network can persuade him that the benefit of showing outweigh= ts the
> > loss of anonymity.
> >
> > This is primarily a question of creating a data-model of what the= network
> > can offer
> > and tie that to a data model for what to show to get it....
> >
> > Cheers
> >=C2=A0 =C2=A0 =C2=A0Toerless
> >

--
---
Toerless Eckert, eckert@cisco.com

--e89a8f23568bb4fca4051cfa7766-- From nobody Mon Aug 10 13:20:52 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440351B3D7E for ; Mon, 10 Aug 2015 13:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB8WfPuu9_0e for ; Mon, 10 Aug 2015 13:13:02 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD601B3D82 for ; Mon, 10 Aug 2015 13:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5552; q=dns/txt; s=iport; t=1439237582; x=1440447182; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=AOY2K+AVH37dWHZThmX/o0PLD8h4NwT3+3Kk5aVnl5s=; b=EmzQM9dgOLwAHkflxDQ/Xw6vkiUazJjZnxX8OJLtfPe2bRdGXG6RBNj2 byAZvy2pG10T2VjApsF727w7BKVU6oAjj/hDCmwdTwxNHLkp0/dLBmHU0 mKMlHJ7PXviQ5V4CVRZaeI1odIJjLaP6dukDNeQjFWLXKhkj4nkhhiK1V w=; X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="scan'208";a="177323492" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 10 Aug 2015 20:13:01 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7AKD0f8016695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 20:13:01 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7AKD0Js021950; Mon, 10 Aug 2015 13:13:00 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7AKCxwm021948; Mon, 10 Aug 2015 13:12:59 -0700 Date: Mon, 10 Aug 2015 13:12:59 -0700 From: Toerless Eckert To: Ted Hardie Message-ID: <20150810201259.GY1667@cisco.com> References: <20150810184147.GW1667@cisco.com> <20150810194018.GX1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 13:20:38 -0700 Cc: Eric Rescorla , "Black, David" , Mirja =?iso-8859-1?Q?K=FChlewind?= , Joe Hildebrand , "spud@ietf.org" , Christian Huitema , Ken Calvert , Brian Trammell , Jana Iyengar Subject: Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:13:07 -0000 Counter example is when the presence of the advanced processing that the app wants to have in the network would actually impact how the application sends packets. For example if i can know at least one middlebox can do advanced priority based packet dropping, then i'd do the video encoding slightly different. And i still contend that privacy advocats would think it is less intrusive if you have the ability to signal your tokens only after figuring out why what you get for it). Independent of whether the app would change it's behavior. Cheers Toerless On Mon, Aug 10, 2015 at 01:02:39PM -0700, Ted Hardie wrote: > On Mon, Aug 10, 2015 at 12:40 PM, Toerless Eckert wrote: > > > ;-) Thanks for detailling the minimum requirements for the example > > exchange. But my point was really about showing the > > only after you know why you would have to show it. > > > > If i read your reply correctly, you are reconfirming > > that the current goal in SPUD is to show tokens whether or not they are > > needed > > and without knowing what benefit you would get when you show them. Its like > > carrying that vertical or hirozontal picture card openly without knowing > > that you'll have a benefit from it. > > > > ???So, let's assume that the request is from an application like a WebRTC > application working inside a browser. It wants to tell the network that a > specific set of packets are grouped together (they are a tube) even when > there are other packets on the same five-tuple. For the ones within the > tube, it would prefer packet drop on delay, rather than buffering. Sure, > it could wait until every middlebox along the way reported its likely > treatment of the tube before specifying what it wanted, but it is faster > and more reasonable to make the declarative statement when the desire is > expressed. > > That's more like, "show the picture when you are entering bar, rather than > waiting to see if a bouncer asks for your ID"???. Yes, the bouncer might > look at you and pass you based on inference, but why rely on that? > > Ted > > > > > > Thats what i think is one of the main reasons why we have this ongoing > > discussion > > between privacy and spud sides. If spud had the framework to tell > > the how what to show and what benefit it would then get, i am arguing > > the pushback would be a lot smaller. > > > > Cheers > > Toerless > > > > On Mon, Aug 10, 2015 at 12:12:12PM -0700, Ted Hardie wrote: > > > Howdy, > > > > > > On Mon, Aug 10, 2015 at 11:41 AM, Toerless Eckert > > wrote: > > > > > > > As a generic side thought based on Christians concern about privacy > > > > (why would an app want to show a shared Tube-ID across multipath/mobile > > > > flows for example). > > > > > > > > To me, the problem is best explained on the following workflow: > > > > > > > > "Here is your new ID card". > > > > "Why would i want to have an ID card, everybody who checks ID cards is > > > > evil" > > > > "You do not have to show your ID card if you don't want to" > > > > "Lets go to the bar" > > > > "ID card please" > > > > "Booze or anonymity... that's the question" > > > > "Lets choose booze" > > > > > > > > > > > ???You've just demonstrated a bad workflow. To drink booze in many > > > jurisdictions, you need to be of a certain age. Associating that age > > with > > > a token that can be shown (of-booze-consuming-age) is enough to meet the > > > requirement; showing an identity is most assuredly not required. > > > > > > There are states that change your ID card when you pass that age, for > > > example; it is a horizontal picture in one and ???a vertical in the > > other. > > > When asked for proof of age, you can show just the picture and be granted > > > entrance, without showing your name, home address, or other identifying > > > characteristics. > > > > > > What we are looking for in SPUD is a set of declarative statements that > > can > > > be made from the application to the network about the network treatment > > > desired and from the network to the application about the network > > treatment > > > provided. Anything beyond that is not just surplus to requirements, it's > > > dangerous because you can end up subverting the security properties of > > the > > > overlying protocol (which is what the application sees and is relying > > on). > > > > > > My two cents, in any case, > > > > > > Ted > > > > > > > > > > > > > > > > > > > So, whats missing in SPUD (or any prior endpoint<->network) signaling > > is > > > > the > > > > signaling element "If you do not show ID card, you will not get booze" > > or > > > > "if you do not use a cross-subflow Tube-ID, your load-sharing, > > mobility or > > > > multipath > > > > performance will suck or not work". > > > > > > > > Using the same Tube-ID is just one example. This interaction really > > applies > > > > to any possible signaling element: The anonymity freak will argue to > > his > > > > death that he doesn't want to provide information to the network... > > unless > > > > the network can persuade him that the benefit of showing outweights the > > > > loss of anonymity. > > > > > > > > This is primarily a question of creating a data-model of what the > > network > > > > can offer > > > > and tie that to a data model for what to show to get it.... > > > > > > > > Cheers > > > > Toerless > > > > From nobody Mon Aug 10 13:21:02 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1E1B3DB1 for ; Mon, 10 Aug 2015 13:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDP1vm7bBGPR for ; Mon, 10 Aug 2015 13:20:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605971B3B39 for ; Mon, 10 Aug 2015 13:20:40 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 10 Aug 2015 20:20:20 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0225.018; Mon, 10 Aug 2015 20:20:20 +0000 From: Christian Huitema To: Toerless Eckert Thread-Topic: Whats missing in SPUD (was: Re: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) Thread-Index: AQHQ05yizIZKWAQmRU21LnY3T8VoKp4Fp/DA Date: Mon, 10 Aug 2015 20:20:19 +0000 Message-ID: References: <20150810184444.GB16123@cisco.com> In-Reply-To: <20150810184444.GB16123@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.160.23] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:dbsIFVquoBCHqTMfdHnEfvQcm8gSCL9ryCvDnXSdMLtczwoYCRuzq+e4N5ErkDKz06YlOvNzXXl7UXW9QyB1NvuBCNVb3xrhE3oymDWoknQzkqbuEOtXmGKQSDscfc6sTfXw9sCD0Z0naqAOtrewVw==; 24:8ch3xgDTTbe9lumiFbyp9EzRv1S8U7RhLvNahKGPU/vnO4v8uFIl39KBUtPt01jOJcMKqpgz2yjn2My8IPJfezwaOrNqVz/UEp6jDRqa8TA=; 20:3bOzfyBB0kI1CiI2apQBKE5+KGjr8kDO9PJQjKBgpBD8Sdkw9gSthyv6ZhSV1ttX2v1Dtoo6kqKjOMNQsp1srg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 06640999CA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(377454003)(189002)(5001860100001)(102836002)(81156007)(8990500004)(50986999)(54356999)(122556002)(5003600100002)(5001960100002)(189998001)(110136002)(5005710100001)(76176999)(77096005)(62966003)(10290500002)(64706001)(4001540100001)(101416001)(76576001)(5001830100001)(2950100001)(230783001)(97736004)(77156002)(5002640100001)(2900100001)(10400500002)(68736005)(33656002)(40100003)(105586002)(106356001)(87936001)(92566002)(66066001)(10090500001)(106116001)(86612001)(2656002)(99286002)(74316001)(46102003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 20:20:20.0587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:20:42 -0000 On Monday, August 10, 2015 11:45 AM, Toerless Eckert wrote: >=20 > [another resend due to spud mailin list setup, sorry] >=20 > As a generic side thought based on Christians concern about privacy (why = would > an app want to show a shared Tube-ID across multipath/mobile flows for > example). >=20 > To me, the problem is best explained on the following workflow: >=20 > "Here is your new ID card". > "Why would i want to have an ID card, everybody who checks ID cards is ev= il" > "You do not have to show your ID card if you don't want to" > "Lets go to the bar" > "ID card please" > "Booze or anonymity... that's the question" > "Lets choose booze" >=20 > So, whats missing in SPUD (or any prior endpoint<->network) signaling is = the > signaling element "If you do not show ID card, you will not get booze" or= "if you > do not use a cross-subflow Tube-ID, your load-sharing, mobility or multip= ath > performance will suck or not work". That's exactly the kind of choice that I would not like the application to = make. Take multipath as an example. The application can do it in two ways. = It can use the same "tube ID" on both paths. Or, it can use two different I= Ds, and reassemble the packets in the end system. There are pros and cons i= n both architectures.=20 If the application uses a single ID, the load balancers in front of the ser= ver farm can easily assign packets to the right context. If the application= uses two identifiers, the servers need to somehow communicate to the load = balancers that the two IDs should really map to the same context. That's mo= re complex, but that's the main drawback of using two different IDs. The other potential drawback of using two IDs is that the on-path elements = cannot manage a single set of allocations for the two paths. But then, if t= he application is actively trying to use two different paths, it probably d= oes not want those two paths to be managed as one, as that would defeat the= purpose of multipath. On the other hand, if the application uses the same ID, it discloses that t= wo different IP addresses really belong to the same device, which is a grea= t way to enable tracking. In the common case of cellular + Wi-Fi, this enab= le tying the Wi-Fi usage, typically randomized and anonymous, to the cellul= ar usage, which is typically "managed." Note that applications doing that d= o not just put their own traffic at risk. By "leaking metadata," they are e= ffectively breaking the privacy of other applications as well. -- Christian Huitema From nobody Mon Aug 10 13:32:53 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67531B3DD8 for ; Mon, 10 Aug 2015 13:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we8y-OiLwLfs for ; Mon, 10 Aug 2015 13:32:50 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CB78A1B3DD4 for ; Mon, 10 Aug 2015 13:32:49 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id AE1DFF984; Mon, 10 Aug 2015 16:32:47 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 649F320057; Mon, 10 Aug 2015 22:32:37 +0200 (CEST) From: Daniel Kahn Gillmor To: Toerless Eckert , Christian Huitema In-Reply-To: <20150810184444.GB16123@cisco.com> References: <20150810184444.GB16123@cisco.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 10 Aug 2015 16:32:37 -0400 Message-ID: <87lhdirije.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:32:51 -0000 On Mon 2015-08-10 14:44:44 -0400, Toerless Eckert wrote: > "Here is your new ID card". > "Why would i want to have an ID card, everybody who checks ID cards is evil" > "You do not have to show your ID card if you don't want to" > "Lets go to the bar" > "ID card please" > "Booze or anonymity... that's the question" > "Lets choose booze" Have you ever tried to go to a bar where they require you to scan your full ID into their targeted advertising database in order to step inside for a pint with a friend? [0] They say they're asking this information for the purpose of avoiding alcohol service to underage people. The full ID scan (at least where i live) contains legal name, home address, biostats (height, weight, hair, eye color), date of birth, license number, physical impairments, etc. The bar says "we need to know whether you can legally drink" (a boolean value) and instead collects a timestamped, identity-mapped, rich-characteristic profile of every individual who enters the establishment. You're right, of course, that most people in such a situation will choose booze over their own privacy. i won't go into the number of reasons that people feel compelled to make this choice unless i get a signal from the chairs that this kind of behavioral analysis is on-topic for the list. But the fact that many people are willing to make this tradeoff is not a legitimate excuse to design a system that encourages the tradeoff to be made this way. That exchange is fundamentally a bad deal for the user, even if we accept as a given that a bar needs an automated mechanism that allows it to distinguish legal drinkers from underage drinkers. Users shouldn't be forced into trading off privacy for network access any more than they should be forced into trading off privacy for security [1], and we shouldn't design mechanisms to encourage this false trade. > So, whats missing in SPUD (or any prior endpoint<->network) signaling > is the signaling element "If you do not show ID card, you will not get > booze" or "if you do not use a cross-subflow Tube-ID, your > load-sharing, mobility or multipath performance will suck or not > work". This is *exactly* what i'm concerned about with SPUD. Full user identification is overkill for detection of who is allowed to drink (or who is allowed to use the global network); it is a disaster for user privacy, and a total bonanza for a would-be pervasive monitor. We're suposed to be pushing back on that kind of thing, right? https://tools.ietf.org/html/rfc7258 https://tools.ietf.org/html/rfc6973 Formalizing this practice would put any network operator in the position of the overzealous bar-operator/marketer: "give me your ID card via SPUD to be able to send or receive traffic", not to mention criminals looking for a home address to burgle based on who's out at the local cafe, nation-states looking to repress their own citizenry, or spy agencies fetishizing the need to "collect it all". > Using the same Tube-ID is just one example. This interaction really > applies to any possible signaling element: The anonymity freak will > argue to his death that he doesn't want to provide information to the > network... unless the network can persuade him that the benefit of > showing outweights the loss of anonymity. We should not be designing protocols that encourage users to give up any amount of anonymity to the network without compelling engineering argument (and evidence!) that the anonymity they give up is necessary to the effective operation of the network. Otherwise, we're building a network that is designed to encourage its users to accept this fundamentally bad deal in a place that is today far more critical to civic interaction than a bar. I will accept the label of "anonymity freak" if it means i am concerned about the social impact of a thoroughly-surveilled society. Thanks for the good example. Regards, --dkg [0] fwiw, i have been to a bar that has this requirement. I have not returned to that bar. [1] https://www.schneier.com/blog/archives/2008/01/security_vs_pri.html From nobody Mon Aug 10 14:06:23 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1FA1B3E8E for ; Mon, 10 Aug 2015 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MphIDalNbECn for ; Mon, 10 Aug 2015 14:06:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702801B3C60 for ; Mon, 10 Aug 2015 14:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5278; q=dns/txt; s=iport; t=1439240780; x=1440450380; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=eFk18UHqyHQnNmmXA444YBrXWNBp3B5FcPsX1m90gX8=; b=nG15Bc72MlcupQy6X6Npo6Py4sORlzlMVpKbBMuk+8nZPix95YJmhERH VXViBz6MgZkz7N5W0I9ZC3Y3FdnRtItumyb+cPwLGs73+qQ7TETXSPeCz hVCfom8QgdaWi+usyBfI2rP8KnHNBn1qm3ETQaWmaoHVyXOpqYEYap6SR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBQDcEclV/5hdJa1UCYMbVGm/R4V5AoE4PBABAQEBAQEBgQqEJAEBBCcTPxALGAkaCw8FSYhBDb5zkH4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBItRhC1cB4MYgRQFjFV0h0KFAoJphHUDgUmEJZApg2YmgkCBXh4zAYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,648,1432598400"; d="scan'208";a="177059289" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Aug 2015 21:06:19 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7AL6I0o015944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2015 21:06:19 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7AL6Ig1025285; Mon, 10 Aug 2015 14:06:18 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7AL6IMD025284; Mon, 10 Aug 2015 14:06:18 -0700 Date: Mon, 10 Aug 2015 14:06:18 -0700 From: Toerless Eckert To: Daniel Kahn Gillmor Message-ID: <20150810210618.GB1667@cisco.com> References: <20150810184444.GB16123@cisco.com> <87lhdirije.fsf@alice.fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lhdirije.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Christian Huitema , spud@ietf.org Subject: Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 21:06:22 -0000 Well, biostats/signature/photo constitute elements to establish ownership of the ID card. And there may be county/city police regulations to keep track of full ID scans. And if not police then insurance or on advice of the bars lawyer in case of lawsuits/challenges. Aka: IMHO much more likely caused by third party directives then lets say the customer data collection done by eg: web/social-networking sites. But lets agree that the ID card in its current form is not ideal to exemplify "know what attributes you need to show for the desired benefits and then only show those attributes". So the right example would have been some form of ID card with keypad, i type in what attributes i want to send, it creates a new short lived cert and NFC's those attributes to the gatekeeper. Whether its Photo + (Age > 17) or anything else. On Mon, Aug 10, 2015 at 04:32:37PM -0400, Daniel Kahn Gillmor wrote: > On Mon 2015-08-10 14:44:44 -0400, Toerless Eckert wrote: > > "Here is your new ID card". > > "Why would i want to have an ID card, everybody who checks ID cards is evil" > > "You do not have to show your ID card if you don't want to" > > "Lets go to the bar" > > "ID card please" > > "Booze or anonymity... that's the question" > > "Lets choose booze" > > Have you ever tried to go to a bar where they require you to scan your > full ID into their targeted advertising database in order to step inside > for a pint with a friend? [0] They say they're asking this information > for the purpose of avoiding alcohol service to underage people. > > The full ID scan (at least where i live) contains legal name, home > address, biostats (height, weight, hair, eye color), date of birth, > license number, physical impairments, etc. The bar says "we need to > know whether you can legally drink" (a boolean value) and instead > collects a timestamped, identity-mapped, rich-characteristic profile of > every individual who enters the establishment. > > You're right, of course, that most people in such a situation will > choose booze over their own privacy. i won't go into the number of > reasons that people feel compelled to make this choice unless i get a > signal from the chairs that this kind of behavioral analysis is on-topic > for the list. > > But the fact that many people are willing to make this tradeoff is not a > legitimate excuse to design a system that encourages the tradeoff to be > made this way. > > That exchange is fundamentally a bad deal for the user, even if we > accept as a given that a bar needs an automated mechanism that allows it > to distinguish legal drinkers from underage drinkers. Users shouldn't be > forced into trading off privacy for network access any more than they > should be forced into trading off privacy for security [1], and we > shouldn't design mechanisms to encourage this false trade. > > > So, whats missing in SPUD (or any prior endpoint<->network) signaling > > is the signaling element "If you do not show ID card, you will not get > > booze" or "if you do not use a cross-subflow Tube-ID, your > > load-sharing, mobility or multipath performance will suck or not > > work". > > This is *exactly* what i'm concerned about with SPUD. Full user > identification is overkill for detection of who is allowed to drink (or > who is allowed to use the global network); it is a disaster for user > privacy, and a total bonanza for a would-be pervasive monitor. > > We're suposed to be pushing back on that kind of thing, right? > > https://tools.ietf.org/html/rfc7258 > https://tools.ietf.org/html/rfc6973 > > Formalizing this practice would put any network operator in the position > of the overzealous bar-operator/marketer: "give me your ID card via SPUD > to be able to send or receive traffic", not to mention criminals looking > for a home address to burgle based on who's out at the local cafe, > nation-states looking to repress their own citizenry, or spy agencies > fetishizing the need to "collect it all". > > > Using the same Tube-ID is just one example. This interaction really > > applies to any possible signaling element: The anonymity freak will > > argue to his death that he doesn't want to provide information to the > > network... unless the network can persuade him that the benefit of > > showing outweights the loss of anonymity. > > We should not be designing protocols that encourage users to give up any > amount of anonymity to the network without compelling engineering > argument (and evidence!) that the anonymity they give up is necessary to > the effective operation of the network. > > Otherwise, we're building a network that is designed to encourage its > users to accept this fundamentally bad deal in a place that is today far > more critical to civic interaction than a bar. > > I will accept the label of "anonymity freak" if it means i am concerned > about the social impact of a thoroughly-surveilled society. > > Thanks for the good example. > > Regards, > > --dkg > > [0] fwiw, i have been to a bar that has this requirement. I have not > returned to that bar. > > [1] https://www.schneier.com/blog/archives/2008/01/security_vs_pri.html From nobody Mon Aug 10 16:18:31 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE201A1A33 for ; Mon, 10 Aug 2015 16:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGJ6zjpSqF45 for ; Mon, 10 Aug 2015 16:18:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BE8071A1A4D for ; Mon, 10 Aug 2015 16:18:27 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 9304FF984; Mon, 10 Aug 2015 19:18:25 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5453F2020F; Tue, 11 Aug 2015 01:18:15 +0200 (CEST) From: Daniel Kahn Gillmor To: Toerless Eckert In-Reply-To: <20150810210618.GB1667@cisco.com> References: <20150810184444.GB16123@cisco.com> <87lhdirije.fsf@alice.fifthhorseman.net> <20150810210618.GB1667@cisco.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 10 Aug 2015 19:18:15 -0400 Message-ID: <87h9o6ravc.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Christian Huitema , spud@ietf.org Subject: Re: [Spud] Whats missing in SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 23:18:29 -0000 On Mon 2015-08-10 17:06:18 -0400, Toerless Eckert wrote: > Well, biostats/signature/photo constitute elements to establish > ownership of the ID card. And there may be county/city police > regulations to keep track of full ID scans. And if not police then > insurance or on advice of the bars lawyer in case of > lawsuits/challenges. Aka: IMHO much more likely caused by third party > directives then lets say the customer data collection done by eg: > web/social-networking sites. Sure. So should we design a protocol that facilitates the publication and collection of arbitrary data that might be of interest to any regulator/lawyer/advertiser/insurer (or criminal/spy/competitor/troll) able to influence any device along the path? I share your concern about the customer data collection done by web/social-networking sites, which today are indistinguishable from "the network" for many users. But the remedy for this is not to help make the lower layers of the network (i.e. IETF purview) as bad for user privacy as the worst of the centralized services are. > But lets agree that the ID card in its current form is not ideal to > exemplify "know what attributes you need to show for the desired benefits > and then only show those attributes". That's why we're having this discussion -- because we do not want to produce a network transport protocol with sufficient flexibility and power to implement the "show your full identity to an arbitrary intermediary order to be able to socialize" antipattern, even though i'm sure some arbitrary intermediaries would love such a thing. > So the right example would have been some form of ID card with keypad, > i type in what attributes i want to send, it creates a new short lived > cert and NFC's those attributes to the gatekeeper. Whether its Photo + > (Age > 17) or anything else. We're not designing a beer-delivery protocol layer (though that does sound like more fun), we're designing a network transport layer. It should be designed for transporting data through the network, not for facilitation of arbitrary interference by any network operator. Can you reframe your proposal in the network transport layer context in a way that seems feasible to implement, is comprehensible to the user, doesn't encourage the false-tradeoff antipattern, and is actually effective at improving user experience on the network (as compared to, say, spending the same amount of engineering effort on a faster link layer)? All the best, --dkg From nobody Tue Aug 11 00:10:16 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8FD1A1A87 for ; Tue, 11 Aug 2015 00:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfl3dAi9mL40 for ; Tue, 11 Aug 2015 00:10:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00631A1A10 for ; Tue, 11 Aug 2015 00:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5050; q=dns/txt; s=iport; t=1439277013; x=1440486613; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HRXTqqFy1wsbaUMNirQ48OpwPfiipYiX87Z7vaVttQY=; b=l8kLBvgIpAkJzILw53ZJcryZ2EcIHsYYuzW58vd78tPfiGUiVoy+e6nl 5QIRVqaij11gVsPyjB0VUO0trgJYzZVFxLl1LaOq5JT2CzJEcdJKLOHqw CullETtv3sao7fXxQhDidFbWNj4tw5tlVfROr8PZeKt0Hv1tNyIo+j5oO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQCLn8lV/4ENJK1HDAEJgxtUxjICgTY7EQEBAQEBAQGBCoQjAQEBAwEnEz8FCwsYCQoCAQEXDwVJLogLCM8cAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tRhB4OAQQJBAJJBwoJAYMEgRQFjUmHQ4dsgjuCOwOBSZRRg2Ymgg4BHIFzHoE4AQEFAheBJwEBAQ X-IronPort-AV: E=Sophos;i="5.15,651,1432598400"; d="scan'208";a="177388943" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 11 Aug 2015 07:10:01 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7B7A0cu018499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2015 07:10:01 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7B7A0Uw032695; Tue, 11 Aug 2015 00:10:00 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7B79xbm032694; Tue, 11 Aug 2015 00:09:59 -0700 Date: Tue, 11 Aug 2015 00:09:59 -0700 From: Toerless Eckert To: Daniel Kahn Gillmor Message-ID: <20150811070959.GD1667@cisco.com> References: <20150810184444.GB16123@cisco.com> <87lhdirije.fsf@alice.fifthhorseman.net> <20150810210618.GB1667@cisco.com> <87h9o6ravc.fsf@alice.fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h9o6ravc.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Christian Huitema , spud@ietf.org Subject: Re: [Spud] Whats missing in SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 07:10:15 -0000 On Mon, Aug 10, 2015 at 07:18:15PM -0400, Daniel Kahn Gillmor wrote: > Sure. So should we design a protocol that facilitates the publication > and collection of arbitrary data that might be of interest to any > regulator/lawyer/advertiser/insurer (or criminal/spy/competitor/troll) > able to influence any device along the path? How do you prohibit in the design of html that a browser and server exchange arbitrary data in the html header ? In the end, SPUD attributes network->app and vice versa are to me really very similar. IMHO we do need to separate the design of the SPUD communication patterns from the semantics of the individual attributes, otherwise we never get to a useful and flexible, extensible protocol. > That's why we're having this discussion -- because we do not want to > produce a network transport protocol with sufficient flexibility and > power to implement the "show your full identity to an arbitrary > intermediary order to be able to socialize" antipattern, even though i'm > sure some arbitrary intermediaries would love such a thing. Lets say you don't trust your browser. What makes you confident the browser can not exchange that undesired data through any other protocol ? Do you trust a browser with IDS/firewall/etc to prohibit a browser from doing something malicious against you ? If you do trust the browser (not app on top!) then i think its easy for the browser to only exchange data that we like. Aka: Lets discuss not only the protocol, but the overall system expectation including your app. SPUD implement natively in browser (browser can build appropriate barrier towards app to control what can be sent/received via SPUD. That already makes the system better than most other app-channels). You do have your login credentials for your bank in your keystore acessible to the browser. Do you trust the browser to not use an arbitrary protocol to send out that key data in the clear to anybody in the world. SPUD or any other protocol ? > Can you reframe your proposal in the network transport layer context in > a way that seems feasible to implement, is comprehensible to the user, > doesn't encourage the false-tradeoff antipattern, and is actually > effective at improving user experience on the network (as compared to, > say, spending the same amount of engineering effort on a faster link > layer)? To characterize the app/flow behavior/expectations we did discuss over the years many attributes. I am not sure there is a lot of agreement on which of these are most urgent ones. In ine implementation in Cisco products we had about 20 attributes and thought of 20 more. But it was mostly about QoS and thats very much evolving due to AQM, bufferbloat, rmcat or the like, so i primarily want to havethe ability to define attributes in the future if i am not sure what good long term relevant ones are in this bucket. An example QoS attribute is RTP clockrate of sRTP flows. Lets assume we do like that the RTP header itself is in the clear, and we do expect our enterprise/SP to monitor jitter/delay/loss/reorder to identify and monitor/account and fix quality issues. Especially when it is over the top video whee the SP must not have the sRTP keys because i stream from notflix. When it comes to characterizing middlebox behavior towards the applications, that much less well explored IMHO, look for the malice draft. The more interesting side is attributes not for "QoS middleboxes", but "security middleboxes". IMHO, those would for example like some secure app identification: For example they would use offpath solutions like identifying the app type of the server endpoint IP of a connection via secure DNS or other means and then classifying based on that server side IP. But lets assume there are also p2p apps, like RTCweb media shortcuts or cloud storage with torrent technologies so that you can't rely on the server IP for all their flows. Or you really can only trust that the app does not leak confidential information when you cryptographically can trust the client side too. Because the trusted client does force all type of content checks on the user before sending a file to the cloud. With todays HTTPs (if i am not mistaken), you (middlebox) could see (via DPI) what cert the client side announces for itself. I am not sure if you could actually vet ownership as a middlebox, but if the app was explicitly sending in SPUD its cert (or hash thereof) and then signs something like the flow key and time, then this would constitute a good secure client-app-id signaled in SPUD. Just as a starting point idea. There are a lot other aspect in these type of crypto security use-cases for signaling IMHO (limit if/when you want to identify yourself, identifying that you're inside a security perimeter because of the middlebox identifying itself, aka: as soon as you're talking cryto security use cases it always get a lot more complex than you'd like ;-). Cheers Toerless From nobody Tue Aug 11 00:23:08 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5041A1A1ABF for ; Tue, 11 Aug 2015 00:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzhtOiSNG14X for ; Tue, 11 Aug 2015 00:23:04 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD151A1ABB for ; Tue, 11 Aug 2015 00:23:03 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ZP3tl-0006FU-Mq for ; Tue, 11 Aug 2015 09:23:01 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 933F1B00505 for ; Tue, 11 Aug 2015 09:23:01 +0200 (CEST) Message-ID: <55C9A2D5.9060304@kit.edu> Date: Tue, 11 Aug 2015 09:23:01 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: spud@ietf.org References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> In-Reply-To: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1439277781. Archived-At: Subject: Re: [Spud] Return routability and feedback (was: Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 07:23:06 -0000 Hi, Am 08.08.2015 um 11:16 schrieb Mirja Kühlewind: > 4) Return routability and feedback —- > > a) 2WHS vs. 3WHS? —> SPUD should/must (?) provide a 2WHS, that means > an ACK in response to the initial packet should be generated by SPUD > even if the overlying protocol does not support this semantic. Note > this mean the ACK may only have a SPUD header but no overlying > protocol data. This would make all SPUD flows/tubes bidirectional. But potentially hitting different middleboxes along asymmetric paths, i.e., the ACK is routed back along a different path than the initial packet. A 2WHS is also vulnerable against state exhaustion attacks. > Further SPUD should also provided the semantics for an 3WHS but may > only send a third packet if the overlying protocol implements it or > there is another reason for the application to explicitly request a > SPUD-only 3WHS. >From a security perspective, a 3WHS with a DoS protection cookie would be the most reasonable option. > b) Does the semantics of the SPUD protocol need to provide an > explicit start signal as well as start/ack signal? -> Yes, start is > needed to distinguish start and middle of a tube; ack is needed to > finally set up state. However, not clear yet if all SPUD tubes MUST > send a start signal or only SHOULD. If a start was received, however, > a ACK must be sent…? See above. On the one hand an ACK is maybe not enough to set up state. A SYN Flood would otherwise also set up state in the SPUD box. On the other hand, SPUD boxes must be prepared to react to flows/tubes that neither have Start, ACK, or Close due to temporary re-routing events. > c) Should it be possible to send multiple START signal on the same > tube (e.g to re-initiate state)? -> Not clear if this is really > needed I don't think that it is needed, see previous point. > c) Is a stop flag needed/useful? —> Yes (faster state tear-down), but > the overlying protocol must be resilient to it not being sent, not > being received.​ I don't understand this, is that different from a close? Regards, Roland From nobody Tue Aug 11 02:36:20 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935B31A3BA7 for ; Tue, 11 Aug 2015 02:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IBZ2Iqgfnut for ; Tue, 11 Aug 2015 02:36:17 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18991A3B9D for ; Tue, 11 Aug 2015 02:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 00C2AD930B; Tue, 11 Aug 2015 11:36:16 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UaZd-+Y+vJ-0; Tue, 11 Aug 2015 11:36:15 +0200 (MEST) Received: from [192.168.178.33] (x4d02d192.dyn.telefonica.de [77.2.209.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AC1FBD9303; Tue, 11 Aug 2015 11:36:14 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <20150810182648.GU1667@cisco.com> Date: Tue, 11 Aug 2015 11:36:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03B69A81-D3C0-44A7-A0EB-1FC49A31DD50@tik.ee.ethz.ch> References: <20150810182648.GU1667@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Ted Hardie , "Black, David" , Eric Rescorla , Joe Hildebrand , "spud@ietf.org" , Jana Iyengar , Ken Calvert , Brian Trammell Subject: Re: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 09:36:19 -0000 Hi, few comments on your use cases > Am 10.08.2015 um 20:26 schrieb Toerless Eckert : >=20 > a) Simplification of multi-path/mobility end-to-end operations. The = Tube-ID > becomes the identifier for the multi-path flow. Its how additional=20= > 5-tuples indicate which flow they belong to. (thats pure = end-to-end). As this is end to end it should be in the overlaying transport and = encrypted such that the network can=E2=80=99t see it. > b) Diagnostics. Operator, management tools, statistics gatherings, > troubleshooting. As in: may also help the user if something goes = wrong > and there is a common layer helping to idenfiy sub-flows of a = connection. Diagnostics seem to be the one argument why leaking on any information = seems to be useful. I don=E2=80=99t think diagnostics should be an = argument to give up privacy. Further as long as I don=E2=80=99t see a = very good example why especially it is needed to know that two different = flows belong to the same app/user for a very concrete case, that = argument is to general for me. > c) ability to do less per-sub-flow signaling by using state data from = another > sub-flow. We are talking about potentially having a spud header in each packet to = support state handling. I don=E2=80=99t see a reason to re-use state information from a = different flow (not even sure how this would exactly look like). > d) Ability to do resource tracking/assignment across a = multi-path/mobile flow. >=20 So tracking is the case we want to avoid! All the network needs to know = is: Please thread these packets together with preferentially that = service. Especially if you try to use two different paths for you flows = (multi path), there is no need to connect packet of different flows = together. Mirja From nobody Tue Aug 11 02:38:29 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE8A1A6ED9 for ; Tue, 11 Aug 2015 02:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2KGjo0JFY0L for ; Tue, 11 Aug 2015 02:38:26 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5581A3BA7 for ; Tue, 11 Aug 2015 02:38:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C7EA8D930B; Tue, 11 Aug 2015 11:38:24 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k-utzM9sX06z; Tue, 11 Aug 2015 11:38:24 +0200 (MEST) Received: from [192.168.178.33] (x4d02d192.dyn.telefonica.de [77.2.209.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 32FEBD9303; Tue, 11 Aug 2015 11:38:24 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <55C9A2D5.9060304@kit.edu> Date: Tue, 11 Aug 2015 11:38:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F26B0A9-8042-472D-92B0-9D2822B5D1A3@tik.ee.ethz.ch> References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> <55C9A2D5.9060304@kit.edu> To: Roland Bless X-Mailer: Apple Mail (2.2102) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] Return routability and feedback (was: Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 09:38:27 -0000 Hi Roland, see below. > Am 11.08.2015 um 09:23 schrieb Roland Bless : >=20 > Hi, >=20 > Am 08.08.2015 um 11:16 schrieb Mirja K=C3=BChlewind: >> 4) Return routability and feedback =E2=80=94- >>=20 >> a) 2WHS vs. 3WHS? =E2=80=94> SPUD should/must (?) provide a 2WHS, = that means >> an ACK in response to the initial packet should be generated by SPUD >> even if the overlying protocol does not support this semantic. Note >> this mean the ACK may only have a SPUD header but no overlying >> protocol data. This would make all SPUD flows/tubes bidirectional. >=20 > But potentially hitting different middleboxes along asymmetric paths, > i.e., the ACK is routed back along a different path than the initial > packet. A 2WHS is also vulnerable against state exhaustion attacks. >=20 >> Further SPUD should also provided the semantics for an 3WHS but may >> only send a third packet if the overlying protocol implements it or >> there is another reason for the application to explicitly request a >> SPUD-only 3WHS. >=20 >> =46rom a security perspective, a 3WHS with a DoS protection cookie = would > be the most reasonable option. >=20 >> b) Does the semantics of the SPUD protocol need to provide an >> explicit start signal as well as start/ack signal? -> Yes, start is >> needed to distinguish start and middle of a tube; ack is needed to >> finally set up state. However, not clear yet if all SPUD tubes MUST >> send a start signal or only SHOULD. If a start was received, however, >> a ACK must be sent=E2=80=A6? >=20 > See above. On the one hand an ACK is maybe not enough to set up state. = A > SYN Flood would otherwise also set up state in the SPUD box. On the > other hand, SPUD boxes must be prepared to react to flows/tubes that > neither have Start, ACK, or Close due to temporary re-routing events. >=20 >> c) Should it be possible to send multiple START signal on the same >> tube (e.g to re-initiate state)? -> Not clear if this is really >> needed >=20 > I don't think that it is needed, see previous point. >=20 >> c) Is a stop flag needed/useful? =E2=80=94> Yes (faster state = tear-down), but >> the overlying protocol must be resilient to it not being sent, not >> being received.=E2=80=8B >=20 > I don't understand this, is that different from a close? No, it=E2=80=99s close. The question is do we need an explicate signal = for close (and maybe even close/ack) or is it sufficient to just let the = state time out because middleboxes anyway need a timer as they can never = rely on seeing a close. Mirja >=20 > Regards, > Roland >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Tue Aug 11 03:27:16 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FF41A702F for ; Tue, 11 Aug 2015 03:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5w83nH_7gkc for ; Tue, 11 Aug 2015 03:27:13 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185E81A702D for ; Tue, 11 Aug 2015 03:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3440; q=dns/txt; s=iport; t=1439288833; x=1440498433; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=QNH9sHX40XYk4zWIvhMHZnAlosxyTzKuj8c2AYZI7jo=; b=CUcpdeGnsIiBY6ERtJjx43g3NjW7SJqMuVNd/8mrRLmni1/D3gNNFa2h FKrpsuaCUwbe8pTO6tAWyUcJPTTeX4Cshqvfb9WKc93x3u0gAiRQoW7je uyd51c3FUsNL0vWWC636CAD6ThILARCjkBEWn+WFoB+R++ggEd6jfBhcS k=; X-IronPort-AV: E=Sophos;i="5.15,652,1432598400"; d="scan'208";a="177490456" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 11 Aug 2015 10:27:13 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7BARC7i026034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2015 10:27:12 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7BARBL6012421; Tue, 11 Aug 2015 03:27:11 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7BARBtQ012420; Tue, 11 Aug 2015 03:27:11 -0700 Date: Tue, 11 Aug 2015 03:27:11 -0700 From: Toerless Eckert To: Mirja =?iso-8859-1?Q?K=FChlewind?= Message-ID: <20150811102711.GF1667@cisco.com> References: <20150810182648.GU1667@cisco.com> <03B69A81-D3C0-44A7-A0EB-1FC49A31DD50@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <03B69A81-D3C0-44A7-A0EB-1FC49A31DD50@tik.ee.ethz.ch> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Ted Hardie , "Black, David" , Eric Rescorla , Joe Hildebrand , "spud@ietf.org" , Jana Iyengar , Ken Calvert , Brian Trammell Subject: Re: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 10:27:14 -0000 On Tue, Aug 11, 2015 at 11:36:13AM +0200, Mirja Kühlewind wrote: > > a) Simplification of multi-path/mobility end-to-end operations. The Tube-ID > > becomes the identifier for the multi-path flow. Its how additional > > 5-tuples indicate which flow they belong to. (thats pure end-to-end). > > As this is end to end it should be in the overlaying transport and encrypted such that the network can???t see it. I disagree. > > b) Diagnostics. Operator, management tools, statistics gatherings, > > troubleshooting. As in: may also help the user if something goes wrong > > and there is a common layer helping to idenfiy sub-flows of a connection. > > Diagnostics seem to be the one argument why leaking on any information seems to be useful. I don???t think diagnostics should be an argument to give up privacy. Further as long as I don???t see a very good example why especially it is needed to know that two different flows belong to the same app/user for a very concrete case, that argument is to general for me. Every enterprise customer trying to manage a network and figuring out why apps don't work or why traffic is not what it should be needs diagnostics for multipath traffic to figure this out. Heck, just comparing the bitrates of two sub-flows to diagnose the WAN congerstion domains. Btw: I would bother wondering about privacy for stuff that sits on top of an API that provides an actual transport connection. Without creating diagnostics for network/transprt layer itself you're creating an unmanageable mess. I understand how folks are also trying to exploit privacy at lower layers, like privacy addresses and the like, and i don't want to stop any of that, but i don't want those folks to stop the option of having diagnostics for network/transport. > > c) ability to do less per-sub-flow signaling by using state data from another > > sub-flow. > > We are talking about potentially having a spud header in each packet to support state handling. > I don???t see a reason to re-use state information from a different flow (not even sure how this would exactly look like). The SPUD header should be small, so i would constrain it to only per-packet attributes like packet priority, ECN and the like. The per-flow attributes could only be in specific signaling packets like START/STOP related ones. If for example an app goes through the long list of ICE matrix local X remote address for connections, we might be ale to ue the Tube-ID to speed up stuff. Haven't quite tried to build out the workflow yet. > > d) Ability to do resource tracking/assignment across a multi-path/mobile flow. > > > So tracking is the case we want to avoid! All the network needs to know is: Please thread these packets together with preferentially that service. Especially if you try to use two different paths for you flows (multi path), there is no need to connect packet of different flows together. Disagreement. You use different addresses local/remote and two of these flows go through a single congestion point, then the network thats trying to provide fairness might want to give you bandwidth for just one actual connection instead of two flows - if you are so nice to the network of letting it know about this fact. Again: its the choice of a collaborative application. Cheers Toerless > Mirja > > -- --- Toerless Eckert, eckert@cisco.com From nobody Tue Aug 11 06:07:59 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B522D1A8A13 for ; Tue, 11 Aug 2015 06:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWXEQ5PIlqac for ; Tue, 11 Aug 2015 06:07:55 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5121A8A0D for ; Tue, 11 Aug 2015 06:07:55 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ZP9HW-0002c4-Fs; Tue, 11 Aug 2015 15:07:54 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 662C5B005D2; Tue, 11 Aug 2015 15:07:54 +0200 (CEST) Message-ID: <55C9F3AA.4090505@kit.edu> Date: Tue, 11 Aug 2015 15:07:54 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> <55C9A2D5.9060304@kit.edu> <0F26B0A9-8042-472D-92B0-9D2822B5D1A3@tik.ee.ethz.ch> In-Reply-To: <0F26B0A9-8042-472D-92B0-9D2822B5D1A3@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1439298474. Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] Return routability and feedback X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 13:07:57 -0000 Hi Mirja, Am 11.08.2015 um 11:38 schrieb Mirja Kühlewind: >>> c) Is a stop flag needed/useful? —> Yes (faster state tear-down), >>> but the overlying protocol must be resilient to it not being >>> sent, not being received.​ >> >> I don't understand this, is that different from a close? > > No, it’s close. The question is do we need an explicate signal for > close (and maybe even close/ack) or is it sufficient to just let the > state time out because middleboxes anyway need a timer as they can > never rely on seeing a close. SPUD doesn't make much sense without a close. I understood that one advantage of SPUD would be the explicit state teardown indication without waiting for a (non-uniform) timeout. However, SPUD doesn't make the timer obsolete. Regards, Roland From nobody Tue Aug 11 09:56:02 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38451ACDA9 for ; Tue, 11 Aug 2015 09:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h193C0WqXYbm for ; Tue, 11 Aug 2015 09:55:58 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C611ACDA8 for ; Tue, 11 Aug 2015 09:55:58 -0700 (PDT) Received: by igfj19 with SMTP id j19so76342705igf.1 for ; Tue, 11 Aug 2015 09:55:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Zgpwz/FYfyIRz5qU/eMb6UKKYCfckp8wg/GvoGF4jug=; b=IqZKCGIhgyeF4yIX2beDy7UllY2NsWzjUzM3AS+0hWY+GIonzegbkQGVaohCPKPT9m wOqnm+R0DFqsft64w11BDXa1Bv+gG1dyOl1GwdjlwYiwhuXQ94SaQw5yHMTzDuTu8T73 0THH/qYhxPD6EkU1CN/n8RJq0E3pEBQyCofEv0tey/ouXPRVRVzecWagBMUtYBuehQqu d3e96Lyx0nVrIIpvM/4WqZvrtxt5noqVLYEWSrwggvUX/+3phZu54Xya87+C9DCc5/sR TLs1ngLSqZZnyUYwto2Bh47iQoUFhLz/J6cya+AP7mKioMG6ty9CaGvYi3JGpFHYzwl6 JESw== X-Gm-Message-State: ALoCoQnoquUyIZKazPLim7OUKEEM+RCc4xG/j5YHjlf0NsS8iyZakpJ2IRnL1pHirEvvQQu2H/6J MIME-Version: 1.0 X-Received: by 10.50.117.65 with SMTP id kc1mr20065513igb.94.1439312157659; Tue, 11 Aug 2015 09:55:57 -0700 (PDT) Received: by 10.107.200.195 with HTTP; Tue, 11 Aug 2015 09:55:57 -0700 (PDT) In-Reply-To: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> Date: Tue, 11 Aug 2015 09:55:57 -0700 Message-ID: From: Tom Herbert To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ted Hardie , "Black, David" , Eric Rescorla , Joe Hildebrand , spud@ietf.org, Jana Iyengar , Ken Calvert , Brian Trammell Subject: Re: [Spud] Questions based on draft-trammell-spud-req-00 X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 16:56:00 -0000 Hi Mirja, A few comments in line... On Sat, Aug 8, 2015 at 2:16 AM, Mirja K=C3=BChlewind wrote: > Hi all, > > based on the discussion in section of draft-trammell-spud-req-00, we (the= current group of authors) have phrased some questions we would like get fu= rther feedback from you! > > For some/most questions we already provided an answer which reflects part= of the discussions we had on this so far. However, none of the provided an= swers are final and in a couple of cases we also don=E2=80=99t have consens= us between the small group of us authors. To further proceed here we would = like to get more input from the broader community to hopefully find a way t= o evolve! > > Please go ahead and provide feedback to some or all of the questions! If = you want to further discuss only one aspect of the questions below, please = think about changing the subject of your mail, such that we have a chance t= o separate different discussions. > > Thanks and have a nice weekend! > Mirja > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > 1) Tradeoffs in tube identifiers > ---- > > a) What the scope of a tube? Is the tube scoped to the 5-tuple, 4-tuple, = or even 3-tuple or can even two different flows have the same tube ID (priv= acy vs. mobility)? > =E2=80=94> 5-tuple, with unidirectional the default. Note that this means= the tube-id itself cannot be used to do mobility. A return flow may use th= e same tube-id, if it wants to signal that it is part of the same exchange,= but it is not required to do so. (5-tuple + tube id =3D 6-tuple; maybe 7-t= uples for per-path-element communication as well?) > > b) Does SPUD need to send a start message for each tube (independent of t= he semantics or the overlying protocol)? > =E2=80=94> Yes, e.g. if you have multiple MPTCP subflows each has its own= tube ID. However, maybe this is should only be aSHOULD. It's a useful mes= sage when you expect it to be used to start initiating state in middleboxes= , but there may be conditions where the treatment requested for the flow me= ans that this is not required. > > c) Can one packet have more than one tube ID? > =E2=80=94> No > > > 2) Property binding > --- > > a) Should it be possible to bind properties (only) to a tube or (also) to= single packets? > =E2=80=94> Only to a tube. If you need to have a packet that should have= different treatment, it needs a new tube-id. Therefore start new tube shou= ld be cheap. > > b) Can properties bound to a tube be changed later on during the connecti= on? > -> Probably not. Also start a new tube in this case as new tube should be= cheap. > > > 3) Tradeoffs in integrity protection > --- > a) Should SPUD provide support to use the authentication mechanism of the= overlying transport for SPUD information provided by an endpoint to check = the authenticity and integrity when the information arrive at the other end= point? > =E2=80=94> Yes, if supported by the overlying protocol > Yes, but this seems independent of the overlying protocol. We should be able to secure the SPUD bits as needed regardless of overlay or underlay. > b) How can packet-mangling (middleboxes changing accidental or intentiona= lly information provided by others, both middblebox and endpoints) by on-pa= th ndes be detected? > -> Lying can potentially be detected if information can be verify over a = different mechanism. However it might not be possible to detect who provide= d these wrong information. Off-path devices would need to know the tube id = to provide wrong information which may be unlikely. > Authenticating the header should be an option in cases where we want to prevent any packet-mangling. > c) If a trust relationship already exists that would allow to authenticat= e information provided by a middlebox, does SPUD need to provided further s= upport for this case? > -> Yes? (Similar as question a) > > d) Is there a value in SPUD having its own (encrypted) end-2-end channel? > -> Not fully clear yet, maybe not; Encrypted end-2-end infos can either b= e handled by the overlying (encrypted) protocol, or an encryption boundery = within SPUD to provided end-2-end information we can be commonly used by m= ultiple protocols. However (encrypted) end-2-end information might be an ow= n overlying protocol (maybe even another shim layer) and not SPUD itself. > > > 4) Return routability and feedback > =E2=80=94- > > a) 2WHS vs. 3WHS? > =E2=80=94> SPUD should/must (?) provide a 2WHS, that means an ACK in resp= onse to the initial packet should be generated by SPUD even if the overlyin= g protocol does not support this semantic. Note this mean the ACK may only = have a SPUD header but no overlying protocol data. This would make all SPU= D flows/tubes bidirectional. Further SPUD should also provided the semantic= s for an 3WHS but may only send a third packet if the overlying protocol im= plements it or there is another reason for the application to explicitly re= quest a SPUD-only 3WHS. > I believe 3WHS is essential to deal with "syn" attacks and this includes synchronizing on unique random values generated by both endpoints. 2WHS may be performed if a receiver has other means to authenticate the sender, or the communication is something like request/response. > > b) Does the semantics of the SPUD protocol need to provide an explicit st= art signal as well as start/ack signal? > -> Yes, start is needed to distinguish start and middle of a tube; ack is= needed to finally set up state. However, not clear yet if all SPUD tubes M= UST send a start signal or only SHOULD. If a start was received, however, a= ACK must be sent=E2=80=A6? > > c) Should it be possible to send multiple START signal on the same tube (= e.g to re-initiate state)? > -> Not clear if this is really needed > I think one goal of SPUD should be to eliminate the motivation for sending keep-alives. Hosts should not be rewarded for sending otherwise useless packets into the network, and these are known to be bad for battery consumption on mobile devices. To accomplish this, it seems like the states for eviction from a middlebox state could be chosen at random. An evicted state can be reconstructed with new packets seen in both directions that indicate the tube is still open at both endpoints. > c) Is a stop flag needed/useful? > =E2=80=94> Yes (faster state tear-down), but the overlying protocol must = be resilient to it not being sent, not being received. > > > 5) In-band, out-of-band, piggybacked, and interleaved signaling > =E2=80=94- > > a) Do all packets of a flow (where one packet already has a spud header) = need to have a SPUD header or could there be single packets in an spud-enab= led flow that don=E2=80=99t have one? > -> Not clear; maybe not and packets on the five-tuple that don't have a t= ube identifier aren't assigned any tube. > > b) Do all SPUD packets need to have overlying protocol data? > =E2=80=94> No, e.g. start packet > > c) Do all SPUD information have to fit into one packet? > =E2=80=94> probably yes (and other should be out-of-band using an overlyi= ng transport) but not clear yet > > d) Can a middlebox generate SPUD packets? > -> not clear yet, alternative is that the endpoint provides a place-holde= r that can be filled by middlebox (and reflected by the receiving endpoint)= which implies all middlebox information need to be requested by the sendin= g endpoint; probably doesn=E2=80=99t work for e.g. error messages and there= fore the system must allow them to generate them, but we also have to recog= nize that they may be consumed by the path before reaching their intended d= estination. Further it makes it difficult to do async signaling of changes. > > We at least need the ability for path elements to send pdec's when they'v= e got the capability. > > e) Can a middlebox request application declaration information from an en= dpoint and/or provide unrequested path declaration information? > -> Not clear yet, to avoid amplification attacks maybe apply the packet c= onservation principle here, e.g. a middlebox can generate a packet/an error= message if it drops a packet..? > > f) Should middlebox information be reflected over the receiver or can the= y also be send directly to the sender (and might take a different route)? > -> Maybe there should be a possibility to sent directly to the sender; fo= r unidirectional flows the receiver may not have a bearer flow to carry the= message back and thus would generate spud-only packets which maybe quite a= bit overhead. However reflection over the receiver should be preferred. > Middleboxes often have a locality associated with them, e.g. home router, enterprise firewall. In such cases, it seems like returning information directly is a better use of resources and limits the exposure of the data. For example, if your firewall wants to provide the client with it's connection timeout, it can send that back directly rather than forwarding this to some server halfway around the world and expecting the them to properly reflect the information when they should not care about this. To the server this is just extra work and extra memory that needs to be allocated for each flow (possibly millions of them). > g) Must SPUD information be provided reliably or are those information al= ways unreliable? > -> hopefully unreliable is enough as we want an incrementally deployable = solution > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Tue Aug 11 10:38:02 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF571ACE1C for ; Tue, 11 Aug 2015 10:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkUyEs2juGsB for ; Tue, 11 Aug 2015 10:37:58 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965BC1ACE15 for ; Tue, 11 Aug 2015 10:37:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 548CAD930B; Tue, 11 Aug 2015 19:37:56 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JpE+-NUyEiQn; Tue, 11 Aug 2015 19:37:56 +0200 (MEST) Received: from [192.168.178.33] (x4d02d192.dyn.telefonica.de [77.2.209.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id EC5A5D9303; Tue, 11 Aug 2015 19:37:54 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 11 Aug 2015 19:37:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> To: Tom Herbert X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Ted Hardie , "Black, David" , Eric Rescorla , Joe Hildebrand , spud@ietf.org, Jana Iyengar , Ken Calvert , Brian Trammell Subject: [Spud] Authentication and packet reflection [was: Re: Questions based on draft-trammell-spud-req-00] X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 17:38:01 -0000 Hi Tom, just two comments below: >> 3) Tradeoffs in integrity protection >> --- >> a) Should SPUD provide support to use the authentication mechanism of = the overlying transport for SPUD information provided by an endpoint to = check the authenticity and integrity when the information arrive at the = other endpoint? >> =E2=80=94> Yes, if supported by the overlying protocol >>=20 > Yes, but this seems independent of the overlying protocol. We should > be able to secure the SPUD bits as needed regardless of overlay or > underlay. That means, you would like to provide key exchange mechanisms in SPUD? >=20 >> b) How can packet-mangling (middleboxes changing accidental or = intentionally information provided by others, both middblebox and = endpoints) by on-path ndes be detected? >> -> Lying can potentially be detected if information can be verify = over a different mechanism. However it might not be possible to detect = who provided these wrong information. Off-path devices would need to = know the tube id to provide wrong information which may be unlikely. >>=20 > Authenticating the header should be an option in cases where we want > to prevent any packet-mangling. If you already have a trust relationship which the other end, that=E2=80=99= s easy but that only helps for information provided from end-points. = However you might not be able to provide authenticated information from = a middlebox. And sometimes it might even been on purpose that one = middlebox should be able to overwrite the information form another = middlebox, e.g. if the shortest time-out on the path is requested. >>=20 >> f) Should middlebox information be reflected over the receiver or can = they also be send directly to the sender (and might take a different = route)? >> -> Maybe there should be a possibility to sent directly to the = sender; for unidirectional flows the receiver may not have a bearer flow = to carry the message back and thus would generate spud-only packets = which maybe quite a bit overhead. However reflection over the receiver = should be preferred. >>=20 > Middleboxes often have a locality associated with them, e.g. home > router, enterprise firewall. In such cases, it seems like returning > information directly is a better use of resources and limits the > exposure of the data. For example, if your firewall wants to provide > the client with it's connection timeout, it can send that back > directly rather than forwarding this to some server halfway around the > world and expecting the them to properly reflect the information when > they should not care about this. To the server this is just extra work > and extra memory that needs to be allocated for each flow (possibly > millions of them). For time-outs I rather would like to see a mechanism where this = information is reflected over the receiver because what you are actually = looking for it not the time-out of your local firewall (you might = already know that over a different channel) but the minimum time-out of = all middleboxes on the path. Otherwise if you just request the time-out, = every (Spud-aware) middlebox on the path would need to send you a = separate reply. Of course the middlebox with the smallest time-out might = not be spud-aware but that=E2=80=99s different problem. Mirja From nobody Tue Aug 11 11:00:09 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C366F1ACE50 for ; Tue, 11 Aug 2015 11:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObT9tjYloqO1 for ; Tue, 11 Aug 2015 11:00:00 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F074E1ACDDF for ; Tue, 11 Aug 2015 10:59:59 -0700 (PDT) Received: by oiev193 with SMTP id v193so78829552oie.3 for ; Tue, 11 Aug 2015 10:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bUOSmEYVPFe64FHjOd3ALYqwV4FmmPupRVDtgmzl2qs=; b=OV4+h2EnjeJN3e0j6sfGGahkK1nts9YRkFA8ySqEBeeWt8mIT4JKmOdrNqYEG4EdpY lwuI/+Zy2ZglQvUCAGt0HoSqFdxCoqWntsYNXQxUc9wnwXdcpw1XYEC5okaOrheV11BD 38yxdacViWln4BwKmkUDRQQQlz4lRx90SPpUWxBImCmFBNsmNTFxmeGGfz4/vE9zCcJP qItssH0E2hAaH+Q2hJZd0EAu5Kl+7WqkczPD3L7xvAj/fnnllWlMSVXdjJp7zbxnarFc xYLSaHN1R251Z/tuyF4hz8wne3zBGrfy69CpLiNbR/O2pDGP3jnlNnVRnhfuv3oPztqC 27ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bUOSmEYVPFe64FHjOd3ALYqwV4FmmPupRVDtgmzl2qs=; b=j+LtWBCl7AIR8JXy107Pb0C2+4BXb4CzBdTjY45SJndfl39/VNffmHxBz+lcakZwBO fo9u9sFG6ngMLpsGujxVxOYJ5yTc8MLUosJlp5LVlijdIu6SQjiglwIfIGoEGuLfsncX ZSfU4a0x70EpqmMqLH/VlogPCbdwWk4TJNAd6OpSdSdGIrEOT8KczjJa0nljn0el0qD6 S1T0P2N5dPk04eatnUmxbTw2OLATqDV28APqP4x21n1mqzgzXmSjqyEYnJGRGnXBwoVc asLM/N9euCzL1IqE22M9xgofJqwVKgn+0E2g5NYkoKEVMGYcVcEQxSxd7DivWsRC4L8G gV7A== X-Gm-Message-State: ALoCoQlEHyM/w7XrsaCY17rlbDJZ0h7ky2GDmbXCr/tP8ZK+mR/3ffMDZmWMSRzhbHWgltPJd7Dw MIME-Version: 1.0 X-Received: by 10.202.45.195 with SMTP id t186mr15330747oit.75.1439315999394; Tue, 11 Aug 2015 10:59:59 -0700 (PDT) Received: by 10.76.158.133 with HTTP; Tue, 11 Aug 2015 10:59:59 -0700 (PDT) In-Reply-To: <0F26B0A9-8042-472D-92B0-9D2822B5D1A3@tik.ee.ethz.ch> References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> <55C9A2D5.9060304@kit.edu> <0F26B0A9-8042-472D-92B0-9D2822B5D1A3@tik.ee.ethz.ch> Date: Tue, 11 Aug 2015 10:59:59 -0700 Message-ID: From: Jana Iyengar To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a1137b266dd5bc2051d0cde49 Archived-At: Cc: Roland Bless , "spud@ietf.org" Subject: Re: [Spud] Return routability and feedback (was: Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 18:00:06 -0000 --001a1137b266dd5bc2051d0cde49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A quick thought on explicit close, FWIW. Sending an explicit close packet often involves a client or a server sending a packet, usually after some amount of quiescence. When on a cellular device, this requires the device to pull up the radio and spend energy on sending/receiving a packet that basically contains little to no information. This design is generally being eschewed in favor of a connection timeout at the ends, especially when the endpoints can negotiate on a timeout period. One way for a middlebox to learn about connection close would be to have an explicit negotiation in SPUD that is visible to the network... but I don't think that relying on connection close packets for signaling a connection's termination is going to be adequate. On Tue, Aug 11, 2015 at 2:38 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Roland, > > see below. > > > Am 11.08.2015 um 09:23 schrieb Roland Bless : > > > > Hi, > > > > Am 08.08.2015 um 11:16 schrieb Mirja K=C3=BChlewind: > >> 4) Return routability and feedback =E2=80=94- > >> > >> a) 2WHS vs. 3WHS? =E2=80=94> SPUD should/must (?) provide a 2WHS, that= means > >> an ACK in response to the initial packet should be generated by SPUD > >> even if the overlying protocol does not support this semantic. Note > >> this mean the ACK may only have a SPUD header but no overlying > >> protocol data. This would make all SPUD flows/tubes bidirectional. > > > > But potentially hitting different middleboxes along asymmetric paths, > > i.e., the ACK is routed back along a different path than the initial > > packet. A 2WHS is also vulnerable against state exhaustion attacks. > > > >> Further SPUD should also provided the semantics for an 3WHS but may > >> only send a third packet if the overlying protocol implements it or > >> there is another reason for the application to explicitly request a > >> SPUD-only 3WHS. > > > >> From a security perspective, a 3WHS with a DoS protection cookie would > > be the most reasonable option. > > > >> b) Does the semantics of the SPUD protocol need to provide an > >> explicit start signal as well as start/ack signal? -> Yes, start is > >> needed to distinguish start and middle of a tube; ack is needed to > >> finally set up state. However, not clear yet if all SPUD tubes MUST > >> send a start signal or only SHOULD. If a start was received, however, > >> a ACK must be sent=E2=80=A6? > > > > See above. On the one hand an ACK is maybe not enough to set up state. = A > > SYN Flood would otherwise also set up state in the SPUD box. On the > > other hand, SPUD boxes must be prepared to react to flows/tubes that > > neither have Start, ACK, or Close due to temporary re-routing events. > > > >> c) Should it be possible to send multiple START signal on the same > >> tube (e.g to re-initiate state)? -> Not clear if this is really > >> needed > > > > I don't think that it is needed, see previous point. > > > >> c) Is a stop flag needed/useful? =E2=80=94> Yes (faster state tear-dow= n), but > >> the overlying protocol must be resilient to it not being sent, not > >> being received.=E2=80=8B > > > > I don't understand this, is that different from a close? > > No, it=E2=80=99s close. The question is do we need an explicate signal fo= r close > (and maybe even close/ack) or is it sufficient to just let the state time > out because middleboxes anyway need a timer as they can never rely on > seeing a close. > > Mirja > > > > > Regards, > > Roland > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a1137b266dd5bc2051d0cde49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A quick thought on explicit close, FWIW. Sending an e= xplicit close packet often involves a client or a server sending a packet, = usually after some amount of quiescence. When on a cellular device, this re= quires the device to pull up the radio and spend energy on sending/receivin= g a packet that basically contains little to no information. This design is= generally being eschewed in favor of a connection timeout at the ends, esp= ecially when the endpoints can negotiate on a timeout period.
One way for a middlebox to learn about connection close would b= e to have an explicit negotiation in SPUD that is visible to the network...= but I don't think that relying on connection close packets for signali= ng a connection's termination is going to be adequate.

On Tue, Aug 11, 2015 a= t 2:38 AM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.eth= z.ch> wrote:
Hi Roland,

see below.

> Am 11.08.2015 um 09:23 schrieb Roland Bless <roland.bless@kit.edu>:
>
> Hi,
>
> Am 08.08.2015 um 11:16 schrieb Mirja K=C3=BChlewind:
>> 4) Return routability and feedback =E2=80=94-
>>
>> a) 2WHS vs. 3WHS? =E2=80=94> SPUD should/must (?) provide a 2WH= S, that means
>> an ACK in response to the initial packet should be generated by SP= UD
>> even if the overlying protocol does not support this semantic. Not= e
>> this mean the ACK may only have a SPUD header but no overlying
>> protocol data.=C2=A0 This would make all SPUD flows/tubes bidirect= ional.
>
> But potentially hitting different middleboxes along asymmetric paths,<= br> > i.e., the ACK is routed back along a different path than the initial > packet. A 2WHS is also vulnerable against state exhaustion attacks. >
>> Further SPUD should also provided the semantics for an 3WHS but ma= y
>> only send a third packet if the overlying protocol implements it o= r
>> there is another reason for the application to explicitly request = a
>> SPUD-only 3WHS.
>
>> From a security perspective, a 3WHS with a DoS protection cookie w= ould
> be the most reasonable option.
>
>> b) Does the semantics of the SPUD protocol need to provide an
>> explicit start signal as well as start/ack signal? -> Yes, star= t is
>> needed to distinguish start and middle of a tube; ack is needed to=
>> finally set up state. However, not clear yet if all SPUD tubes MUS= T
>> send a start signal or only SHOULD. If a start was received, howev= er,
>> a ACK must be sent=E2=80=A6?
>
> See above. On the one hand an ACK is maybe not enough to set up state.= A
> SYN Flood would otherwise also set up state in the SPUD box. On the > other hand, SPUD boxes must be prepared to react to flows/tubes that > neither have Start, ACK, or Close due to temporary re-routing events.<= br> >
>> c) Should it be possible to send multiple START signal on the same=
>> tube (e.g to re-initiate state)? -> Not clear if this is really=
>> needed
>
> I don't think that it is needed, see previous point.
>
>> c) Is a stop flag needed/useful? =E2=80=94> Yes (faster state t= ear-down), but
>> the overlying protocol must be resilient to it not being sent, not=
>> being received.=E2=80=8B
>
> I don't understand this, is that different from a close?

No, it=E2=80=99s close. The question is do we need an explicate= signal for close (and maybe even close/ack) or is it sufficient to just le= t the state time out because middleboxes anyway need a timer as they can ne= ver rely on seeing a close.

Mirja

>
> Regards,
> Roland
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud

--001a1137b266dd5bc2051d0cde49-- From nobody Tue Aug 11 13:29:01 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D95A1AD23D for ; Tue, 11 Aug 2015 13:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3zsayJC-Nds for ; Tue, 11 Aug 2015 13:28:57 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B6D1AC3E6 for ; Tue, 11 Aug 2015 13:28:56 -0700 (PDT) Received: by wicne3 with SMTP id ne3so75704264wic.0 for ; Tue, 11 Aug 2015 13:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5L7Fc+qv6i/OYC7BIFPgw8qgYCxgZUpzO7bg29cb9eU=; b=skABQy+rp49JIwW6lLtNghKJCAkn6IzAyNjozMZbbJlcDbcE96MNSscsyoMUqP9DuT N/Kf8Ff8J3tplGPV8gIFZ5DVQQPygWijoPwkcNycrKRJlepFLPCvZ20Nn2vgil9AsULQ /etKseu9LDQsecWaH8P7Lru29g7KyDeIoAxsAojxTDRiO3iyyn5m2CfN53BjDdukBfSE Sts9vGjzvTRBSncHsirFNNzOIIZizRcES5bmrgpa/PYwFxCi0dmChNzxAuqNruztILrT 6h4xyzbZLeHtE6lZhjZmMLBRw2dGUKUY3pY8KOuNXvRZXjk/lU6KWONNSkZxdgQqgK0/ odLg== MIME-Version: 1.0 X-Received: by 10.194.122.97 with SMTP id lr1mr59624106wjb.26.1439324935049; Tue, 11 Aug 2015 13:28:55 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Tue, 11 Aug 2015 13:28:54 -0700 (PDT) In-Reply-To: References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> <55C9A2D5.9060304@kit.edu> <0F26B0A9-8042-472D-92B0-9D2822B5D1A3@tik.ee.ethz.ch> Date: Tue, 11 Aug 2015 13:28:54 -0700 Message-ID: From: Ted Hardie To: Jana Iyengar Content-Type: multipart/alternative; boundary=089e01228c70785979051d0ef31a Archived-At: Cc: Roland Bless , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "spud@ietf.org" Subject: Re: [Spud] Return routability and feedback (was: Questions based on draft-trammell-spud-req-00) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 20:28:59 -0000 --089e01228c70785979051d0ef31a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 11, 2015 at 10:59 AM, Jana Iyengar wrote: > A quick thought on explicit close, FWIW. Sending an explicit close packet > often involves a client or a server sending a packet, usually after some > amount of quiescence. When on a cellular device, this requires the device > to pull up the radio and spend energy on sending/receiving a packet that > basically contains little to no information. This design is generally bei= ng > eschewed in favor of a connection timeout at the ends, especially when th= e > endpoints can negotiate on a timeout period. > > =E2=80=8B =E2=80=8BSo, the problem with this approach is that the negotiation of the = timeout period doesn't involve just the endpoints; it involves the network elements that are maintain state and allocations. To keep them at their task, lots of systems send heartbeat packets at regular intervals when no other traffic is present. Those also wake the radio and consume battery.=E2=80= =8B So, whether the trade-off with an explicit close is worth may depend on the traffic pattern of the application and the state being held in the network. In some cases, the close message would go with the last packet, and so be "free" from a radio perspective. I'd guess that it would generally be worth it in any system containing a SPUD-compliant NAT or STUN server, but there are cases (DNS over SPUD) where even then it might not be a win for the client. But the client itself is the best judge of this, which is why I favor including the functionality, but making it optional. All the systems have to be redundant to that packet being lost anyway. > One way for a middlebox to learn about connection close would be to have > an explicit negotiation in SPUD that is visible to the network... but I > don't think that relying on connection close packets for signaling a > connection's termination is going to be adequate. > > =E2=80=8BFrom a coding perspective, that seems to be really painful. When = some Harry Potter app uses 17 second timeouts in homage to the Galleon, it's going to need custom timers. Ted > On Tue, Aug 11, 2015 at 2:38 AM, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > >> Hi Roland, >> >> see below. >> >> > Am 11.08.2015 um 09:23 schrieb Roland Bless : >> > >> > Hi, >> > >> > Am 08.08.2015 um 11:16 schrieb Mirja K=C3=BChlewind: >> >> 4) Return routability and feedback =E2=80=94- >> >> >> >> a) 2WHS vs. 3WHS? =E2=80=94> SPUD should/must (?) provide a 2WHS, tha= t means >> >> an ACK in response to the initial packet should be generated by SPUD >> >> even if the overlying protocol does not support this semantic. Note >> >> this mean the ACK may only have a SPUD header but no overlying >> >> protocol data. This would make all SPUD flows/tubes bidirectional. >> > >> > But potentially hitting different middleboxes along asymmetric paths, >> > i.e., the ACK is routed back along a different path than the initial >> > packet. A 2WHS is also vulnerable against state exhaustion attacks. >> > >> >> Further SPUD should also provided the semantics for an 3WHS but may >> >> only send a third packet if the overlying protocol implements it or >> >> there is another reason for the application to explicitly request a >> >> SPUD-only 3WHS. >> > >> >> From a security perspective, a 3WHS with a DoS protection cookie woul= d >> > be the most reasonable option. >> > >> >> b) Does the semantics of the SPUD protocol need to provide an >> >> explicit start signal as well as start/ack signal? -> Yes, start is >> >> needed to distinguish start and middle of a tube; ack is needed to >> >> finally set up state. However, not clear yet if all SPUD tubes MUST >> >> send a start signal or only SHOULD. If a start was received, however, >> >> a ACK must be sent=E2=80=A6? >> > >> > See above. On the one hand an ACK is maybe not enough to set up state.= A >> > SYN Flood would otherwise also set up state in the SPUD box. On the >> > other hand, SPUD boxes must be prepared to react to flows/tubes that >> > neither have Start, ACK, or Close due to temporary re-routing events. >> > >> >> c) Should it be possible to send multiple START signal on the same >> >> tube (e.g to re-initiate state)? -> Not clear if this is really >> >> needed >> > >> > I don't think that it is needed, see previous point. >> > >> >> c) Is a stop flag needed/useful? =E2=80=94> Yes (faster state tear-do= wn), but >> >> the overlying protocol must be resilient to it not being sent, not >> >> being received.=E2=80=8B >> > >> > I don't understand this, is that different from a close? >> >> No, it=E2=80=99s close. The question is do we need an explicate signal f= or close >> (and maybe even close/ack) or is it sufficient to just let the state tim= e >> out because middleboxes anyway need a timer as they can never rely on >> seeing a close. >> >> Mirja >> >> > >> > Regards, >> > Roland >> > >> > _______________________________________________ >> > Spud mailing list >> > Spud@ietf.org >> > https://www.ietf.org/mailman/listinfo/spud >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >> > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > > --089e01228c70785979051d0ef31a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 11, 2015 at 10:59 A= M, Jana Iyengar <jri@google.com> wrote:
A quick thought= on explicit close, FWIW. Sending an explicit close packet often involves a= client or a server sending a packet, usually after some amount of quiescen= ce. When on a cellular device, this requires the device to pull up the radi= o and spend energy on sending/receiving a packet that basically contains li= ttle to no information. This design is generally being eschewed in favor of= a connection timeout at the ends, especially when the endpoints can negoti= ate on a timeout period.

=E2=80= =8B

=E2=80=8BSo, the problem with this approach is that th= e negotiation of the timeout period doesn't involve just the endpoints;= it involves the network elements that are maintain state and allocations.= =C2=A0 To keep them at their task, lots of systems send heartbeat packets a= t regular intervals when no other traffic is present.=C2=A0 Those also wake= the radio and consume battery.=E2=80=8B

So, whether= the trade-off with an explicit close is worth may depend on the traffic pa= ttern of the application and the state being held in the network.=C2=A0 In = some cases, the close message would go with the last packet, and so be &quo= t;free" from a radio perspective. =C2=A0 I'd=C2=A0 guess that it w= ould generally be worth it in any system containing a SPUD-compliant NAT or= STUN server, but there are cases (DNS over SPUD) where even then it might = not be a win for the client.=C2=A0

But the client itself is the bes= t judge of this, which is why I favor including the functionality, but maki= ng it optional.=C2=A0 All the systems have to be redundant to that packet b= eing lost anyway.
=C2=A0
One way for a middlebox to learn about connecti= on close would be to have an explicit negotiation in SPUD that is visible t= o the network... but I don't think that relying on connection close pac= kets for signaling a connection's termination is going to be adequate.<= /div>


=E2=80=8BFrom a co= ding perspective, that seems to be really painful.=C2=A0 When some Harry Po= tter app uses 17 second timeouts in homage to the Galleon, it's going t= o need custom timers.

Ted
=C2=A0
On Tue, Aug 11, 2015 at 2:38 = AM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
Hi Roland,

see below.

> Am 11.08.2015 um 09:23 schrieb Roland Bless <roland.bless@kit.edu>:
>
> Hi,
>
> Am 08.08.2015 um 11:16 schrieb Mirja K=C3=BChlewind:
>> 4) Return routability and feedback =E2=80=94-
>>
>> a) 2WHS vs. 3WHS? =E2=80=94> SPUD should/must (?) provide a 2WH= S, that means
>> an ACK in response to the initial packet should be generated by SP= UD
>> even if the overlying protocol does not support this semantic. Not= e
>> this mean the ACK may only have a SPUD header but no overlying
>> protocol data.=C2=A0 This would make all SPUD flows/tubes bidirect= ional.
>
> But potentially hitting different middleboxes along asymmetric paths,<= br> > i.e., the ACK is routed back along a different path than the initial > packet. A 2WHS is also vulnerable against state exhaustion attacks. >
>> Further SPUD should also provided the semantics for an 3WHS but ma= y
>> only send a third packet if the overlying protocol implements it o= r
>> there is another reason for the application to explicitly request = a
>> SPUD-only 3WHS.
>
>> From a security perspective, a 3WHS with a DoS protection cookie w= ould
> be the most reasonable option.
>
>> b) Does the semantics of the SPUD protocol need to provide an
>> explicit start signal as well as start/ack signal? -> Yes, star= t is
>> needed to distinguish start and middle of a tube; ack is needed to=
>> finally set up state. However, not clear yet if all SPUD tubes MUS= T
>> send a start signal or only SHOULD. If a start was received, howev= er,
>> a ACK must be sent=E2=80=A6?
>
> See above. On the one hand an ACK is maybe not enough to set up state.= A
> SYN Flood would otherwise also set up state in the SPUD box. On the > other hand, SPUD boxes must be prepared to react to flows/tubes that > neither have Start, ACK, or Close due to temporary re-routing events.<= br> >
>> c) Should it be possible to send multiple START signal on the same=
>> tube (e.g to re-initiate state)? -> Not clear if this is really=
>> needed
>
> I don't think that it is needed, see previous point.
>
>> c) Is a stop flag needed/useful? =E2=80=94> Yes (faster state t= ear-down), but
>> the overlying protocol must be resilient to it not being sent, not=
>> being received.=E2=80=8B
>
> I don't understand this, is that different from a close?

No, it=E2=80=99s close. The question is do we need an explicate= signal for close (and maybe even close/ack) or is it sufficient to just le= t the state time out because middleboxes anyway need a timer as they can ne= ver rely on seeing a close.

Mirja

>
> Regards,
> Roland
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud


_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud


--089e01228c70785979051d0ef31a-- From nobody Tue Aug 11 13:36:58 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646831B2A61 for ; Tue, 11 Aug 2015 13:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN-Ykpqt7PWq for ; Tue, 11 Aug 2015 13:36:56 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AB61B2A5D for ; Tue, 11 Aug 2015 13:36:56 -0700 (PDT) Received: by igfj19 with SMTP id j19so38628igf.1 for ; Tue, 11 Aug 2015 13:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hdrDH+zDX7DxR2gE7bvVobWyZ9DUaQoAHfgMibmZW8U=; b=MSa0J5dYe1SC2iSfpN4T9aBJmkO17fWFWbwFA6ZBzYC2ko6Mn24x9zi1uoNqJBzro3 PWBKqHgi9DsKtmyR2ewxaHkSc6x9cGwuItoozzPN2Pc0Iwa8GfzbN0MgvnrZc9LrLOLu ZbSJhahMIqMsCqqyxFI3TPhPEwYZkf98ZTR3G6ylB/Dh6MbwOZsqZ7TfDBOt88I5FmM1 rbnMs3+IUN2ozoi3tDHIkjYzWxfEqlHLVm0WAxH8TQ3+bCNQFBVZDudEmPXbqkSkGKPV asaiz8S0ekYZXkUpoVOHWpTtpOexyi4mbY3/Of71N9qjYLFZF6+BsyI9yVfdUmvD0rki RBsg== X-Gm-Message-State: ALoCoQnv8MewNiPANSu7bK1rHp5y0nF+8tnvXdWgZw0PkHCQwkyW7Z0CajPET4CqYT/eypMYVG1T MIME-Version: 1.0 X-Received: by 10.50.72.6 with SMTP id z6mr21113743igu.65.1439325415579; Tue, 11 Aug 2015 13:36:55 -0700 (PDT) Received: by 10.107.200.195 with HTTP; Tue, 11 Aug 2015 13:36:55 -0700 (PDT) In-Reply-To: References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> Date: Tue, 11 Aug 2015 13:36:55 -0700 Message-ID: From: Tom Herbert To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ted Hardie , "Black, David" , Eric Rescorla , Joe Hildebrand , spud@ietf.org, Jana Iyengar , Ken Calvert , Brian Trammell Subject: Re: [Spud] Authentication and packet reflection [was: Re: Questions based on draft-trammell-spud-req-00] X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 20:36:57 -0000 On Tue, Aug 11, 2015 at 10:37 AM, Mirja K=C3=BChlewind wrote: > Hi Tom, > > just two comments below: > >>> 3) Tradeoffs in integrity protection >>> --- >>> a) Should SPUD provide support to use the authentication mechanism of t= he overlying transport for SPUD information provided by an endpoint to chec= k the authenticity and integrity when the information arrive at the other e= ndpoint? >>> =E2=80=94> Yes, if supported by the overlying protocol >>> >> Yes, but this seems independent of the overlying protocol. We should >> be able to secure the SPUD bits as needed regardless of overlay or >> underlay. > > That means, you would like to provide key exchange mechanisms in SPUD? > The end points do need a key exchange, if they are already doing TLS for encrypting the payload maybe that can be leveraged. IIRC QUIC headers are authenticated but cleartext, and payload is always encrypted, so they may have already solved this... >> >>> b) How can packet-mangling (middleboxes changing accidental or intentio= nally information provided by others, both middblebox and endpoints) by on-= path ndes be detected? >>> -> Lying can potentially be detected if information can be verify over = a different mechanism. However it might not be possible to detect who provi= ded these wrong information. Off-path devices would need to know the tube i= d to provide wrong information which may be unlikely. >>> >> Authenticating the header should be an option in cases where we want >> to prevent any packet-mangling. > > If you already have a trust relationship which the other end, that=E2=80= =99s easy but that only helps for information provided from end-points. How= ever you might not be able to provide authenticated information from a midd= lebox. And sometimes it might even been on purpose that one middlebox shoul= d be able to overwrite the information form another middlebox, e.g. if the = shortest time-out on the path is requested. > Right, but there's also fields in the headers which should be declared immutable in the path-- which likely includes the session ID and cmd. We should be able to get integrity and end to end authentication of those. If mutable fields are also present, then some options are: - Define a mechanism to indicate those fields are excluded from authentication and integrity check - Place mutable fields outside of the headers. For instance, middleboxes can respond directly to the source instead of modifying packets inflight and relying on reflection - Middlebox encapsulates in another header so it can set any fields as desired, but receiver will need to untangle that >>> >>> f) Should middlebox information be reflected over the receiver or can t= hey also be send directly to the sender (and might take a different route)? >>> -> Maybe there should be a possibility to sent directly to the sender; = for unidirectional flows the receiver may not have a bearer flow to carry t= he message back and thus would generate spud-only packets which maybe quite= a bit overhead. However reflection over the receiver should be preferred. >>> >> Middleboxes often have a locality associated with them, e.g. home >> router, enterprise firewall. In such cases, it seems like returning >> information directly is a better use of resources and limits the >> exposure of the data. For example, if your firewall wants to provide >> the client with it's connection timeout, it can send that back >> directly rather than forwarding this to some server halfway around the >> world and expecting the them to properly reflect the information when >> they should not care about this. To the server this is just extra work >> and extra memory that needs to be allocated for each flow (possibly >> millions of them). > > For time-outs I rather would like to see a mechanism where this informati= on is reflected over the receiver because what you are actually looking for= it not the time-out of your local firewall (you might already know that ov= er a different channel) but the minimum time-out of all middleboxes on the = path. Otherwise if you just request the time-out, every (Spud-aware) middle= box on the path would need to send you a separate reply. Of course the midd= lebox with the smallest time-out might not be spud-aware but that=E2=80=99s= different problem. > How big of problem is this likely to be? How many middleboxes do you foresee in paths that will be maintaining flow state with timeouts? Also, see my comment about keep-alivess, I'm hoping we can get a better solution which eliminates the need for knowing timeouts and sending keep-alives in the first place! Tom > Mirja > > > > From nobody Tue Aug 11 14:02:44 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148001B2AB8 for ; Tue, 11 Aug 2015 14:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9uhZp_PsZgQ for ; Tue, 11 Aug 2015 14:02:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133AB1B2AB0 for ; Tue, 11 Aug 2015 14:02:43 -0700 (PDT) Received: from [128.9.184.187] ([128.9.184.187]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t7BL1lkT018310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Aug 2015 14:01:53 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Roland Bless References: <1AFABFF2-B841-4B0D-867C-709683BEDC8D@tik.ee.ethz.ch> <55C9A2D5.9060304@kit.edu> <0F26B0A9-8042-472D-92B0-9D2822B5D1A3@tik.ee.ethz.ch> From: Joe Touch Message-ID: <55CA62B9.7000202@isi.edu> Date: Tue, 11 Aug 2015 14:01:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <0F26B0A9-8042-472D-92B0-9D2822B5D1A3@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud@ietf.org, touch@isi.edu Subject: Re: [Spud] Return routability and feedback X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 21:02:44 -0000 On 8/11/2015 2:38 AM, Mirja Kühlewind wrote: >>> c) Is a stop flag needed/useful? —> Yes (faster state tear-down), but >>> >> the overlying protocol must be resilient to it not being sent, not >>> >> being received.​ >> > >> > I don't understand this, is that different from a close? > No, it’s close. The question is do we need an explicate signal for close (and maybe even close/ack) or is it sufficient to just let the state time out because middleboxes anyway need a timer as they can never rely on seeing a close. You might want to look at the Delta-T protocol if you're willing to let time manage state this way. Joe From nobody Fri Aug 14 00:04:15 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7747E1A007A for ; Fri, 14 Aug 2015 00:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.618 X-Spam-Level: X-Spam-Status: No, score=-11.618 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcE1lFb9bBtL for ; Fri, 14 Aug 2015 00:04:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE441A0074 for ; Fri, 14 Aug 2015 00:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=501; q=dns/txt; s=iport; t=1439535854; x=1440745454; h=date:from:to:subject:message-id:mime-version; bh=BHp3hJ1zfGLveXjhb9JiN4OvgZ2UuPRYb42q2XVvVH4=; b=h58dASZpTozPACg1tXthPUkdSrPNYlotf38WU5FV6ma8EONhub4u09EM F339v2RN2fAFajtIABSs0dMb6/F/ijPDkr8tIDtrgNzymrQQE8k+NPs0K VKkZK9rPVhddCINWnrT2r0/xqdo2WE25NBZZRlg/3MqpCe7s/CSAbrPKc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ACBgAQks1V/5BdJa1dgxu/PwEJiSgMOBQBAQEBAQEBgQqEZHs0BYkKqiOmFQsBAQEekHqEFQWNT4dMjGkDmiQmhB0egn8BAQE X-IronPort-AV: E=Sophos;i="5.15,676,1432598400"; d="scan'208";a="20432786" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 14 Aug 2015 07:04:13 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t7E74CWT009023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Aug 2015 07:04:12 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7E74BTT005602 for ; Fri, 14 Aug 2015 00:04:11 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7E74Bqr005601 for spud@ietf.org; Fri, 14 Aug 2015 00:04:11 -0700 Date: Fri, 14 Aug 2015 00:04:11 -0700 From: Toerless Eckert To: spud@ietf.org Message-ID: <20150814070411.GQ1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Spud] SPUD and anycast... ?! X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 07:04:14 -0000 Was there ever an extension for TCP or SCTP to "explicitly" deal with anycast, eg: SYN to reponder anycast, SYN-ACK back from responder unicast, but with data field indicating anycast address and nonce from SYN, then ACK back to responder unicast ? I can't remember / find anything like this right now. WOuld be lovely for SPUD to consier including something like this. Heck, could even do this with multicast and let initiator send ACK back to fastest responder ;-) Cheers Toerless From nobody Fri Aug 14 00:40:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F491A0277 for ; Fri, 14 Aug 2015 00:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ7UHd0lYllf for ; Fri, 14 Aug 2015 00:40:02 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A120E1A03A6 for ; Fri, 14 Aug 2015 00:40:02 -0700 (PDT) Received: from [192.168.1.104] (p508F1ACB.dip0.t-ipconnect.de [80.143.26.203]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B4CD31C0B461E; Fri, 14 Aug 2015 09:39:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Tuexen In-Reply-To: <20150814070411.GQ1667@cisco.com> Date: Fri, 14 Aug 2015 09:39:57 +0200 Content-Transfer-Encoding: 7bit Message-Id: <07E2D217-F71A-47DD-850D-F6F21855FBC1@lurchi.franken.de> References: <20150814070411.GQ1667@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.2104) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD and anycast... ?! X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 07:40:04 -0000 > On 14 Aug 2015, at 09:04, Toerless Eckert wrote: > > Was there ever an extension for TCP or SCTP to "explicitly" deal with > anycast, eg: SYN to reponder anycast, SYN-ACK back from responder > unicast, but with data field indicating anycast address and nonce from > SYN, then ACK back to responder unicast ? You can do that with SCTP and dynamic address re-conifguration. Randy Stewart and myself discussed this ages ago but never wrote an ID, since we didn't see a consumer of the idea. Best regards Michael > > I can't remember / find anything like this right now. WOuld be > lovely for SPUD to consier including something like this. Heck, > could even do this with multicast and let initiator send ACK > back to fastest responder ;-) > > Cheers > Toerless > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Fri Aug 14 04:59:44 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297881ACE42 for ; Fri, 14 Aug 2015 04:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.517 X-Spam-Level: X-Spam-Status: No, score=-13.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2ayVoMOGC0j for ; Fri, 14 Aug 2015 04:59:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8E01ACE3B for ; Fri, 14 Aug 2015 04:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1799; q=dns/txt; s=iport; t=1439553581; x=1440763181; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=kwSMrz4WCrG+9iHMMw7FKjEUl+z3kbVE7d7Cr5+Na0o=; b=ZzJeYuespvF1CiXuHCNMZsrx1GGFA9GHnfroEF/sB2Q8N4YZvNfPrDLK HsHdtnrJlgdjJRBwEnkxIqLkEuVbIyBtSsBw0/wmVpTCfxKzpDhrWqc9S cCSZjNlXFXM0Ppkjzbo733lXXjQPj1G+lY0/OrTTE5pwuumoRsNIztf+b U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBgDq1s1V/4ENJK1dgxtULTy+BwEJgWsMhXcCgT8MOBQBAQEBAQEBgQqEJAEBBAEBATc0CxALGAklDwUTNhMbiBMN0D8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXi1OFCQeELAWNT4dMjGkDmiQmhB0eM4JMAQEB X-IronPort-AV: E=Sophos;i="5.15,677,1432598400"; d="scan'208";a="24241656" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2015 11:59:40 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7EBxeWl004723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2015 11:59:40 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7EBxd21028404; Fri, 14 Aug 2015 04:59:39 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7EBxdEQ028403; Fri, 14 Aug 2015 04:59:39 -0700 Date: Fri, 14 Aug 2015 04:59:39 -0700 From: Toerless Eckert To: Michael Tuexen Message-ID: <20150814115939.GS1667@cisco.com> References: <20150814070411.GQ1667@cisco.com> <07E2D217-F71A-47DD-850D-F6F21855FBC1@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07E2D217-F71A-47DD-850D-F6F21855FBC1@lurchi.franken.de> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD and anycast... ?! X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 11:59:43 -0000 http://www.cachefly.com/2014/07/11/measuring-throughput-performance-dns-vs-tcp-anycast-routing/ Even beyond this easily googled example, i think that anycast TCP is used quite a bit and on web application you can often just have short lived TCP connection running completely on the anycast address and just redirect to a unicast URL when you know it's going to be long-lived (streaming). So i think the reason why this may not have come up is because for a good amount of applications, just ignoring the anycast problem leads to good enough solutions, and the solutions where this would not work may not had enough of a business case / working strategy to get this type of extension forced into TCP. Cheers toerless On Fri, Aug 14, 2015 at 09:39:57AM +0200, Michael Tuexen wrote: > > On 14 Aug 2015, at 09:04, Toerless Eckert wrote: > > > > Was there ever an extension for TCP or SCTP to "explicitly" deal with > > anycast, eg: SYN to reponder anycast, SYN-ACK back from responder > > unicast, but with data field indicating anycast address and nonce from > > SYN, then ACK back to responder unicast ? > You can do that with SCTP and dynamic address re-conifguration. Randy > Stewart and myself discussed this ages ago but never wrote an ID, since > we didn't see a consumer of the idea. > > Best regards > Michael > > > > I can't remember / find anything like this right now. WOuld be > > lovely for SPUD to consier including something like this. Heck, > > could even do this with multicast and let initiator send ACK > > back to fastest responder ;-) > > > > Cheers > > Toerless > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Aug 14 06:19:07 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15ECF1A1A79 for ; Fri, 14 Aug 2015 06:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KhwR0EZ98iy for ; Fri, 14 Aug 2015 06:19:04 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0181A00E9 for ; Fri, 14 Aug 2015 06:19:03 -0700 (PDT) Received: from [192.168.1.200] (p508F1E60.dip0.t-ipconnect.de [80.143.30.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 733281C0C0BCF; Fri, 14 Aug 2015 15:19:01 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Tuexen In-Reply-To: <20150814115939.GS1667@cisco.com> Date: Fri, 14 Aug 2015 15:19:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150814070411.GQ1667@cisco.com> <07E2D217-F71A-47DD-850D-F6F21855FBC1@lurchi.franken.de> <20150814115939.GS1667@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.2104) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD and anycast... ?! X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 13:19:06 -0000 > On 14 Aug 2015, at 13:59, Toerless Eckert wrote: >=20 > = http://www.cachefly.com/2014/07/11/measuring-throughput-performance-dns-vs= -tcp-anycast-routing/ >=20 > Even beyond this easily googled example, i think that anycast TCP is > used quite a bit and on web application you can often just have short > lived TCP connection running completely on the anycast address and = just If you want to use anycast with TCP, how do you make sure that all TCP packets with the same anycast destination address end up at the same = host? For SCTP you would only use an anycast address as the destination = address of the first packet and then the server uses a unicast address. Since SCTP supports multiple IP addresses and dynamic address reconfiguration, that is possible. Similar things can be done with MPTCP, but not with TCP. Best regards Michael > redirect to a unicast URL when you know it's going to be long-lived = (streaming). > So i think the reason why this may not have come up is because for a = good amount > of applications, just ignoring the anycast problem leads to good = enough > solutions, and the solutions where this would not work may not had > enough of a business case / working strategy to get this type of = extension > forced into TCP. >=20 > Cheers > toerless >=20 > On Fri, Aug 14, 2015 at 09:39:57AM +0200, Michael Tuexen wrote: >>> On 14 Aug 2015, at 09:04, Toerless Eckert wrote: >>>=20 >>> Was there ever an extension for TCP or SCTP to "explicitly" deal = with >>> anycast, eg: SYN to reponder anycast, SYN-ACK back from responder >>> unicast, but with data field indicating anycast address and nonce = from >>> SYN, then ACK back to responder unicast ? >> You can do that with SCTP and dynamic address re-conifguration. Randy >> Stewart and myself discussed this ages ago but never wrote an ID, = since >> we didn't see a consumer of the idea. >>=20 >> Best regards >> Michael >>>=20 >>> I can't remember / find anything like this right now. WOuld be >>> lovely for SPUD to consier including something like this. Heck, >>> could even do this with multicast and let initiator send ACK >>> back to fastest responder ;-) >>>=20 >>> Cheers >>> Toerless >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >=20 From nobody Fri Aug 14 06:24:06 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B941A8F34 for ; Fri, 14 Aug 2015 06:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.517 X-Spam-Level: X-Spam-Status: No, score=-13.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB7ZHOMZBYaj for ; Fri, 14 Aug 2015 06:24:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0871A1B49 for ; Fri, 14 Aug 2015 06:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3458; q=dns/txt; s=iport; t=1439558634; x=1440768234; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=L0PNDhge+NF2N+wnM09jeqhXIT5THNYNSd3mR6v+dhY=; b=luIZQHPCTk0YteUeoLfwGXvd0+D9BwGFjxDvLoY5Be2AZvDSHo11gSGu 23nXZ/3CEwG+QJuztxvrDuTwjwkYJAhHrlhJ+0Mn90ZtmnzfSzpNZcXUS DXt8EeY8A7lC5OMGVILST8off0CRzl3J70G57WwBoUMPkoDgFtb1ihI1x o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBgBP681V/5pdJa1dgxtULTy+CAEJgWsMhXcCgTgMOBQBAQEBAQEBgQqEIwEBAQMBAQEBNzQLBQsLGAklDwUTNhMbiAsIDdAiAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tThD5LB4QsBY1Ph0yMaQOaJCaEHR4zgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,678,1432598400"; d="scan'208";a="18564961" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 14 Aug 2015 13:23:53 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t7EDNrip027777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2015 13:23:53 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7EDNqG3003791; Fri, 14 Aug 2015 06:23:52 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7EDNqv6003790; Fri, 14 Aug 2015 06:23:52 -0700 Date: Fri, 14 Aug 2015 06:23:52 -0700 From: Toerless Eckert To: Michael Tuexen Message-ID: <20150814132352.GT1667@cisco.com> References: <20150814070411.GQ1667@cisco.com> <07E2D217-F71A-47DD-850D-F6F21855FBC1@lurchi.franken.de> <20150814115939.GS1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD and anycast... ?! X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 13:24:05 -0000 On Fri, Aug 14, 2015 at 03:19:00PM +0200, Michael Tuexen wrote: > > On 14 Aug 2015, at 13:59, Toerless Eckert wrote: > > > > http://www.cachefly.com/2014/07/11/measuring-throughput-performance-dns-vs-tcp-anycast-routing/ > > > > Even beyond this easily googled example, i think that anycast TCP is > > used quite a bit and on web application you can often just have short > > lived TCP connection running completely on the anycast address and just > If you want to use anycast with TCP, how do you make sure that all TCP > packets with the same anycast destination address end up at the same host? My paragraph meant to imply that the whole TCP connection does use anycast in this case, and the different instances of the anycast group are deployed so that ECMP can't happen, so the TCP connections will only fail in case of re-routing that changes metrics to have the anycast address flip over and that doesn't seem to a big enough problem in the deployment cases - because the servers are far enough apart from each other for example. > For SCTP you would only use an anycast address as the destination address of > the first packet and then the server uses a unicast address. Since SCTP > supports multiple IP addresses and dynamic address reconfiguration, that > is possible. Similar things can be done with MPTCP, but not with TCP. I thought to remembre from long time ago that the only architecturally sane anycast assumption is that a single packet will only reach a single anycast group member. As soon as you send two packets they may end uup in different ones. Of course, likelyhood for this is quite small. SO all i was saying is that it wold be lovely for SPUD to be able to support architecturally sane use of anycast. Seems simple enough to permit it. Cheers Toerless > Best regards > Michael > > redirect to a unicast URL when you know it's going to be long-lived (streaming). > > So i think the reason why this may not have come up is because for a good amount > > of applications, just ignoring the anycast problem leads to good enough > > solutions, and the solutions where this would not work may not had > > enough of a business case / working strategy to get this type of extension > > forced into TCP. > > > > Cheers > > toerless > > > > On Fri, Aug 14, 2015 at 09:39:57AM +0200, Michael Tuexen wrote: > >>> On 14 Aug 2015, at 09:04, Toerless Eckert wrote: > >>> > >>> Was there ever an extension for TCP or SCTP to "explicitly" deal with > >>> anycast, eg: SYN to reponder anycast, SYN-ACK back from responder > >>> unicast, but with data field indicating anycast address and nonce from > >>> SYN, then ACK back to responder unicast ? > >> You can do that with SCTP and dynamic address re-conifguration. Randy > >> Stewart and myself discussed this ages ago but never wrote an ID, since > >> we didn't see a consumer of the idea. > >> > >> Best regards > >> Michael > >>> > >>> I can't remember / find anything like this right now. WOuld be > >>> lovely for SPUD to consier including something like this. Heck, > >>> could even do this with multicast and let initiator send ACK > >>> back to fastest responder ;-) > >>> > >>> Cheers > >>> Toerless > >>> > >>> _______________________________________________ > >>> Spud mailing list > >>> Spud@ietf.org > >>> https://www.ietf.org/mailman/listinfo/spud From nobody Fri Aug 14 11:35:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258591A1ADA; Fri, 14 Aug 2015 11:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDlkJh_2pnUN; Fri, 14 Aug 2015 11:35:11 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id E5CA61A1AC1; Fri, 14 Aug 2015 11:35:10 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 68DE36CE5E; Fri, 14 Aug 2015 14:35:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; s=sasl; bh=Rn/ kicWlC4qSnL6vwHFaxHybywQ=; b=OiRzS6rBDeHZpBACkLLgEGWWZxugwtFH3gw W1wXcB2UbMOVgsYUvaku4jtql2AGqEw/ajkK4F0bs7oPXVgPXq5JU6q8OFR6MkxY kPHkMwhxTXjFp8PXs/FgJ1/ZoH+1D4xbHqLfhEav6V1pvDSnxhXVrMS0WOiHhUgO n65oaMoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; q=dns; s=sasl; b= l76t8VZKbyqBemz8yg7HI9phWkeyieDcCi0KKrQQ9+Bv74qRjvbVwoJUN3mw2TE0 YMCstAmKxeCrC/XcD8UIwQWIEwMpCszthJ1Sv+WJ83mYeJl05vwwsy0Q7cSVTa+p kMHu5dgcQO7X152SRrkbzn7qJpjZ0tbBD0FKPkuAves= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6126F6CE5B; Fri, 14 Aug 2015 14:35:09 -0400 (EDT) Received: from mail-ob0-f182.google.com (unknown [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id E8CE36CE5A; Fri, 14 Aug 2015 14:35:08 -0400 (EDT) Received: by obnw1 with SMTP id w1so67893566obn.3; Fri, 14 Aug 2015 11:35:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.24.7 with SMTP id q7mr4779917obf.43.1439577308471; Fri, 14 Aug 2015 11:35:08 -0700 (PDT) Received: by 10.202.77.72 with HTTP; Fri, 14 Aug 2015 11:35:08 -0700 (PDT) Date: Fri, 14 Aug 2015 11:35:08 -0700 Message-ID: From: "C. M. Heard" To: spud , tsvwg Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: 30C79B4E-42B3-11E5-83E6-63719F42C9D4-06080547!pb-smtp1.pobox.com Archived-At: Cc: Joe Touch Subject: Re: [Spud] New Version Notification for draft-touch-tsvwg-udp-options-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 18:35:12 -0000 On 7/22/2015 09:52 AM, Joe Touch wrote: > On 7/21/2015 11:22 PM, Brian Trammell wrote: > > hi Joe, > > > > Thanks for this draft; I appreciate the elegant redundancy-reducing > > length hack. :) > > > > Data in this case is, I know, hard to come by, but would you have > > any feel for how much stuff out there will just break when they see an > > inconsistency between IP and UDP length information? > > I have students starting this fall who will look into this and do some > tests. We have no information yet. In an off-list e-mail exchange with Joe a couple of weeks ago, I noted that every host stack implementation whose code I have inspected simply ignores bytes that are past the UDP length but within the IP payload length. The BSD-derived stacks trim the excess bytes before the data is passed to the application via the sockets interface. However, one embedded stack I have seen (which does not use a sockets API) makes all data available to the application, including the UDP header, and lets the application deal with excess bytes as it sees fit. I have zero information on the behavior of middleboxes (NAT/NAPT). Assuming that Joe's tests confirm these observations for both end systems and middleboxes, then the proposed UDP option trailer should be incrementally deployable as long as all options therein can be safely ignored if not understood. The degree of utility (or, at least, the length of time needed to make them useful) will of course depend strongly on whether middleboxes trim the trailer or leave it intact; if the prevalent middlebox practice is to trim it, then they won't be useful without updating middleboxes as well as end systems. Also, Joe, if you and your students have the time and resources to look at what middleboxes do with UDP packets where the IP header indicates a shorter length than the UDP header, that would be useful information, as it could open up a possible means to incorporate fragmentation in the UDP layer, independent of whether or not an options trailer is present. Mike Heard From nobody Fri Aug 14 16:34:37 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667AE1A9218 for ; Fri, 14 Aug 2015 16:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI-oQafxKDDU for ; Fri, 14 Aug 2015 16:34:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0699.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::699]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CEE1A916D for ; Fri, 14 Aug 2015 16:34:33 -0700 (PDT) Received: from BLUPR02MB1747.namprd02.prod.outlook.com (10.162.213.149) by BLUPR02MB020.namprd02.prod.outlook.com (10.242.191.28) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 14 Aug 2015 23:34:30 +0000 Received: from BLUPR02MB1747.namprd02.prod.outlook.com (10.162.213.149) by BLUPR02MB1747.namprd02.prod.outlook.com (10.162.213.149) with Microsoft SMTP Server (TLS) id 15.1.231.21; Fri, 14 Aug 2015 23:34:27 +0000 Received: from BLUPR02MB1747.namprd02.prod.outlook.com ([10.162.213.149]) by BLUPR02MB1747.namprd02.prod.outlook.com ([10.162.213.149]) with mapi id 15.01.0231.021; Fri, 14 Aug 2015 23:34:27 +0000 From: Michael Thornburgh To: Toerless Eckert , "spud@ietf.org" Thread-Topic: [Spud] SPUD and anycast... ?! Thread-Index: AQHQ1l9zJIjEsmoUDEm7JrdftL6wsp4LHBaAgABIj4CAABYsAIAAAVwAgACi0BA= Date: Fri, 14 Aug 2015 23:34:27 +0000 Message-ID: References: <20150814070411.GQ1667@cisco.com> <07E2D217-F71A-47DD-850D-F6F21855FBC1@lurchi.franken.de> <20150814115939.GS1667@cisco.com> <20150814132352.GT1667@cisco.com> In-Reply-To: <20150814132352.GT1667@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mthornbu@adobe.com; x-originating-ip: [192.150.10.208] x-microsoft-exchange-diagnostics: 1; BLUPR02MB1747; 5:nZqKRZ1pkhomxvXYKhmttNaGlR2BV1qVpF6F7fNVqYk7Ehe3jMtJIWZA5eclGsyJM/YHnMIxxzemkF/JAzeNOUtwb5mxUuCWmZviRDmADqH8KHe+SECdclIy4GYYat4FLg0UR/V0577SpeJfBKamvw==; 24:NansIVmbUlJvv5iro0HPhgoHSGcYzLszySV9H0qpp3DNcPc3Pr1os4UwaaJFarG/Etfy+3mBGtmH8IzTjE7ESSbrp2BImb/U9KgGc/rFWB0=; 20:V80VjAtifPM4UkerYdFl9XhpZYP2NTpv1Wi9grE0gB14444/n/R2BXA1hz3fLuTSPG4i9YDPjrEh2Hxn2Mph/w== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR02MB1747; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR02MB020; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR02MB1747; BCL:0; PCL:0; RULEID:; SRVR:BLUPR02MB1747; x-forefront-prvs: 066898046A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(189002)(51444003)(199003)(377454003)(24454002)(122556002)(2501003)(15975445007)(10400500002)(19580395003)(66066001)(10090500001)(86362001)(33656002)(101416001)(189998001)(8990500004)(64706001)(87936001)(76176999)(77156002)(5003600100002)(40100003)(50986999)(54356999)(68736005)(62966003)(107886002)(2900100001)(5002640100001)(2950100001)(5001960100002)(102836002)(77096005)(92566002)(19580405001)(74316001)(93886004)(4001540100001)(81156007)(46102003)(2656002)(106356001)(5001770100001)(97736004)(99286002)(105586002)(106116001)(76576001)(5001860100001)(5001830100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR02MB1747; H:BLUPR02MB1747.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2015 23:34:27.2752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR02MB1747 X-Microsoft-Exchange-Diagnostics: 1; BLUPR02MB020; 2:uUKjGtdxf4i0CrTjTKazaD43GYWsqs5JRy+6kyIZk6ILDrKpwP6Zwp8Ex84fWSdo/V2t8XyKys8Mb5/YUWBIEUiHY805SQy9c1+WqCJwQQQfyet/6dz9hugru/fJbumrxl9c19Q2YwHps6yd5PeGzZOzPIzbs1uh6KQDSljJiBc=; 3:rbcWIrK9lbrukiSbvCRv5daGZNZUBVc9v0iiMGj6F5PHRKdlkoYHATAd5PPzgDOv2be6ETNAMOaBYE2z7PLlGesgt9rPv58ufEH61l2hjdVIzzh2CIQOLLmlldSqTD6nwUIrSf9js9qE+eQnhnz/BA==; 25:JW+IzmhcGqKUo6urLDVPuuTduWBCLFNcwicqCQLuXFhbhME/Lh/RdbCBgtw+m8E4m0rZisBXX9sS5GMIjTvI4ddF52RS0R8Np+ZWhcusPVOKaQkF1lxOgGREGsXfK1WKeXIkkQYLo9kn1cNVcAg3CwhSi7M+aH+DthyCklmVOxwVjTh6Vk5jup6c3a6PbSaczvH7Gy+LYqdCXoB4gw4fvYE/uSknW42J9ISHjzZrOHdsfwJEuVyb0+6D2Tv7Zng55TzmDW4BONoARxH82ZqwkA==; 23:T3TTF2agLdTlMCgN2FCtU7GIHbGWBhV0QNBstY4KBRfzzGqdLXLIH3j3aq/q64T91S597BBOVfLMo3unNvXHM9j224gR8a7luZJOnKytQo9Whjguw8wn9/imJ+/wMV9M/DTHQgeQtPDvhVctXGct5Vt0DNPBKrBMFyaBOcZ7ucoQCt1Z3etcDSuTwnlRam1CRzHrZYYHaGzSZN/p22f24GS8zT88anUqXQcaI9GaUXkoeznvTClnHWKXifFFFhRU X-OriginatorOrg: adobe.com Archived-At: Subject: Re: [Spud] SPUD and anycast... ?! X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 23:34:36 -0000 RTMFP (RFC 7016) supports opening to an anycast or multicast address "out o= f the box". these cases aren't explicitly called out in the spec, but the = same mechanism that supports parallel open, redirectors, forwarders, and lo= ad distribution/fault tolerance also supports anycast/multicast. see Secti= on 3.5.1 (and subsections) of RFC 7016. opening to an anycast address could work in these ways: 1. anycast responder uses the anycast address for the session, as long as= the anycast routing is consistent for the lifetime of the session (otherwi= se the session will time out and die), same as with TCP or anything else 2. anycast responder uses its unicast address to respond with its RHello,= session is established to the unicast address 3. anycast responder uses its anycast address to respond with a Redirect = listing the responder's unicast address, initiator then tries unicast addre= ss and establishes the session note that if the client has an address/port restricted NAT or firewall, 2 w= on't work, but 3 would. for opening to a multicast address, the responders would all respond with a= n RHello. whichever one was received first would win and be selected by the= initiator for the session, and the other responses would be ignored (the s= ame situation as for the load distribution case in Section 3.5.1.7). -mike > -----Original Message----- > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: Friday, August 14, 2015 6:24 AM > To: Michael Tuexen > Cc: spud@ietf.org > Subject: Re: [Spud] SPUD and anycast... ?! >=20 > On Fri, Aug 14, 2015 at 03:19:00PM +0200, Michael Tuexen wrote: > > > On 14 Aug 2015, at 13:59, Toerless Eckert wrote: > > > > > > http://www.cachefly.com/2014/07/11/measuring-throughput-performance-d= ns-vs-tcp-anycast-routing/ > > > > > > Even beyond this easily googled example, i think that anycast TCP is > > > used quite a bit and on web application you can often just have short > > > lived TCP connection running completely on the anycast address and ju= st >=20 > > If you want to use anycast with TCP, how do you make sure that all TCP > > packets with the same anycast destination address end up at the same ho= st? >=20 > My paragraph meant to imply that the whole TCP connection does use anycas= t > in this case, and the different instances of the anycast group are deploy= ed > so that ECMP can't happen, so the TCP connections will only fail in case > of re-routing that changes metrics to have the anycast address flip over > and that doesn't seem to a big enough problem in the deployment cases - > because the servers are far enough apart from each other for example. >=20 > > For SCTP you would only use an anycast address as the destination addre= ss of > > the first packet and then the server uses a unicast address. Since SCTP > > supports multiple IP addresses and dynamic address reconfiguration, tha= t > > is possible. Similar things can be done with MPTCP, but not with TCP. >=20 > I thought to remembre from long time ago that the only architecturally > sane anycast assumption is that a single packet will only reach a single > anycast group member. As soon as you send two packets they may end uup > in different ones. Of course, likelyhood for this is quite small. SO all > i was saying is that it wold be lovely for SPUD to be able to support > architecturally sane use of anycast. Seems simple enough to permit it. >=20 > Cheers > Toerless >=20 > > Best regards > > Michael > > > redirect to a unicast URL when you know it's going to be long-lived (= streaming). > > > So i think the reason why this may not have come up is because for a= good amount > > > of applications, just ignoring the anycast problem leads to good enou= gh > > > solutions, and the solutions where this would not work may not had > > > enough of a business case / working strategy to get this type of exte= nsion > > > forced into TCP. > > > > > > Cheers > > > toerless > > > > > > On Fri, Aug 14, 2015 at 09:39:57AM +0200, Michael Tuexen wrote: > > >>> On 14 Aug 2015, at 09:04, Toerless Eckert wrote: > > >>> > > >>> Was there ever an extension for TCP or SCTP to "explicitly" deal wi= th > > >>> anycast, eg: SYN to reponder anycast, SYN-ACK back from responder > > >>> unicast, but with data field indicating anycast address and nonce f= rom > > >>> SYN, then ACK back to responder unicast ? > > >> You can do that with SCTP and dynamic address re-conifguration. Rand= y > > >> Stewart and myself discussed this ages ago but never wrote an ID, si= nce > > >> we didn't see a consumer of the idea. > > >> > > >> Best regards > > >> Michael > > >>> > > >>> I can't remember / find anything like this right now. WOuld be > > >>> lovely for SPUD to consier including something like this. Heck, > > >>> could even do this with multicast and let initiator send ACK > > >>> back to fastest responder ;-) > > >>> > > >>> Cheers > > >>> Toerless > > >>> > > >>> _______________________________________________ > > >>> Spud mailing list > > >>> Spud@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/spud >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Aug 14 21:23:39 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076551AD0CF for ; Fri, 14 Aug 2015 21:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.517 X-Spam-Level: X-Spam-Status: No, score=-13.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Grl4YTwZznDM for ; Fri, 14 Aug 2015 21:23:37 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A361AD0CE for ; Fri, 14 Aug 2015 21:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5947; q=dns/txt; s=iport; t=1439612616; x=1440822216; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=iVz047JHAIFwYcYf7fRmiy8PWiyQiAE0x4+o7Yk2zPw=; b=I5/Ud3Zjd2v1tf/7LFZq516ejE6FOpCqS0MkYwWszUSDKc9FiRE/ukwb +T2yljD0p9zXtjUpKlEkIwcWnRGqaHQtMFfXQp+Jb/SefsVdXCJ32Q+D0 i7pa3eGSKIBXsih2aiHi0sCXHEYvmwohpKhqKJZyIkIr32o8ucz/jO/m7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CjAwBJvs5V/51dJa1dgxtUab4SAQmBawyFdwKBLgw4FAEBAQEBAQGBCoQjAQEBAwEBAQE3NAsMBAsOAwQBAQEJHgcPBRMfCQ4TGwOICAgNz1sBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi1OEPksHBoQmBY1ShD+DDYxpA5olJoQdHjOCTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,682,1432598400"; d="scan'208";a="178539506" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2015 04:23:35 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7F4NZbL031521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Aug 2015 04:23:35 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t7F4NYi8028981; Fri, 14 Aug 2015 21:23:34 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t7F4NYGh028980; Fri, 14 Aug 2015 21:23:34 -0700 Date: Fri, 14 Aug 2015 21:23:34 -0700 From: Toerless Eckert To: Michael Thornburgh Message-ID: <20150815042334.GI1667@cisco.com> References: <20150814070411.GQ1667@cisco.com> <07E2D217-F71A-47DD-850D-F6F21855FBC1@lurchi.franken.de> <20150814115939.GS1667@cisco.com> <20150814132352.GT1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD and anycast... ?! X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 04:23:39 -0000 Nice. Does 3. in RTMFP imply one more RTT to start the session ? to just seed a (good) NAT/FW, it should be sufficient for responder to send the ACK to the responder instead of restarting with SYN ?! (to avoid one more RTT). Don't find the word multicast in the text though... Cheers Toerless On Fri, Aug 14, 2015 at 11:34:27PM +0000, Michael Thornburgh wrote: > RTMFP (RFC 7016) supports opening to an anycast or multicast address "out of the box". these cases aren't explicitly called out in the spec, but the same mechanism that supports parallel open, redirectors, forwarders, and load distribution/fault tolerance also supports anycast/multicast. see Section 3.5.1 (and subsections) of RFC 7016. > > opening to an anycast address could work in these ways: > > 1. anycast responder uses the anycast address for the session, as long as the anycast routing is consistent for the lifetime of the session (otherwise the session will time out and die), same as with TCP or anything else > > 2. anycast responder uses its unicast address to respond with its RHello, session is established to the unicast address > > 3. anycast responder uses its anycast address to respond with a Redirect listing the responder's unicast address, initiator then tries unicast address and establishes the session > > note that if the client has an address/port restricted NAT or firewall, 2 won't work, but 3 would. > > for opening to a multicast address, the responders would all respond with an RHello. whichever one was received first would win and be selected by the initiator for the session, and the other responses would be ignored (the same situation as for the load distribution case in Section 3.5.1.7). > > -mike > > > > -----Original Message----- > > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Toerless Eckert > > Sent: Friday, August 14, 2015 6:24 AM > > To: Michael Tuexen > > Cc: spud@ietf.org > > Subject: Re: [Spud] SPUD and anycast... ?! > > > > On Fri, Aug 14, 2015 at 03:19:00PM +0200, Michael Tuexen wrote: > > > > On 14 Aug 2015, at 13:59, Toerless Eckert wrote: > > > > > > > > http://www.cachefly.com/2014/07/11/measuring-throughput-performance-dns-vs-tcp-anycast-routing/ > > > > > > > > Even beyond this easily googled example, i think that anycast TCP is > > > > used quite a bit and on web application you can often just have short > > > > lived TCP connection running completely on the anycast address and just > > > > > If you want to use anycast with TCP, how do you make sure that all TCP > > > packets with the same anycast destination address end up at the same host? > > > > My paragraph meant to imply that the whole TCP connection does use anycast > > in this case, and the different instances of the anycast group are deployed > > so that ECMP can't happen, so the TCP connections will only fail in case > > of re-routing that changes metrics to have the anycast address flip over > > and that doesn't seem to a big enough problem in the deployment cases - > > because the servers are far enough apart from each other for example. > > > > > For SCTP you would only use an anycast address as the destination address of > > > the first packet and then the server uses a unicast address. Since SCTP > > > supports multiple IP addresses and dynamic address reconfiguration, that > > > is possible. Similar things can be done with MPTCP, but not with TCP. > > > > I thought to remembre from long time ago that the only architecturally > > sane anycast assumption is that a single packet will only reach a single > > anycast group member. As soon as you send two packets they may end uup > > in different ones. Of course, likelyhood for this is quite small. SO all > > i was saying is that it wold be lovely for SPUD to be able to support > > architecturally sane use of anycast. Seems simple enough to permit it. > > > > Cheers > > Toerless > > > > > Best regards > > > Michael > > > > redirect to a unicast URL when you know it's going to be long-lived (streaming). > > > > So i think the reason why this may not have come up is because for a good amount > > > > of applications, just ignoring the anycast problem leads to good enough > > > > solutions, and the solutions where this would not work may not had > > > > enough of a business case / working strategy to get this type of extension > > > > forced into TCP. > > > > > > > > Cheers > > > > toerless > > > > > > > > On Fri, Aug 14, 2015 at 09:39:57AM +0200, Michael Tuexen wrote: > > > >>> On 14 Aug 2015, at 09:04, Toerless Eckert wrote: > > > >>> > > > >>> Was there ever an extension for TCP or SCTP to "explicitly" deal with > > > >>> anycast, eg: SYN to reponder anycast, SYN-ACK back from responder > > > >>> unicast, but with data field indicating anycast address and nonce from > > > >>> SYN, then ACK back to responder unicast ? > > > >> You can do that with SCTP and dynamic address re-conifguration. Randy > > > >> Stewart and myself discussed this ages ago but never wrote an ID, since > > > >> we didn't see a consumer of the idea. > > > >> > > > >> Best regards > > > >> Michael > > > >>> > > > >>> I can't remember / find anything like this right now. WOuld be > > > >>> lovely for SPUD to consier including something like this. Heck, > > > >>> could even do this with multicast and let initiator send ACK > > > >>> back to fastest responder ;-) > > > >>> > > > >>> Cheers > > > >>> Toerless > > > >>> > > > >>> _______________________________________________ > > > >>> Spud mailing list > > > >>> Spud@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/spud > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Sat Aug 15 17:26:49 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12361B3089 for ; Sat, 15 Aug 2015 17:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQZpEqQthwnC for ; Sat, 15 Aug 2015 17:26:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0649.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::649]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B04E1B3088 for ; Sat, 15 Aug 2015 17:26:45 -0700 (PDT) Received: from CY1PR02MB1755.namprd02.prod.outlook.com (10.162.165.149) by CY1PR02MB1755.namprd02.prod.outlook.com (10.162.165.149) with Microsoft SMTP Server (TLS) id 15.1.231.21; Sun, 16 Aug 2015 00:26:39 +0000 Received: from CY1PR02MB1755.namprd02.prod.outlook.com ([10.162.165.149]) by CY1PR02MB1755.namprd02.prod.outlook.com ([10.162.165.149]) with mapi id 15.01.0231.024; Sun, 16 Aug 2015 00:26:39 +0000 From: Michael Thornburgh To: Toerless Eckert , "spud@ietf.org" Thread-Topic: [Spud] SPUD and anycast... ?! Thread-Index: AQHQ1l9zJIjEsmoUDEm7JrdftL6wsp4LHBaAgABIj4CAABYsAIAAAVwAgACi0BCAAFiQAIABSZxO Date: Sun, 16 Aug 2015 00:26:39 +0000 Message-ID: References: <20150814070411.GQ1667@cisco.com> <07E2D217-F71A-47DD-850D-F6F21855FBC1@lurchi.franken.de> <20150814115939.GS1667@cisco.com> <20150814132352.GT1667@cisco.com> , <20150815042334.GI1667@cisco.com> In-Reply-To: <20150815042334.GI1667@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mthornbu@adobe.com; x-originating-ip: [198.202.199.162] x-microsoft-exchange-diagnostics: 1; CY1PR02MB1755; 5:sMmDsnxlGu1ITy/bP0RXAhbi6hm45S8vPFp/+CWjo8Xd/fYA2VMsYznx0wyZ+kH5vsOoYFYrSLeUZlUbwD3bIxDerJHZ0gEikZ4pZ0voxNLvp30VFf0/fv7jbLLPTroWAdC0HZkWkUWvIsfDG5Z46Q==; 24:UICjhdp1DhTnduQuFy/MKgqI7c510ablPKNnCtiE3//ZkE5JbpknVx3Cqn1PZ7vi5GC6Ub6T4T+zKfxhSBKN3QJtHY0u+ABMFj5S5yUB58w=; 20:PBu01TFqhA33dpClYyVSLlFYDWyEaTsWB17UtmFOh4grS81VjiBkfsL0tjHKy6SbqxGSbqbesOH9I0SkYWSLrA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR02MB1755; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CY1PR02MB1755; BCL:0; PCL:0; RULEID:; SRVR:CY1PR02MB1755; x-forefront-prvs: 067071EFC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(51444003)(52314003)(24454002)(13464003)(377454003)(66066001)(40100003)(77096005)(2950100001)(77156002)(62966003)(68736005)(15975445007)(102836002)(2900100001)(50986999)(54356999)(99286002)(106356001)(2501003)(10090500001)(106116001)(105586002)(5003600100002)(76576001)(5002640100001)(92566002)(74316001)(64706001)(122556002)(10400500002)(101416001)(76176999)(5001830100001)(93886004)(8990500004)(2656002)(5001860100001)(87936001)(189998001)(33656002)(86362001)(19580395003)(19580405001)(4001540100001)(81156007)(5001960100002)(107886002)(46102003)(97736004)(5001920100001)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR02MB1755; H:CY1PR02MB1755.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2015 00:26:39.1448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1755 Archived-At: Subject: Re: [Spud] SPUD and anycast... ?! X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 00:26:48 -0000 yes, 3 implies one more RTT. you wouldn't want to have a combo redirect/RH= ello coming from the anycast address and just believe the unicast address i= n the redirect, because the initiator might not have bidirectional connecti= vity to the unicast address, or the initiator might use a different source = address to reach the unicast address (which might produce a different cooki= e, which would then take an additional RTT anyway, see Section 3.5.1.2). you could potentially save an RTT by combining 3 and 2 (sending a Redirect = from the anycast address AND sending an RHello from the unicast address). = if the RHello gets through then you're good, and if it doesn't then you spe= nd an extra RTT after receiving the Redirect. this would be very similar t= o the situation in Section 3.5.1.6. > Don't find the word multicast in the text though... as i said, anycast and multicast use cases aren't called out explicitly in = the spec. but they work with no special handling because there's already s= upport for multiple responders responding to the same IHello. the initiato= r matches the open responses based on an opaque tag rather than on IP addre= ss & port number, latches on the first acceptable response no matter where = it comes from, and uses the address/port from which that response came as t= he far socket address for the session. note that once the session is up, the address of either end can change, and= , depending on the NAT/firewall situation between the endpoints, the sessio= n can survive the address change. see Section 3.5.3 and Section 3.5.4.2. -mike ________________________________________ From: Toerless Eckert [eckert@cisco.com] Sent: Friday, August 14, 2015 9:23 PM To: Michael Thornburgh Cc: spud@ietf.org Subject: Re: [Spud] SPUD and anycast... ?! Nice. Does 3. in RTMFP imply one more RTT to start the session ? to just seed a (good) NAT/FW, it should be sufficient for responder to send the ACK to the responder instead of restarting with SYN ?! (to avoid o= ne more RTT). Don't find the word multicast in the text though... Cheers Toerless On Fri, Aug 14, 2015 at 11:34:27PM +0000, Michael Thornburgh wrote: > RTMFP (RFC 7016) supports opening to an anycast or multicast address "out= of the box". these cases aren't explicitly called out in the spec, but th= e same mechanism that supports parallel open, redirectors, forwarders, and = load distribution/fault tolerance also supports anycast/multicast. see Sec= tion 3.5.1 (and subsections) of RFC 7016. > > opening to an anycast address could work in these ways: > > 1. anycast responder uses the anycast address for the session, as long = as the anycast routing is consistent for the lifetime of the session (other= wise the session will time out and die), same as with TCP or anything else > > 2. anycast responder uses its unicast address to respond with its RHell= o, session is established to the unicast address > > 3. anycast responder uses its anycast address to respond with a Redirec= t listing the responder's unicast address, initiator then tries unicast add= ress and establishes the session > > note that if the client has an address/port restricted NAT or firewall, 2= won't work, but 3 would. > > for opening to a multicast address, the responders would all respond with= an RHello. whichever one was received first would win and be selected by t= he initiator for the session, and the other responses would be ignored (the= same situation as for the load distribution case in Section 3.5.1.7). > > -mike > > > > -----Original Message----- > > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Toerless Eckert > > Sent: Friday, August 14, 2015 6:24 AM > > To: Michael Tuexen > > Cc: spud@ietf.org > > Subject: Re: [Spud] SPUD and anycast... ?! > > > > On Fri, Aug 14, 2015 at 03:19:00PM +0200, Michael Tuexen wrote: > > > > On 14 Aug 2015, at 13:59, Toerless Eckert wrote: > > > > > > > > http://www.cachefly.com/2014/07/11/measuring-throughput-performance= -dns-vs-tcp-anycast-routing/ > > > > > > > > Even beyond this easily googled example, i think that anycast TCP i= s > > > > used quite a bit and on web application you can often just have sho= rt > > > > lived TCP connection running completely on the anycast address and = just > > > > > If you want to use anycast with TCP, how do you make sure that all TC= P > > > packets with the same anycast destination address end up at the same = host? > > > > My paragraph meant to imply that the whole TCP connection does use anyc= ast > > in this case, and the different instances of the anycast group are depl= oyed > > so that ECMP can't happen, so the TCP connections will only fail in cas= e > > of re-routing that changes metrics to have the anycast address flip ove= r > > and that doesn't seem to a big enough problem in the deployment cases - > > because the servers are far enough apart from each other for example. > > > > > For SCTP you would only use an anycast address as the destination add= ress of > > > the first packet and then the server uses a unicast address. Since SC= TP > > > supports multiple IP addresses and dynamic address reconfiguration, t= hat > > > is possible. Similar things can be done with MPTCP, but not with TCP. > > > > I thought to remembre from long time ago that the only architecturally > > sane anycast assumption is that a single packet will only reach a singl= e > > anycast group member. As soon as you send two packets they may end uup > > in different ones. Of course, likelyhood for this is quite small. SO al= l > > i was saying is that it wold be lovely for SPUD to be able to support > > architecturally sane use of anycast. Seems simple enough to permit it. > > > > Cheers > > Toerless > > > > > Best regards > > > Michael > > > > redirect to a unicast URL when you know it's going to be long-lived= (streaming). > > > > So i think the reason why this may not have come up is because for= a good amount > > > > of applications, just ignoring the anycast problem leads to good en= ough > > > > solutions, and the solutions where this would not work may not had > > > > enough of a business case / working strategy to get this type of ex= tension > > > > forced into TCP. > > > > > > > > Cheers > > > > toerless > > > > > > > > On Fri, Aug 14, 2015 at 09:39:57AM +0200, Michael Tuexen wrote: > > > >>> On 14 Aug 2015, at 09:04, Toerless Eckert wrot= e: > > > >>> > > > >>> Was there ever an extension for TCP or SCTP to "explicitly" deal = with > > > >>> anycast, eg: SYN to reponder anycast, SYN-ACK back from responder > > > >>> unicast, but with data field indicating anycast address and nonce= from > > > >>> SYN, then ACK back to responder unicast ? > > > >> You can do that with SCTP and dynamic address re-conifguration. Ra= ndy > > > >> Stewart and myself discussed this ages ago but never wrote an ID, = since > > > >> we didn't see a consumer of the idea. > > > >> > > > >> Best regards > > > >> Michael > > > >>> > > > >>> I can't remember / find anything like this right now. WOuld be > > > >>> lovely for SPUD to consier including something like this. Heck, > > > >>> could even do this with multicast and let initiator send ACK > > > >>> back to fastest responder ;-) > > > >>> > > > >>> Cheers > > > >>> Toerless > > > >>> > > > >>> _______________________________________________ > > > >>> Spud mailing list > > > >>> Spud@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/spud > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com=