RE: [dtn-security] 00 version of the Bundle Security Protocol Spec.
"Susan F. Symington" <susan@mitre.org> Wed, 25 May 2005 15:37 UTC
Received: from smtp-bedford.mitre.org (smtp-bedford-x.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PFb1V30618 for <dtn-security@mailman.dtnrg.org>; Wed, 25 May 2005 08:37:01 -0700
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j4PFb1232703 for <dtn-security@mailman.dtnrg.org>; Wed, 25 May 2005 11:37:01 -0400
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 0068BBEFB for <dtn-security@mailman.dtnrg.org>; Wed, 25 May 2005 11:37:00 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.28.8]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j4PFb0N32639; Wed, 25 May 2005 11:37:00 -0400
Message-Id: <200505251537.j4PFb0N32639@smtp-bedford.mitre.org>
Received: from mm122433-pc.mitre.org (128.29.14.10) by mailhub2.mitre.org with SMTP id 12460727; Wed, 25 May 2005 11:36:53 -0400
From: "Susan F. Symington" <susan@mitre.org>
To: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>
Cc: dtn-security@mailman.dtnrg.org, 'Howard Weiss' <howard.weiss@sparta.com>
Subject: RE: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Date: Wed, 25 May 2005 11:36:50 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-reply-to: <42944BEF.7090007@cs.tcd.ie>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-index: AcVhD4mMCAQCrOSBS5CFH9DFMRpoZwAKwZxQ
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>
Stephen, 1. One of the decisions that was made at the Berkeley meetings last week was that the dictionary header would contain all endpoint ids (EIDs) that appear in the bundle header, including the four in the primary bundle header, any security-related EIDs, any EIDs used in a source route header, etc. I understand your point that the security EIDs are only present in the security headers if they are different from the source and destination EIDs. At first I agreed with you that there would therefore be no gain in using the dictionary header for the security EIDs. However, after thinking about it I think that it makes sense to use the dictionary header, as decided. For one thing, a security EID might be the same as a report-to EID. Furthermore, if a source route header does eventually get defined, a security source or destination may very well be the same as an EID in the source route. So, I think there may be good reason to have the PSH-security-source and other security fields be offsets into the dictionary header than self-contained SDNVs. 2. Also according to last week's discussions, EIDs will be represented as a pair of two-byte offsets in the dictionary: one byte for scheme and 1 byte for SSP (Scheme-specific-part). If we do use the dictionary then is there still something wrong with the encoding? I'm not sure I see it. I don't think there is both and offset and length to mark the start and end of each string in the dictionary. I believe that we are using only offsets, with the end of each string being determined by the start of the next. (Now that I think about it, this may be a pain (but still doable) if the offsets are coming from lots of different headers, and not just the primary bundle header, but that's not a security issue; its an issue of how to structure the pointers into the dictionary header.) If there is still something wrong with the encoding, can you please explain it? 3. Even if there is nothing incorrect about the current encoding, it seems like we will want to make the ciphersuite field bigger. Do you want to do it now? -susan ***************************************************************** PLEASE NOTE: The exchange for Susan Symington's work numbers has changed from "883" to "983". So, her new office contact information is now: 703-983-7209 (voice) 708-983-7142 (fax) Please make a note of this change. Thanks! ****************************************************************** -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May 25, 2005 5:57 AM To: Susan F. Symington Cc: dtn-security@mailman.dtnrg.org; 'Howard Weiss' Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. Hi Susan, I think that this is fine to go, but I believe there was one change discussed last week that might be worth getting into the -00 version, since as currently written the encoding doesn't quite work;-) The current text uses 3 bits of the ciphersuite ID to indicate presence/absence of the of src/dest/parms. It appears (from last week's chats) that each of these is better encoded as SDNVs contained in the BAH,PSH or CH (since src/dest are only present when not the same as something already present/known, so there's no major gain in using the dictionary header). Given that, then we can use '00'H to indicate absence at the cost of 3 bytes, but if we're adding a BAH,PSH or CH the overall cost is probably so high that the additional 3 bytes are acceptable. That also solves the ciphersuite ID-size issue since 5 bits isn't really enough, but 8 bits probably is. If the 3 byte overhead (call that plan A) isn't acceptable, then I'd suggest we try plan B: a) make the change to use SDNV-8 for src & dest and not use the dictionary header for these, b) make the ciphersuite ID a 16-bit field, with the top three bits used for presence/absence of src/dest/parms, with maybe another 3 bits reserved and a 10-bit ciphersuite ID. That'd involve a 1-byte overhead on all messages, but makes messages that contain a src, dest & parms a byte bigger than otherwise. (I don't mind which plan we go with for now. I suppose plan B is very slightly better since we get those "reserved" bits:-) All the changes for this are contained in section 3.1 since later sections always (hopefully) talk about the fields being present/absent without getting into encoding details. So, if you've time before posting, I think it'd be worthwhile, but as I say, its ok as-is for a -00 IMO. (If you're stuck for time but want the change, you can fire over the xml and I'll do the editing.) Regards, Stephen. PS: The reason the current encoding doesn't work is that as I understand it the "natural" encoding of endpoint IDs can use the dictionary header so as written we're missing some offset/length field to allow the decoder to spot the end of the src field/start of the dest field when both are present.
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Rajesh Krishnan
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- Re: [dtn-security] 00 version of the Bundle Secur… Scott Burleigh
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Howard Weiss
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Rajesh Krishnan
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- Re: are offsets enough? --was: (dictionary or not… Michael Demmer
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- I18N (was: Re: (dictionary or not) Re: [dtn-secur… Stephen Farrell
- [dtn-security] Re: are offsets enough? --was: (di… Stephen Farrell
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Stephen Farrell
- [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- RE:are offsets enough? --was: (dictionary or not)… Susan F. Symington
- Re: [dtn-dev] Re: [dtn-security] 00 version of th… Michael Demmer
- [dtn-security] Re: [dtn-dev] Re: SDNV-new Michael Demmer
- Re: (dictionary or not) Re: [dtn-security] 00 ver… Scott Burleigh
- [dtn-security] Re: [dtn-dev] Re: SDNV-new Scott Burleigh
- Re: [dtn-dev] Re: [dtn-security] 00 version of th… Scott Burleigh
- Re: (dictionary or not) Re: [dtn-security] 00 ver… Michael Demmer
- Re: SDNV-new (was: Re: [dtn-security] 00 version … Michael Demmer
- Re: [dtn-security] 00 version of the Bundle Secur… Wesley Eddy
- SDNV-new (was: Re: [dtn-security] 00 version of t… Stephen Farrell
- Re: (dictionary or not) Re: [dtn-security] 00 ver… Stephen Farrell
- Re: (dictionary or not) Re: [dtn-security] 00 ver… Michael Demmer
- RE: [dtn-security] 00 version of the Bundle Secur… Susan F. Symington
- (dictionary or not) Re: [dtn-security] 00 version… Stephen Farrell
- Re: [dtn-security] 00 version of the Bundle Secur… Michael Demmer
- Re: [dtn-security] 00 version of the Bundle Secur… Michael Demmer
- Re: [dtn-security] 00 version of the Bundle Secur… Stephen Farrell
- [dtn-security] 00 version of the Bundle Security … Susan F. Symington
- Re: [dtn-security] Re: SDNV-new : OK Stephen Farrell
- Re: [dtn-security] 00 version of the Bundle Secur… Stephen Farrell
- [dtn-security] Re: SDNV-new : OK Manikantan Ramadas
- Re: [dtn-security] 00 version of the Bundle Secur… Howard Weiss
- Re: [dtn-security] 00 version of the Bundle Secur… Scott Burleigh
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Manikantan Ramadas
- RE: [dtn-security] 00 version of the Bundle Secur… Susan F. Symington
- Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new stephen.farrell
- Re: [dtn-security] meeting at IETF? Kevin Fall
- [dtn-security] meeting at IETF? Sandra Murphy