IETF Logo Mail Archive

Re: [Spud] endpoint control

"Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com> Wed, 29 June 2016 10:45 UTC

Return-Path: <Kevin.Smith@vodafone.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A541D12DB74 for <spud@ietfa.amsl.com>; Wed, 29 Jun 2016 03:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 RjzInhOIlE99 for <spud@ietfa.amsl.com>; Wed, 29 Jun 2016 03:45:56 -0700 (PDT)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.109]) (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 EF23112DB72 for <spud@ietf.org>; Wed, 29 Jun 2016 03:45:55 -0700 (PDT)
Received: from [193.109.255.99] by server-5.bemta-14.messagelabs.com id FF/ED-08132-1E6A3775; Wed, 29 Jun 2016 10:45:53 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRWlGSWpSXmKPExsVy+MWXVt2Hy4r DDSbuVLHY2PKOzWLRhaeMFpcvPWJ2YPbonTuN1WPJkp9MHk/2z2QJYI5izcxLyq9IYM24OOUU U8E8yYqp/46zNzB+kehi5OQQEtjDKNH+Ub6LkQvIXskocfL0IRYIZzmTxM32LawQzhFGiQMT7 zJDOJsZJTbdmc4K0s8m4CpxdNcddhBbREBV4sGE6ywgNrNAjMSMuQeZQGxhARWJmZeXscLU9P dOgKq3kthw8xPQUA4OFqD4+yXyIGFegVCJtrn72CB2zWaU+P7zIFg9p0CgxLy929hAbEYBWYk vjauZIXaJS9x6Mh9sl4SAgMSSPeeZIWxRiZeP/7GCzGcW0JRYv0sfolxRYkr3Q3aIXYISJ2c+ YZnAKDYLyaRZCB2zkHTMQtKxgJFlFaNGcWpRWWqRrqGBXlJRZnpGSW5iZo6uoaGJXm5qcXFie mpOYlKxXnJ+7iZGYMQxAMEOxnPLnA8xSnIwKYny6ucVhwvxJeWnVGYkFmfEF5XmpBYfYpTh4F CS4L2yFCgnWJSanlqRlpkDjH2YtAQHj5IIb+5ioDRvcUFibnFmOkTqFKOilDgvEzBhCAmAJDJ K8+DaYOnmEqOslDAvI9AhQjwFqUW5mSWo8q8YxTkYlYR534Js58nMK4Gb/gpoMRPQYuZSsMUl iQgpqQbGLkXJyav1zaXWpW3WMpr680zJ3mWvE5+ybLK/7ejgIm6Rr2Yl1/i82fZ9Y2iVy1WF4 PntfJeY3z1y0S1qUTC2uK4058zD6upAmRPurZ7MSltfTurjmB5/Z5VRY6PJXO2rTzkfZt/xXL vmkfUk/+mJkm1+mluDmpe3rf0gsoCj9JFpQ/OiktdKLMUZiYZazEXFiQBJ8d6XMgMAAA==
X-Env-Sender: Kevin.Smith@vodafone.com
X-Msg-Ref: server-11.tower-48.messagelabs.com!1467197153!8962962!1
X-Originating-IP: [195.232.244.133]
X-StarScan-Received:
X-StarScan-Version: 8.46; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13973 invoked from network); 29 Jun 2016 10:45:53 -0000
Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-11.tower-48.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 29 Jun 2016 10:45:53 -0000
Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout01.vodafone.com (Postfix) with ESMTP id 3rffTs18Srz1yG5; Wed, 29 Jun 2016 12:45:53 +0200 (CEST)
Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3rffTs02XVzxPZT; Wed, 29 Jun 2016 12:45:53 +0200 (CEST)
Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3rffTr6n4hzxP8s; Wed, 29 Jun 2016 12:45:52 +0200 (CEST)
Received: from AVOEXH03W.internal.vodafone.com (145.230.15.141) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 29 Jun 2016 12:45:52 +0200
Received: from VOEXM17W.internal.vodafone.com ([169.254.1.75]) by AVOEXH03W.internal.vodafone.com ([145.230.15.141]) with mapi id 14.03.0224.002; Wed, 29 Jun 2016 12:45:52 +0200
From: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>
To: Tom Herbert <tom@herbertland.com>
Thread-Topic: [Spud] endpoint control
Thread-Index: AdHRKB6Rk1yBi0AtT2GnUMPMbLGi+gAKs4sAACVbQKA=
Date: Wed, 29 Jun 2016 10:45:50 +0000
Message-ID: <A4BAAB326B17CE40B45830B745F70F10EE37B7F0@VOEXM17W.internal.vodafone.com>
References: <A4BAAB326B17CE40B45830B745F70F10EE37ACAE@VOEXM17W.internal.vodafone.com> <CALx6S35DbFk5ZXUf0ob+hziPb1d5xjZvGADP_g-rw=EYKbPOvw@mail.gmail.com>
In-Reply-To: <CALx6S35DbFk5ZXUf0ob+hziPb1d5xjZvGADP_g-rw=EYKbPOvw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/mvHQfQy77vE4l49Fs6KWER9jdkI>
Cc: "Brian Trammell (ietf@trammell.ch)" <ietf@trammell.ch>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] endpoint control
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2016 10:45:58 -0000

Hi Tom, 

> Do you see any reason (other than maybe current deployability) that these can't be done in HBH options instead of TCP options?

Probably down to forwarding performance too, as Hop-by-Hop must be processed by all network devices. And deployability as you say; because IPv6 is unfortunately not prevalent yet in mobile core networks...

https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05 recommends using other extension headers instead, due to a denial of service threat. But these are intended for the destination and not interim nodes, and we'd need to check that EH are consistently passed across a range of vendors' routers.

Many thanks,
Kevin

-----Original Message-----
From: Tom Herbert [mailto:tom@herbertland.com] 
Sent: 28 June 2016 18:37
To: Smith, Kevin, (R&D) Vodafone Group
Cc: Brian Trammell (ietf@trammell.ch); spud@ietf.org
Subject: Re: [Spud] endpoint control

On Tue, Jun 28, 2016 at 3:41 AM, Smith, Kevin, (R&D) Vodafone Group <Kevin.Smith@vodafone.com> wrote:
> Hi Brian,
>
> I think Mobile Throughput Guidance would be a good candidate for PLUS path-to-endpoint signalling. The latest (albeit expired) MTG draft [1] is bound to TCP Options, and was considering use of TCP-AO for authentication; PLUS could allow MTG for both TCP and UDP-based flows. However it seems that proposed PLUS mechanism:
>
>>(1) For forward signaling, the sending endpoint must place "scratch space" in the packet with a label on it stating that it's okay to modify; this okay-to-modify state is enforced by a MAC which only verifies the length but not the content of the scratch space.
>
> ...may not provide the guarantee that (1) the MTG information was indeed injected by the cellular network and (2) that it has not been modified by another node. Have I got that right? Or would such an authentication/integrity check applicable to path data be in scope of PLUS?
>
> Cheers,
> Kevin
> Vodafone R&D
>
> [1] 
> https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidanc
> e-03.txt , expired
>
Hi Kevin,

That is an interesting use case. Do you see any reason (other than maybe current deployability) that these can't be done in HBH options instead of TCP options?

Thanks,
Tom


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

v2.23.0 | Report a Bug | By Email