Re: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00))

Toerless Eckert <eckert@cisco.com> Mon, 10 August 2015 19:40 UTC

Return-Path: <eckert@cisco.com>
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 <spud@ietfa.amsl.com>; 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 <spud@ietfa.amsl.com>; 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 <spud@ietf.org>; 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 <eckert@cisco.com>
To: Ted Hardie <ted.ietf@gmail.com>
Message-ID: <20150810194018.GX1667@cisco.com>
References: <20150810184147.GW1667@cisco.com> <CA+9kkMCkaKJ8Bn8rVfDtAKwewWgRXdxJ_HOK+XioCu5FMZ7J+w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+9kkMCkaKJ8Bn8rVfDtAKwewWgRXdxJ_HOK+XioCu5FMZ7J+w@mail.gmail.com>
User-Agent: Mutt/1.4.2.2i
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/b58ausne7VVtjPKc_3KIcxJ3qM8>
X-Mailman-Approved-At: Mon, 10 Aug 2015 13:20:38 -0700
Cc: Eric Rescorla <ekr@rtfm.com>, "Black, David" <david.black@emc.com>, Mirja =?iso-8859-1?Q?K=FChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Joe Hildebrand <jhildebr@cisco.com>, "spud@ietf.org" <spud@ietf.org>, Christian Huitema <huitema@microsoft.com>, Ken Calvert <calvert@netlab.uky.edu>, Brian Trammell <ietf@trammell.ch>, Jana Iyengar <jri@google.com>
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 <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: 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 <insert right token>
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 <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
> > 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