Re: [Spud] endpoint control

Brian Trammell <ietf@trammell.ch> Tue, 28 June 2016 12:21 UTC

Return-Path: <ietf@trammell.ch>
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 4F4A412D13A for <spud@ietfa.amsl.com>; Tue, 28 Jun 2016 05:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_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 8ErFTMdJK1WH for <spud@ietfa.amsl.com>; Tue, 28 Jun 2016 05:21:08 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 487EE12D133 for <spud@ietf.org>; Tue, 28 Jun 2016 05:21:08 -0700 (PDT)
Received: from public-docking-cx-2148.ethz.ch (public-docking-pat-cx-mapped-0020.ethz.ch [195.176.111.21]) by trammell.ch (Postfix) with ESMTPSA id 7A20B1A061D; Tue, 28 Jun 2016 14:20:36 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_952BA5A5-78C4-4F48-A4A6-8B666E1C34B6"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <A4BAAB326B17CE40B45830B745F70F10EE37ACAE@VOEXM17W.internal.vodafone.com>
Date: Tue, 28 Jun 2016 14:20:35 +0200
Message-Id: <38EA0207-F18F-4AFC-B2CF-2FD7BA23281A@trammell.ch>
References: <A4BAAB326B17CE40B45830B745F70F10EE37ACAE@VOEXM17W.internal.vodafone.com>
To: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/hC3bVMBrwSjSuH50pVODVhteMJc>
Cc: "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: Tue, 28 Jun 2016 12:21:11 -0000

> On 28 Jun 2016, at 12:41, 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?

Correct. It doesn't provide that guarantee at all, by design.

> Or would such an authentication/integrity check applicable to path data be in scope of PLUS?

As I see it now, not at first. The cases where the endpoint reliably has an way to authenticate a middlebox are limited (though mobile access networks are one such case), and IMO the mechanism should be as general as possible.

I will point out that integrity and authentication of information from a middlebox where the sending endpoint can authenticate the middlebox can trivially be implemented on top of this proposed mechanism: the definition of the exposed information could be "content plus MAC", where the MAC can be verified using the middlebox's certificate. But these can be implemented in information elements atop PLUS, without requiring additional support in the PLUS header.

In a mobile access network, on the upstream path this would look like:

user terminal --[ PLUS mobile-foo: 00000000 ]--> access network --[ PLUS mobile-foo CCCCCCMM ]--> server

(where mobile-foo is whatever you want the access network to be able to say, 00000000 is scratch space, C is content and M is MAC.)

The server can act on the throughput guidance (should it choose to, see spud-req 5.9), but since it's the user terminal that has a relationship with the access network, the server may need to feed the content and MAC back to the user terminal (see spud-req 5.5 and 6.4) for verification.

Cheers,

Brian

> Cheers,
> Kevin
> Vodafone R&D
> 
> [1] https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03.txt , expired
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud