[Spud] SPUD/PLUS Integrity
Dave Dolson <ddolson@sandvine.com> Wed, 20 July 2016 21:43 UTC
Return-Path: <ddolson@sandvine.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 A36C112D133 for <spud@ietfa.amsl.com>; Wed, 20 Jul 2016 14:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.206
X-Spam-Level:
X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 5ZpXZNOlRd2r for <spud@ietfa.amsl.com>; Wed, 20 Jul 2016 14:43:48 -0700 (PDT)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF0B12B05D for <spud@ietf.org>; Wed, 20 Jul 2016 14:43:47 -0700 (PDT)
Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 20 Jul 2016 17:43:46 -0400
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0294.000; Wed, 20 Jul 2016 17:43:46 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: "spud@ietf.org" <spud@ietf.org>
Thread-Topic: SPUD/PLUS Integrity
Thread-Index: AdHiyuAEWW3tvt+uRKGHx2/tJcFn3Q==
Date: Wed, 20 Jul 2016 21:43:46 +0000
Message-ID: <E8355113905631478EFF04F5AA706E983103224A@wtl-exchp-2.sandvine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.196.10]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E983103224Awtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/yYvy3_5c6Pfomk8hm3CkwwkbTHs>
Subject: [Spud] SPUD/PLUS Integrity
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, 20 Jul 2016 21:43:49 -0000
In draft-trammell-spud-req-04, Section "6.3 Integrity" says, "Endpoints should be able to detect changes to headers SPUD uses for its own signaling..." It does not (in this section, at least) say that elements on the path should be able to detect changes to the headers. Is this omission accidental or intentional? Section 1.1.1 in the spud-use-cases document does indicate there may be some situations in which there could be such verifiability. There are a few charging-related use-cases that would be assisted by confirming that a sender has the authority to say what it said. I can also imagine how DDoS scrubbing might be assisted by examining some integrity aspect of the PLUS/SPUD layer. -Dave
- [Spud] SPUD/PLUS Integrity Dave Dolson