IETF Logo Mail Archive

Re: [Spud] Additional SPUD use-cases

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Thu, 19 March 2015 17:17 UTC

Return-Path: <jhildebr@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 294A71A6EE9 for <spud@ietfa.amsl.com>; Thu, 19 Mar 2015 10:17:19 -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 3h0Af8SVSdNE for <spud@ietfa.amsl.com>; Thu, 19 Mar 2015 10:17:18 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD291A3BA6 for <spud@ietf.org>; Thu, 19 Mar 2015 10:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1972; q=dns/txt; s=iport; t=1426785431; x=1427995031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9fnkhNenfDZEqSV0Veu030iJGdIw2lA10a2xlgqerkI=; b=Ba4hZDWr68UfPuCSarwl+5lPILzhCStRJd5lDJNY4JqSbURS2jQxMIz6 grYO2WBXLVymKiNNAI3J56NMdVNzdFUObEhhrCV8OHUJvMHjgL+HK8t3l 7Z+7OtzJwB8gbDJfOAQAWXkhpgV89SHInFAObxvD8kwVgpwqTAOaqGAck o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BYCgA8AwtV/5pdJa1cgwaBLASDCcBfiC8CHIEwTAEBAQEBAX2EEAEBBCMRRRACAQgaAiYCAgIwFRACBAENBYgvsjacAAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hBklMweCaC+BFgEEkEmJbQGUJyKDbm8BgQFCfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,430,1422921600"; d="scan'208";a="405372708"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 19 Mar 2015 17:17:11 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2JHHA7G026975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 17:17:10 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 12:17:10 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>, "Pal Martinsen (palmarti)" <palmarti@cisco.com>, Carsten Bormann <cabo@tzi.org>, Mike Jones <Michael.Jones@microsoft.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, Richard Barnes <rlb@ipv.sx>
Thread-Topic: [Spud] Additional SPUD use-cases
Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fqEUAgABEwYCAANXxgIADhomA//+2xAA=
Date: Thu, 19 Mar 2015 17:17:10 +0000
Message-ID: <E6385C88-2236-40EC-BABB-61A97E129EBB@cisco.com>
References: <B57E4F68-A0C6-44D8-A729-47B1BED309C9@cisco.com> <CA+9kkMB4kfmMuR61aAhHLzrhEK37dEqy9cpdaqdtzpuyoCbBfg@mail.gmail.com> <CE03DB3D7B45C245BCA0D24327794936412E51@MX104CL02.corp.emc.com> <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch>
In-Reply-To: <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/15.8.1.150311
x-originating-ip: [10.129.24.156]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8B184F6BE8B3414A9FC3CC396D625832@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/mi-mqATkaSEEyQ8X0ti0Dx50dno>
Cc: "Black, David" <david.black@emc.com>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] Additional SPUD use-cases
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: <http://www.ietf.org/mail-archive/web/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: Thu, 19 Mar 2015 17:17:19 -0000

On 3/19/15, 9:38 AM, "Mirja Kühlewind" <mirja.kuehlewind@tik.ee.ethz.ch> wrote:

>just a quick though on our comment regarding basically ‚why does DSCP not work inter-domain‘. One answer to this question is that is it mostly used intra-domain and that’s okay. That’s why we look at SPUD because we actually what something inter-domain (at least to signal information without negotiation). Therefore the questions for SPUD are for me:
>
>- How can we ensure that information provided by the end-point does not get modified?
>
>and more complicated
>
>- How can we ensure that information a middlebox puts in is not (wrongly) modified by another middlebox (as there are cases, we we want one middlebox to override data of another middlebox…?)

I'm CC'ing in some people that I know are interested in working on "COSE", a recoding of JOSE into CBOR, but who may not be subscribed to the SPUD list.

One approach we could take is have the client put a (tube-specific? time-limited?) public key into each OPEN packet in a path-accessible way.  Assertions from the application could be signed with the corresponding private key, assertions from the path could be encrypted with the public key.  

I'm worried about the CPU overhead for middleboxen, but we could both make this optional in the protocol and required-by-default in the library to see what the market shakes out as use cases.

-- 
Joe Hildebrand

v2.8.7 | Report a Bug | By Email