Subject: Re(2): [dtn-interest] Re: bundle security protocol
From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Wesley Eddy" <[email-masked]>, "dtn interest" <[email-masked]>, Susan <[email-masked]>, hsw <[email-masked]>, "Peter Lovell" <[email-masked]>
Date: Thu, 30 Aug 2007 17:42:44 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

On Tue, Aug 28, 2007, Stephen Farrell <[email-masked]> wrote:

>
>
>Peter Lovell wrote:
>
>> This is something which came up recently doing things for
>> confidentiality C3 so I'll describe it in that context.
>> 
>> Confidentiality ciphersuites allow super-encryption. During discussion
>> in Dublin we agreed that super-encryption of the payload should also
>> apply to the earlier confidentiality parameters in the more-deeply-
>> nested CB. That way, payload data and encryption parameters have the
>> same level of protection.
>> 
>> We also want a confidentiality ciphersuite for metadata. We create
>> metadata (metadata block) and then protect it using different keys from
>> the payload.  Let's assume we have confidentiality ciphersuite C5 which
>> applies just to metadata.
>
>Urgh. Can't we re-define the current ciphersuite somehow so that
>it can be re-used for new blocks as well as currently defined ones?
>
>If not, then I think we're a bit broken.
>
>S.

Yeah - I think we're a bit broken. For the moment I'm not tearing in to
create any new stuff as the thought processes still need to gel a bit.

We have several want-to's pulling in different directions.

In one, we want to incorporate metadata security under the overall BSP
umbrella, for lots of good reasons. This is quite important even if we
use new ways to get there.

Another one is that a "ciphersuite" is a complete package that defines
the actions, algorithms etc -- and there's not really any variability.
For example, BA1 requires two blocks and there's no flexibility to have
one-or-two. We may wish to revisit the "firmness" of the package but it
is what it is at least for now.

A third is categorization of the various security suites. Right now we
have hop-by-hop integrity checking (BA), end-to-end integrity checking
(PS) for data and data-related things, and confidentiality (C) for data
+ kitchen sink.

>... a bit broken.
If I had to guess, I'd suspect that the categorization is what's
primarily broken. We tried to apply confidentiality to non-data stuff
and hit a disconnect. I've not had the time recently to think about the
issues but expect to next week.

Cheers.....Peter

Date: Tue, 28 Aug 2007 17:57:35 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
CC: Wesley Eddy <[email-masked]>, dtn interest <[email-masked]>, Susan <[email-masked]>, hsw <[email-masked]>
Subject: Re: [dtn-interest] Re: bundle security protocol
Sender: [email-masked]

Peter Lovell wrote:

> This is something which came up recently doing things for
> confidentiality C3 so I'll describe it in that context.
> 
> Confidentiality ciphersuites allow super-encryption. During discussion
> in Dublin we agreed that super-encryption of the payload should also
> apply to the earlier confidentiality parameters in the more-deeply-
> nested CB. That way, payload data and encryption parameters have the
> same level of protection.
> 
> We also want a confidentiality ciphersuite for metadata. We create
> metadata (metadata block) and then protect it using different keys from
> the payload.  Let's assume we have confidentiality ciphersuite C5 which
> applies just to metadata.

Urgh. Can't we re-define the current ciphersuite somehow so that
it can be re-used for new blocks as well as currently defined ones?

If not, then I think we're a bit broken.

S.

Date: Tue, 28 Aug 2007 17:55:17 +0100
From: Stephen Farrell <[email-masked]>
To: "Weiss, Howard" <[email-masked]>
CC: "Symington, Susan F." <[email-masked]>, "Lovell, Peter" <[email-masked]>, Wesley Eddy <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Re: bundle security protocol
Sender: [email-masked]

Fair enough on changing to sdnvs for the ciphesuite and
flags.

I'd still like to discourage an explosion of ciphersuites
though, but given that this isn't a standards-track spec,
I can't see a very good way to do that. Ideas welcome.

S.

Content-class: urn:content-classes:message
Subject: RE: Re(2): [dtn-interest] Re: bundle security protocol
Date: Tue, 28 Aug 2007 10:42:03 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Symington, Susan F." <[email-masked]>, "Lovell, Peter" <[email-masked]>, "Wesley Eddy" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I never like to say "never" but....  I can't imagine needing more than
16-bits for ciphersuites and I hope that we never need more than a
handful but I'm too old to know that just because I can't imagine that
now, who knows what time will tell.  After all the original ARPAnet only
provided 6-bits for packet switch numbers (who would ever have more than
64 packet switch nodes on the net??)  :-)  Who would ever need more than
64K of RAM in a PC (and it was a LOT more than the 8K I had in my
PDP-8)?

I agree that making this an SDNV brings consistency and potential
expandability so it's a good thing - if it doesn't cost a lot in terms
of re-implementation to make this change so we don't look like
neanderthals sometime in the future.

Howie

> -----Original Message-----
> From: Symington, Susan F. [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2007 9:26 AM
> To: Lovell, Peter; Wesley Eddy; Stephen Farrell
> Cc: [email-masked]; Weiss, Howard
> Subject: RE: Re(2): [dtn-interest] Re: bundle security protocol
> 
> I agree with this.
> 
> -susan
> 
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
> 
> 
> >-----Original Message-----
> >From: Peter Lovell [mailto:[email-masked]]
> >Sent: Monday, August 27, 2007 5:03 PM
> >To: Wesley Eddy; Stephen Farrell; Peter Lovell
> >Cc: [email-masked]; Symington, Susan F.; hsw
> >Subject: Re(2): [dtn-interest] Re: bundle security protocol
> >
> >On Wed, Aug 15, 2007, Wesley Eddy <[email-masked]> wrote:
> >
> >>On Tue, Aug 14, 2007 at 11:22:45PM +0100, Stephen Farrell wrote:
> >>> >
> >>> >>6) Ciphersuite ID - why is this 16 bits?  Should it be an
> >SDNV, even just
> >>> >>  for consistency's sake?  It wasn't clear to me why this
> >was decided to
> >>> >>  be fixed-length.  It seemed to me like it should really
> >be 2 SDNVs
> >>> >>  instead of a single 16-bit field (one for format flags
> >indicating
> >>> >>  what other fields are present, and one for identifying
> >the algorithms).
> >>> >>  This would currently yield the same on-wire length
> >since there are only
> >>> >>  5 flags and a handful of algorithms, so it seems like a clear
> >>> >>  improvement
> >>> >>  unless I'm missing some point.
> >>> >
> >>> >I believe this is just historic. It could be SDNVs without
> >major impact.
> >>>
> >>> I'd rather not change, just about. There's no reason I can imagine
> >>> to want that many ciphersuites - each additional one is a
potential
> >>> non-interop opportunity, so there's a specific reason in
> >this case to
> >>> not want too much extensibillity. (Some ECC fans once turned up at
> >>> a TLS meeting wanting to define 96 new ciphersuites, each of which
> >>> was some other (non)encumbered variant ECC suite - a bad idea.)
> >>
> >
> >
> >I don't have an issue with limiting ciphersuites to some sane number,
> >but the fixed-size field in an anomaly. Along with numbering, we also
> >need [will need] some way to handle ciphersuite number assignment.
> >
> >More problematic for me is the non-expandable "flags" field. We've
> >changed the block-level flags to SDNV, primarily to allow
> >expansion, and
> >I would like to have the same ability with regard to ciphersuite
> flags.
> >I already have a need for at least one, as it turns out. I would not
> >like to bet that there won't be more.
> >
> >My preference would be to change these to two SDNVs, and set a
> >specification limit on how many suites.
> >
> >Cheers.....Peter
> >
> >

Content-class: urn:content-classes:message
Subject: RE: Re(2): [dtn-interest] Re: bundle security protocol
Date: Tue, 28 Aug 2007 09:25:55 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Wesley Eddy" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>, "hsw" <[email-masked]>
Sender: [email-masked]

I agree with this. 

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: Peter Lovell [mailto:[email-masked]] 
>Sent: Monday, August 27, 2007 5:03 PM
>To: Wesley Eddy; Stephen Farrell; Peter Lovell
>Cc: [email-masked]; Symington, Susan F.; hsw
>Subject: Re(2): [dtn-interest] Re: bundle security protocol
>
>On Wed, Aug 15, 2007, Wesley Eddy <[email-masked]> wrote:
>
>>On Tue, Aug 14, 2007 at 11:22:45PM +0100, Stephen Farrell wrote:
>>> >
>>> >>6) Ciphersuite ID - why is this 16 bits?  Should it be an 
>SDNV, even just
>>> >>  for consistency's sake?  It wasn't clear to me why this 
>was decided to
>>> >>  be fixed-length.  It seemed to me like it should really 
>be 2 SDNVs
>>> >>  instead of a single 16-bit field (one for format flags 
>indicating
>>> >>  what other fields are present, and one for identifying 
>the algorithms).
>>> >>  This would currently yield the same on-wire length 
>since there are only
>>> >>  5 flags and a handful of algorithms, so it seems like a clear 
>>> >>  improvement
>>> >>  unless I'm missing some point.
>>> >
>>> >I believe this is just historic. It could be SDNVs without 
>major impact.
>>> 
>>> I'd rather not change, just about. There's no reason I can imagine
>>> to want that many ciphersuites - each additional one is a potential
>>> non-interop opportunity, so there's a specific reason in 
>this case to
>>> not want too much extensibillity. (Some ECC fans once turned up at
>>> a TLS meeting wanting to define 96 new ciphersuites, each of which
>>> was some other (non)encumbered variant ECC suite - a bad idea.)
>>
>
>
>I don't have an issue with limiting ciphersuites to some sane number,
>but the fixed-size field in an anomaly. Along with numbering, we also
>need [will need] some way to handle ciphersuite number assignment.
>
>More problematic for me is the non-expandable "flags" field. We've
>changed the block-level flags to SDNV, primarily to allow 
>expansion, and
>I would like to have the same ability with regard to ciphersuite
flags.
>I already have a need for at least one, as it turns out. I would not
>like to bet that there won't be more.
>
>My preference would be to change these to two SDNVs, and set a
>specification limit on how many suites.
>
>Cheers.....Peter
>
>

From: "Peter Lovell" <[email-masked]>
To: "Wesley Eddy" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "Peter Lovell" <[email-masked]>
Cc: <[email-masked]>, Susan <[email-masked]>, hsw <[email-masked]>
Subject: Re(2): [dtn-interest] Re: bundle security protocol
Date: Mon, 27 Aug 2007 17:03:11 -0400
Sender: [email-masked]

On Wed, Aug 15, 2007, Wesley Eddy <[email-masked]> wrote:

>On Tue, Aug 14, 2007 at 11:22:45PM +0100, Stephen Farrell wrote:
>> >
>> >>6) Ciphersuite ID - why is this 16 bits?  Should it be an SDNV, even just
>> >>  for consistency's sake?  It wasn't clear to me why this was decided to
>> >>  be fixed-length.  It seemed to me like it should really be 2 SDNVs
>> >>  instead of a single 16-bit field (one for format flags indicating
>> >>  what other fields are present, and one for identifying the algorithms).
>> >>  This would currently yield the same on-wire length since there are only
>> >>  5 flags and a handful of algorithms, so it seems like a clear 
>> >>  improvement
>> >>  unless I'm missing some point.
>> >
>> >I believe this is just historic. It could be SDNVs without major impact.
>> 
>> I'd rather not change, just about. There's no reason I can imagine
>> to want that many ciphersuites - each additional one is a potential
>> non-interop opportunity, so there's a specific reason in this case to
>> not want too much extensibillity. (Some ECC fans once turned up at
>> a TLS meeting wanting to define 96 new ciphersuites, each of which
>> was some other (non)encumbered variant ECC suite - a bad idea.)
>

I don't have an issue with limiting ciphersuites to some sane number,
but the fixed-size field in an anomaly. Along with numbering, we also
need [will need] some way to handle ciphersuite number assignment.

More problematic for me is the non-expandable "flags" field. We've
changed the block-level flags to SDNV, primarily to allow expansion, and
I would like to have the same ability with regard to ciphersuite flags.
I already have a need for at least one, as it turns out. I would not
like to bet that there won't be more.

My preference would be to change these to two SDNVs, and set a
specification limit on how many suites.

Cheers.....Peter

From: Rajesh Krishnan <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Organization: BBN Technologies
Date: Wed, 22 Aug 2007 09:39:16 -0400
Subject: [dtn-interest] CHANTS 2007 Call for Participation
Sender: [email-masked]

                  CALL FOR PARTICIPATION

Second Workshop on Challenged Networks (CHANTS) 2007
====================================================

Co-located with Mobicom 2007, 14 September 2007, Montreal, QC, Canada

http://chants-2007.netlab.tkk.fi/

On behalf of the CHANTS 2007 committee, we extend an invitation to you
to participate in the 2nd ACM Workshop on Challenged Networks (CHANTS),
the third workshop in its series after WDTN 2005 and CHANTS 2006
focusing on communication in challenged networking environments in
general and delay-tolerant networking in particular.

Challenged and delay-tolerant communications are receiving more and more
attention.  The assumptions of the disruption-prone or opportunistic
nature of networking peered with potentially non-existing end-to-end
paths are becoming commonly accepted for research in many areas,
including (but not limited to) mobile ad-hoc and sensor networks as can
be witnessed from many recent publications addressing these issues.
Particularly ad-hoc communication among mobile human users with their
specific mobility patterns and application demands—for daily life and in
extreme situations such as disaster management—has attracted many
researchers’ attention.  We observe how research efforts expand their
scope in many ways highly relevant to the future of challenged
communications: from synthetic mobility models to realistic ones (e.g.,
based upon human mobility traces), from routing protocols and
optimizations to real applications, from isolated views of individual
problems to system and integration aspects, and from simulations to
implementations.  At the same time, fundamental research on
understanding and categorizing algorithms and protocols for challenged
networks are pursued to provide a more solid foundation where our
current understanding is still in the early stages.

We have an excellent program this year that reflects these trends in a
balanced way.  A keynote by Prof. Kevin Almeroth (University of
California, Santa Barbara, CA, USA) will set the stage giving his
perspectives on the future research questions at hand.  The program
includes 11 papers that cover basic concepts on DTN routing, the
interaction of routing and mobility including implementation aspects,
and a wide range of different applications for human interaction in
general as well as for specific scenarios.  In support of the trend
towards implementations, this year’s workshop provides a venue for
practical results and includes a demonstration session with 4
demonstrations, and this is complemented by 5 poster presentations of
early results of ongoing work.  The full program can be found at
http://chants-2007.netlab.tkk.fi/program.html 

We hope that you will enjoy the combination of theory and practice that
CHANTS 2007 has to offer and that you will find the papers and
presentations interesting and stimulating.  We look forward to seeing
you at CHANTS 2007 for a highly interactive workshop that should provide
an opportunity to share ideas and challenges with other researchers from
around the world.  

Joerg Ott and Rajesh Krishnan

======================================================================
Technical Program Co-chairs:

   Joerg Ott, Helsinki University of Technology (TKK)
   Email: [email-masked]
	
   Rajesh Krishnan, BBN Technologies
   Email: [email-masked]

Program Committee Members:

    Mostafa Ammar, Georgia Institute of Technology
    Prithwish Basu, BBN Technologies
    Scott Burleigh, NASA/JPL
    Chen-Nee Chuah, University of California, Davis
    Mooi Choo Chuah, Lehigh University
    Vania Conan, Thales Architecture Framework Centre
    Marco Conti, IIT-CNR
    Christophe Diot, Thomson
    Deborah Estrin, University of California at Los Angeles
    Kevin Fall, Intel Research
    Stephen Farrell, Trinity College Dublin
    Silvia Giordano, University of Applied Science - SUPSI
    Stephen Hailes, UCL Sushant Jain, Google
    Gunnar Karlsson, KTH, Royal Institute of Technology
    Srinivasan Keshav, University of Waterloo
    Dirk Kutscher, University of Bremen
    Jeremie Leguay, Univ. Pierre et Marie Curie
    Cecilia Mascolo, University College London
    Andrea Passarella, IIT-CNR
    Kaustubh Phanse, Lulea University of Technology
    James Scott, Microsoft Research
    Keith Scott, MITRE
    Arun Venkataramani, UMass Amherst
    Ellen Zegura, Georgia Institute of Technology

======================================================================

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Re: bundle security protocol
Date: Tue, 21 Aug 2007 13:03:50 -0400
From: "Scott, Keith L." <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, "Symington, Susan F." <[email-masked]>
Cc: "Wesley Eddy" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

In addition to the dtlsr router that ships with the reference
implementation I've got a Python script that runs RIP (over UDP) and
uses the TCL interface to mess with the forwarding tables of the DTN
static router.

		--keith 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lloyd Wood
Sent: Monday, August 20, 2007 4:35 PM
To: Symington, Susan F.
Cc: Wesley Eddy; [email-masked]
Subject: RE: [dtn-interest] Re: bundle security protocol

At Monday 20/08/2007 15:52 -0400, Symington, Susan F. wrote:

>It seems to me that if (security destination != destination), then
>eventually we will want to provide a solution for enabling the routing
>mechanisms to understand that they need to route to the security
>destination en route to the ultimate destination.

Do we have any working routing mechanisms, other than IP routing?

thanks,

L.

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 
_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Cc: Lloyd Wood <[email-masked]>, "Symington, Susan F." <[email-masked]>, Wesley Eddy <[email-masked]>, [email-masked]
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] Re: bundle security protocol
Date: Mon, 20 Aug 2007 13:55:57 -0700
To: Michael Demmer <[email-masked]>
Sender: [email-masked]

Mike didn't mention it but, DTLSR is described on his page:

http://www.cs.berkeley.edu/~demmer/papers/dtlsr-nsdr07.pdf

- K

On Aug 20, 2007, at 1:45 PM@Aug 20, 2007, Michael Demmer wrote:

> Yes.
>
> The reference implementation ships with working versions of Prophet  
> (intended for mobile environments) and DTLSR (a link state approach  
> intended for more stationary topologies).
>
> -m
>
>
> On Aug 20, 2007, at 1:35 PM, Lloyd Wood wrote:
>
>> At Monday 20/08/2007 15:52 -0400, Symington, Susan F. wrote:
>>
>>> It seems to me that if (security destination != destination), then
>>> eventually we will want to provide a solution for enabling the  
>>> routing
>>> mechanisms to understand that they need to route to the security
>>> destination en route to the ultimate destination.
>>
>>
>> Do we have any working routing mechanisms, other than IP routing?
>>
>> thanks,
>>
>> L.
>>
>> Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
>>
>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Cc: "Symington, Susan F." <[email-masked]>, Wesley Eddy <[email-masked]>, [email-masked]
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] Re: bundle security protocol
Date: Mon, 20 Aug 2007 13:45:59 -0700
To: Lloyd Wood <[email-masked]>
Sender: [email-masked]

Yes.

The reference implementation ships with working versions of Prophet  
(intended for mobile environments) and DTLSR (a link state approach  
intended for more stationary topologies).

-m

On Aug 20, 2007, at 1:35 PM, Lloyd Wood wrote:

> At Monday 20/08/2007 15:52 -0400, Symington, Susan F. wrote:
>
>> It seems to me that if (security destination != destination), then
>> eventually we will want to provide a solution for enabling the  
>> routing
>> mechanisms to understand that they need to route to the security
>> destination en route to the ultimate destination.
>
>
> Do we have any working routing mechanisms, other than IP routing?
>
> thanks,
>
> L.
>
> Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
>
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Mon, 20 Aug 2007 21:35:12 +0100
To: "Symington, Susan F." <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: RE: [dtn-interest] Re: bundle security protocol
Cc: "Wesley Eddy" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At Monday 20/08/2007 15:52 -0400, Symington, Susan F. wrote:

>It seems to me that if (security destination != destination), then
>eventually we will want to provide a solution for enabling the routing
>mechanisms to understand that they need to route to the security
>destination en route to the ultimate destination.

Do we have any working routing mechanisms, other than IP routing?

thanks,

L.

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Re: bundle security protocol
Date: Mon, 20 Aug 2007 15:52:48 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Peter Lovell" <[email-masked]>
Cc: "Wesley Eddy" <[email-masked]>, <[email-masked]>, "hsw" <[email-masked]>
Sender: [email-masked]

Wes,

Thanks for taking the time to read the BSP carefully and provide good
comments. I don't have a whole lot to add to the replies that Peter and
Stephen have already made, but I will add a few items below.

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
>-----Original Message-----
[...]

>>> 6) Ciphersuite ID - why is this 16 bits?  Should it be an SDNV,
even just
>>>   for consistency's sake?  It wasn't clear to me why this was
decided to
>>>   be fixed-length.  It seemed to me like it should really be 2
SDNVs
>>>   instead of a single 16-bit field (one for format flags indicating
>>>   what other fields are present, and one for identifying the
algorithms).
>>>   This would currently yield the same on-wire length since there
are only
>>>   5 flags and a handful of algorithms, so it seems like a clear
improvement
>>>   unless I'm missing some point.
>> 
>> I believe this is just historic. It could be SDNVs without major
impact.

> I'd rather not change, just about. There's no reason I can imagine
> to want that many ciphersuites - each additional one is a potential
> non-interop opportunity, so there's a specific reason in this case to
> not want too much extensibillity. (Some ECC fans once turned up at
> a TLS meeting wanting to define 96 new ciphersuites, each of which
> was some other (non)encumbered variant ECC suite - a bad idea.)

I agree that we don't want to encourage an overabundance of
ciphersuites, but on the other hand I think it's always safest to use
and SDNV as none of us knows for sure what extensions folks might think
up. Being able to add flags other than the ones we've already thought
of is appealing.  

>> 12) The presence of the "At-Most-Once-Delivery" option affects the
>>     registration between an application and a bundle agent, since
that's
>>     where it is specified, but I don't believe it's related to the
BSP.
>>     Is it?

>I'd agree. Its a bit of a hangover from when this was all one
>document that included bits of API. But this is something Susan's
>keen on so I'd like to see what she says.

Agreed. The presence of this option in this spec is historical. The
option used to be in the Bundle Protocol itself back when the BP
included API-related material. Rather than lose the option and concept
entirely, we moved it into this document. I don't really care where the
option/concept is documented, as long as we do it somewhere. 

>> 13) As a larger point to consider, if we can use registration
signalling
>>     to turn on the At-Most-Once-Delivery behavior, should we also
use it
>>     to let applications request CB or PSB services?  I do believe
so.

Seems reasonable to me. 

>>> 15) "Specification of a security-destination other than the bundle
>>>    destination creates a routing requirement that the 
>bundle somehow be
>>>    directed to the security-destination node on its way to the
final
>>>    destination.  This requirement is presently private to 
>the ciphersuite,
>>>    since routing nodes are not required to implement 
>security processing."
>> 
>> heh
>>>    This implication had bothered me from the moment
>> 
>> Me too, which is exactly why I added this statement to the spec last
>> time through. There are huge implications and they seemed to be
>> receiving scant attention so I wanted to be sure that the
implication
>> was at least on record.
>> 
>>>    This implication had bothered me from the moment I 
>thought about the
>>>    format of the abstract security block in 2.1, and is (I 
>think) very
>>>    bad.  If a security-destination is added that differs from the
>>>    original bundle's destination EID, should the original 
>be pushed into
>>>    the security block, and popped later after processing by 
>the security-
>>>    destination?  I'm sure there could be huge problems with 
>this too, but
>>>    it seems to me like presently, without a security-source 
>having some
>>>    routing path knowledge, adding security-destinations 
>that aren't the
>>>    final destination is tricky at best.  You might often be 
>forced to
>>>    use a multicast EID as the security destination if you don't
know
>>>    exactly where a bundle will enter/exit your enclaves, 
>which seems like it
>>>    could be unpallatable for keying (but I guess that would 
>be easier to
>>>    answer after there's a crispy proposal for key management).
>> 
>> I do not have a good answer for this, or even any proper 
>answer at all.
>> The closest I've come is to have a "routing info" block of 
>some sort as
>> a hint for forwarding nodes that they need to direct this 
>bundle to the
>> specified node. Your suggestion to push/pop the destination into
>> security may be better. After all, if the content is 
>encrypted then it
>> needs to get to security-dest. Flawless delivery to the 
>destination but
>> bypassing the decrypt node is kinda useless :)
>
>I think that if you need a security destination != destination then
>you should arrange routing so that that works. VPNs do that kind of
>thing all the time, so I'd be ok with not trying to provide a
>solution for now,
>

It seems to me that if (security destination != destination), then
eventually we will want to provide a solution for enabling the routing
mechanisms to understand that they need to route to the security
destination en route to the ultimate destination. The above two
suggestions ("routing info block" and "push/pop destination into
security header") are worth investigating. I don't think we're ready to
suggest a solution at this point, but it's good to be thinking about
it, especially in the context of the super-encryption issues Peter
discussed in his most-recent email. It is good that the routing
concerns have been made explicit in the BSP.

Also, I agree that one might often want to use a multicast EID as the
security destination. In the case of providing security for a metadata
block, I think the security destination in the metadata block will
often be best expressed as a multicast EID, because several different
nodes along the way may have to decrypt the encrypted metadata in order
to make routing decisions based on it. Also, if there are three
different ways of entering your enclave, then I would think you would
want to express the security destination as the multicast EID that has
exactly those three entrance nodes as members. This would provide the
most routing flexibility rather than trying to pin down a specific
route to the destination. 

-susan

Date: Wed, 15 Aug 2007 08:52:11 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: Peter Lovell <[email-masked]>, [email-masked], Susan <[email-masked]>, hsw <[email-masked]>
Subject: Re: [dtn-interest] Re: bundle security protocol
Reply-To: [email-masked]
Sender: [email-masked]

On Tue, Aug 14, 2007 at 11:22:45PM +0100, Stephen Farrell wrote:
> >
> >>6) Ciphersuite ID - why is this 16 bits?  Should it be an SDNV, even just
> >>  for consistency's sake?  It wasn't clear to me why this was decided to
> >>  be fixed-length.  It seemed to me like it should really be 2 SDNVs
> >>  instead of a single 16-bit field (one for format flags indicating
> >>  what other fields are present, and one for identifying the algorithms).
> >>  This would currently yield the same on-wire length since there are only
> >>  5 flags and a handful of algorithms, so it seems like a clear 
> >>  improvement
> >>  unless I'm missing some point.
> >
> >I believe this is just historic. It could be SDNVs without major impact.
> 
> I'd rather not change, just about. There's no reason I can imagine
> to want that many ciphersuites - each additional one is a potential
> non-interop opportunity, so there's a specific reason in this case to
> not want too much extensibillity. (Some ECC fans once turned up at
> a TLS meeting wanting to define 96 new ciphersuites, each of which
> was some other (non)encumbered variant ECC suite - a bad idea.)

I agree with limiting the ciphersuites.  I wasn't thinking of that as a
real motivation for the change, it was more for both consistency and
direct extensibility to the abstract security block where there
currently is none (at least not directly).  An SDNV for the 5 flags
would add extensibility, which perhaps would never be needed, but who
knows, especially with security protocols ... 

> >I do not have a good answer for this, or even any proper answer at all.
> >The closest I've come is to have a "routing info" block of some sort as
> >a hint for forwarding nodes that they need to direct this bundle to the
> >specified node. Your suggestion to push/pop the destination into
> >security may be better. After all, if the content is encrypted then it
> >needs to get to security-dest. Flawless delivery to the destination but
> >bypassing the decrypt node is kinda useless :)
> 
> I think that if you need a security destination != destination then
> you should arrange routing so that that works. VPNs do that kind of
> thing all the time, so I'd be ok with not trying to provide a
> solution for now,

Well, IPsec VPNs only accomplish this through encapsulation, with the
outer header forcing the "security destination" into the routing path
and the inner header retaining the final destination.  BSP seems to
do more of an insertion than an encapsulation, which is I think where
the issue stems from.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Wesley Eddy" <[email-masked]>, "dtn interest" <[email-masked]>, Susan <[email-masked]>, hsw <[email-masked]>
Subject: Re(2): [dtn-interest] Re: bundle security protocol
Date: Wed, 15 Aug 2007 08:15:55 -0400
Sender: [email-masked]

On Tue, Aug 14, 2007, Stephen Farrell <[email-masked]> wrote:

>> One which cropped up recently is the differentiation between processing
>> for "payload stuff" and processing for "other stuff". Right now
>> ciphersuites are generic and I believe we need to change that. The
>> discussion is too long for here but the current approach needs work.
>
>Authorisation.

Hi Stephen,

without denying the need for authorization, that is not the point behind
my comment.

This is something which came up recently doing things for
confidentiality C3 so I'll describe it in that context.

Confidentiality ciphersuites allow super-encryption. During discussion
in Dublin we agreed that super-encryption of the payload should also
apply to the earlier confidentiality parameters in the more-deeply-
nested CB. That way, payload data and encryption parameters have the
same level of protection.

We also want a confidentiality ciphersuite for metadata. We create
metadata (metadata block) and then protect it using different keys from
the payload.  Let's assume we have confidentiality ciphersuite C5 which
applies just to metadata.

So consider a bundle with a C3 block (payload encryption), a C5 block
with encrypted metadata (encapsulated within the C5 block) and encrypted
payload.

If a node's policy now applies super-encryption, do we encrypt the C5
block? That doesn't make sense, as the user of metadata (think content-
based routing or caching) would require the payload key (at least one)
to look at the metadata. Oops.

So it seems that data protection and metadata protection are different
categories to some extent. But in the plug-in model we have there's no
way to tell them apart. It's tempting to define a query mechanism so
that the ciphersuite doing super-encryption could enquire about the
characteristics of the other suite, but that suite might not be present
on this node.

I think this is specific to confidentiality and doesn't apply to the
others - at least I haven't been able to devise such a scenario. So one
possible solution would be to create a new BlockProcessor for metadata
confidentiality in addition to the existing three for
BundleAuthentication, PayloadSecurity and Confidentiality (for payload). 

Have a good holiday.

Cheers.....Peter

Date: Tue, 14 Aug 2007 23:29:04 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] Re: bundle security protocol
Sender: [email-masked]

The bits Pete didn't cover where I've something to say:

>    I think it would be good to document these quickly in a bulleted list
>    at the end of this draft.  As an RG product, it would clearly identify
>    what further research would be useful and productive.  This could be
>    especially useful since these would probably be the barriers between
>    an Experimental and standards track protocol farther down the line.

Whether, how and with what changes the BP spec might get onto the
standards track involves so many imponderables, that I'm ok that we
ignore the issue for now. Let's do the experiments with the experimental
RFCs and then figure that out, if we're all still interested then.
(And some more commercial interests appear too.)

> 
> 1) I know this is just mincing words, and I don't consider it an
>    important issue, but a point of small reader confusion:
> 
>    The BSP - Bundle Security Protocol - consists of 3 different types of
>    blocks, rules and policies for processing bundles and blocks, and
>    algorithms for use within processing, but there doesn't really seem to
>    be anything tangible that could be named "BSP".  It's more of a
>    "framework" than a "protocol", right?

I'd rather not.

> 3) Early on, I would appreciate more motivating discussion on lower layer
>    and upper layer security mechanisms, and how they can (or can't)
>    supplement/complement/replace each of the BAB, PSB, and CB services.
>    I know this is already aimed at in the "Security Overview and
>    Motivations" document, but I feel it would be helpful to summarize it
>    in 1-2 paragraphs in the introduction here.

Feel free to craft those paragraphs.

> 7) In 2.3 on the PSB - "the security information can be checked at any
>    hop on the way to the destination that has access to the required keying
>    information." Yes, but, SHOULD it?  

I dunno. And am happy leaving that open for experimenters.

Under what circumstances?  What
>    should it do if the check fails?  I know this is discussed further later
>    on within the document (although still a bit mushily), so maybe just
>    adding text like "as discussed later within this document" would be a
>    good idea.

That's fine.

> 12) The presence of the "At-Most-Once-Delivery" option affects the
>     registration between an application and a bundle agent, since that's
>     where it is specified, but I don't believe it's related to the BSP.
>     Is it?

I'd agree. Its a bit of a hangover from when this was all one
document that included bits of API. But this is something Susan's
keen on so I'd like to see what she says.

> If you've survived reading to this point, thanks for your attention!

Thanks right back,
S.

Date: Tue, 14 Aug 2007 23:22:45 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
CC: Wesley Eddy <[email-masked]>, [email-masked], Susan <[email-masked]>, hsw <[email-masked]>
Subject: Re: [dtn-interest] Re: bundle security protocol
Sender: [email-masked]

Just sticking my oar in before I go on hols...

Peter Lovell wrote:
> Hi Wes,
> 
> your comments are very helpful and much appreciated.

Agreed. Good to get more review of this stuff.

> 
> On Mon, Aug 13, 2007, Wesley Eddy <[email-masked]> wrote:
> 
>> Here are some comments on draft-irtf-dtnrg-bundle-security-03, after
>> reading it carefully last week.  I haven't been closely following
>> discussion on this lately, so please forgive me if some of these
>> comments are already known or addressed in a planned update.  Also, I'm
>> sorry for the grossly long email, perhaps some of these should be
>> followed up in distinct threads:
>>
>> 0) Overall, it seems like there are still a couple of interesting open
>>   issues for research.  The current BSP looks like an evolutionary step
>>   forward from "no security" to allowing some classes of deployment of
>>   bundling agents to provide reasonable security services.  But would I be
>>   wrong to say (or would anyone echo the sentiment) that the BSP isn't yet
>>   capable of meeting all the goals of the DTN architecture?
> 
> I agree - we handle some things but not all. And some of the ones we do
> have need revision in light of various changes.

True. Text about that should go in the sec overview though, otherwise
we'll never get this one done. I'd have no problem renaming this I-D
to make it clear that this one is the analog of ESP and not IKE etc.

> 
> 
>>   In addition to key management, what key goals can we identify for
>>   needed advances?  I think comments 14 and 15 below may be a start, but I
>>   believe there may be others.
> 
> One which cropped up recently is the differentiation between processing
> for "payload stuff" and processing for "other stuff". Right now
> ciphersuites are generic and I believe we need to change that. The
> discussion is too long for here but the current approach needs work.

Authorisation.

> 
> 
>> 6) Ciphersuite ID - why is this 16 bits?  Should it be an SDNV, even just
>>   for consistency's sake?  It wasn't clear to me why this was decided to
>>   be fixed-length.  It seemed to me like it should really be 2 SDNVs
>>   instead of a single 16-bit field (one for format flags indicating
>>   what other fields are present, and one for identifying the algorithms).
>>   This would currently yield the same on-wire length since there are only
>>   5 flags and a handful of algorithms, so it seems like a clear improvement
>>   unless I'm missing some point.
> 
> I believe this is just historic. It could be SDNVs without major impact.

I'd rather not change, just about. There's no reason I can imagine
to want that many ciphersuites - each additional one is a potential
non-interop opportunity, so there's a specific reason in this case to
not want too much extensibillity. (Some ECC fans once turned up at
a TLS meeting wanting to define 96 new ciphersuites, each of which
was some other (non)encumbered variant ECC suite - a bad idea.)

> 
>> 10) Canonicalization - This isn't a very crunchy or actionable comment; I'm
>>    sorry.  Canonicalization seems like it could be the major impact on
>>    performance of the BSP, and it's certainly an ugly thing to have to do,
>>    although I understand and accept that it's needed.  Are there
>>    performance profiling numbers available on this?
> 
> Having just worked through the code for PS2, I agree it can be a major
> impact. My head is still hurting from all the gyrations needed. I have
> done no profiling [yet] but I don't expect it to be pretty.
> 
> 
>> 14) Another, un-actionable comment: "This specification does not currently
>>    define any ciphersuite which can handle this reactive fragmentation case
>>    well."  Reactive fragmentation has been a thorn in the side of a few
>>    mechanisms in this RG.  I wonder if it is really a feasible part of
>>    the architecture in general, or if we have to take an IPv6-like path
>>    forwards and only allow proactive fragmentation, or convergence-layer
>>    "suspend/resume" functions for interupted bundle exchanges (rather than
>>    reactive fragmentation).  In anyone else's minds, would this simplify
>>    things significantly or at least alleviate some floundering on the issue
>>    that parts of the instantiated DTN architecture don't and forseably
>>    won't nicely support reactive framentation?
> 
> There are some scenarios where reactive fragmentation can be useful, but
> it's a small subset of the overall dtn capability. For end-to-end
> security, fragmentation is not too much problem since all the pieces
> will [should] arrive and be available for assembly. The big problems
> come at intermediate points where only partial data is available. 
> 
> 
>> 15) "Specification of a security-destination other than the bundle
>>    destination creates a routing requirement that the bundle somehow be
>>    directed to the security-destination node on its way to the final
>>    destination.  This requirement is presently private to the ciphersuite,
>>    since routing nodes are not required to implement security processing."
> 
> heh
>>    This implication had bothered me from the moment
> 
> Me too, which is exactly why I added this statement to the spec last
> time through. There are huge implications and they seemed to be
> receiving scant attention so I wanted to be sure that the implication
> was at least on record.
> 
>>    This implication had bothered me from the moment I thought about the
>>    format of the abstract security block in 2.1, and is (I think) very
>>    bad.  If a security-destination is added that differs from the
>>    original bundle's destination EID, should the original be pushed into
>>    the security block, and popped later after processing by the security-
>>    destination?  I'm sure there could be huge problems with this too, but
>>    it seems to me like presently, without a security-source having some
>>    routing path knowledge, adding security-destinations that aren't the
>>    final destination is tricky at best.  You might often be forced to
>>    use a multicast EID as the security destination if you don't know
>>    exactly where a bundle will enter/exit your enclaves, which seems like it
>>    could be unpallatable for keying (but I guess that would be easier to
>>    answer after there's a crispy proposal for key management).
> 
> I do not have a good answer for this, or even any proper answer at all.
> The closest I've come is to have a "routing info" block of some sort as
> a hint for forwarding nodes that they need to direct this bundle to the
> specified node. Your suggestion to push/pop the destination into
> security may be better. After all, if the content is encrypted then it
> needs to get to security-dest. Flawless delivery to the destination but
> bypassing the decrypt node is kinda useless :)

I think that if you need a security destination != destination then
you should arrange routing so that that works. VPNs do that kind of
thing all the time, so I'd be ok with not trying to provide a
solution for now,

S.

Date: Tue, 14 Aug 2007 23:03:33 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Updating the list of papers...
Sender: [email-masked]

So I've finally put these up, [1] sorry for the delay.

The formatting's not right but I'll fix that later.

Can you check that if you sent me something that
I've properly included it.

No hurry doing that - I'm off on vacation until
the 26th (but anyone else can feel free to fix the
page in the meantime),

Cheers,
S.

[1] http://www.dtnrg.org/wiki/Docs#papers

Stephen Farrell wrote:
> 
> Hi all,
> 
> Someone asked me to post a link to a recent dtn-related paper
> of theirs on the dtnrg.org page for that [1].
> 
> Seems like we've not done that for a while, so I'll collate
> 'em and post a bunch together.
> 
> To make that easy can you send stuff to me (don't cc the list
> please) in the wiki source format, as shown by the examples
> below which are the current 2007 set of papers. I reserve
> the right to ignore stuff in the wrong format:-)
> 
> I'll give it a week or so and then post the lot in one go.
> 
> Cheers,
> S.
> 
> [1] http://www.dtnrg.org/wiki/Docs
> 
> --- example format
> 
>  * T. Spyropoulos, K. Psounis, and C. Raghavendra, 
> �[http://www-sop.inria.fr/planete/spyropoulos/papers/ton-singlecopy.pdf 
> Efficient Routing in Intermittently Connected Mobile Networks: The 
> Single-copy Case]�, to appear in ACM/IEEE journal of Transactions on 
> Networking.
>   * T. Spyropoulos, K. Psounis, and C. Raghavendra, 
> �[http://www-sop.inria.fr/planete/spyropoulos/papers/ton-multicopy-final.pdf 
> Efficient Routing in Intermittently Connected Mobile Networks: The 
> Multi-copy Case]�, to appear in ACM/IEEE journal of Transactions on 
> Networking.
>   * K. Harras, M. Wittie, K. Almeroth and E. Belding. 
> "[http://www.cs.ucsb.edu/~kharras/docs/paranets.pdf ParaNets: A Parallel 
> Network Architecture for Challenged Networks]", IEEE Workshop on Mobile 
> Computing Systems and Applications (HotMobile). Tucson, AZ, February 2007.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

From: "Peter Lovell" <[email-masked]>
To: "Wesley Eddy" <[email-masked]>, <[email-masked]>, "Peter Lovell" <[email-masked]>
Cc: Susan <[email-masked]>, "Stephen Farrell" <[email-masked]>, hsw <[email-masked]>
Date: Tue, 14 Aug 2007 08:02:16 -0400
Subject: [dtn-interest] Re: bundle security protocol
Sender: [email-masked]

Hi Wes,

your comments are very helpful and much appreciated.

I am just about to make extensive updates, since the current development
cycle is turning to test-mode, so the timing is exquisitely good. My
comments are included inline below, with the exception of those relating
to edit changes which I will just "deal with".

Thanks.....Peter

On Mon, Aug 13, 2007, Wesley Eddy <[email-masked]> wrote:

>Here are some comments on draft-irtf-dtnrg-bundle-security-03, after
>reading it carefully last week.  I haven't been closely following
>discussion on this lately, so please forgive me if some of these
>comments are already known or addressed in a planned update.  Also, I'm
>sorry for the grossly long email, perhaps some of these should be
>followed up in distinct threads:
>
>0) Overall, it seems like there are still a couple of interesting open
>   issues for research.  The current BSP looks like an evolutionary step
>   forward from "no security" to allowing some classes of deployment of
>   bundling agents to provide reasonable security services.  But would I be
>   wrong to say (or would anyone echo the sentiment) that the BSP isn't yet
>   capable of meeting all the goals of the DTN architecture?

I agree - we handle some things but not all. And some of the ones we do
have need revision in light of various changes.

>   In addition to key management, what key goals can we identify for
>   needed advances?  I think comments 14 and 15 below may be a start, but I
>   believe there may be others.

One which cropped up recently is the differentiation between processing
for "payload stuff" and processing for "other stuff". Right now
ciphersuites are generic and I believe we need to change that. The
discussion is too long for here but the current approach needs work.

>6) Ciphersuite ID - why is this 16 bits?  Should it be an SDNV, even just
>   for consistency's sake?  It wasn't clear to me why this was decided to
>   be fixed-length.  It seemed to me like it should really be 2 SDNVs
>   instead of a single 16-bit field (one for format flags indicating
>   what other fields are present, and one for identifying the algorithms).
>   This would currently yield the same on-wire length since there are only
>   5 flags and a handful of algorithms, so it seems like a clear improvement
>   unless I'm missing some point.

I believe this is just historic. It could be SDNVs without major impact.

>10) Canonicalization - This isn't a very crunchy or actionable comment; I'm
>    sorry.  Canonicalization seems like it could be the major impact on
>    performance of the BSP, and it's certainly an ugly thing to have to do,
>    although I understand and accept that it's needed.  Are there
>    performance profiling numbers available on this?

Having just worked through the code for PS2, I agree it can be a major
impact. My head is still hurting from all the gyrations needed. I have
done no profiling [yet] but I don't expect it to be pretty.

>14) Another, un-actionable comment: "This specification does not currently
>    define any ciphersuite which can handle this reactive fragmentation case
>    well."  Reactive fragmentation has been a thorn in the side of a few
>    mechanisms in this RG.  I wonder if it is really a feasible part of
>    the architecture in general, or if we have to take an IPv6-like path
>    forwards and only allow proactive fragmentation, or convergence-layer
>    "suspend/resume" functions for interupted bundle exchanges (rather than
>    reactive fragmentation).  In anyone else's minds, would this simplify
>    things significantly or at least alleviate some floundering on the issue
>    that parts of the instantiated DTN architecture don't and forseably
>    won't nicely support reactive framentation?

There are some scenarios where reactive fragmentation can be useful, but
it's a small subset of the overall dtn capability. For end-to-end
security, fragmentation is not too much problem since all the pieces
will [should] arrive and be available for assembly. The big problems
come at intermediate points where only partial data is available. 

>15) "Specification of a security-destination other than the bundle
>    destination creates a routing requirement that the bundle somehow be
>    directed to the security-destination node on its way to the final
>    destination.  This requirement is presently private to the ciphersuite,
>    since routing nodes are not required to implement security processing."

heh
>    This implication had bothered me from the moment

Me too, which is exactly why I added this statement to the spec last
time through. There are huge implications and they seemed to be
receiving scant attention so I wanted to be sure that the implication
was at least on record.

>    This implication had bothered me from the moment I thought about the
>    format of the abstract security block in 2.1, and is (I think) very
>    bad.  If a security-destination is added that differs from the
>    original bundle's destination EID, should the original be pushed into
>    the security block, and popped later after processing by the security-
>    destination?  I'm sure there could be huge problems with this too, but
>    it seems to me like presently, without a security-source having some
>    routing path knowledge, adding security-destinations that aren't the
>    final destination is tricky at best.  You might often be forced to
>    use a multicast EID as the security destination if you don't know
>    exactly where a bundle will enter/exit your enclaves, which seems like it
>    could be unpallatable for keying (but I guess that would be easier to
>    answer after there's a crispy proposal for key management).

I do not have a good answer for this, or even any proper answer at all.
The closest I've come is to have a "routing info" block of some sort as
a hint for forwarding nodes that they need to direct this bundle to the
specified node. Your suggestion to push/pop the destination into
security may be better. After all, if the content is encrypted then it
needs to get to security-dest. Flawless delivery to the destination but
bypassing the decrypt node is kinda useless :)

Date: Mon, 13 Aug 2007 11:47:04 -0400
From: Wesley Eddy <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] bundle security protocol
Sender: [email-masked]

Here are some comments on draft-irtf-dtnrg-bundle-security-03, after
reading it carefully last week.  I haven't been closely following
discussion on this lately, so please forgive me if some of these
comments are already known or addressed in a planned update.  Also, I'm
sorry for the grossly long email, perhaps some of these should be
followed up in distinct threads:

0) Overall, it seems like there are still a couple of interesting open
   issues for research.  The current BSP looks like an evolutionary step
   forward from "no security" to allowing some classes of deployment of
   bundling agents to provide reasonable security services.  But would I be
   wrong to say (or would anyone echo the sentiment) that the BSP isn't yet
   capable of meeting all the goals of the DTN architecture?

   In addition to key management, what key goals can we identify for
   needed advances?  I think comments 14 and 15 below may be a start, but I
   believe there may be others.

   I think it would be good to document these quickly in a bulleted list
   at the end of this draft.  As an RG product, it would clearly identify
   what further research would be useful and productive.  This could be
   especially useful since these would probably be the barriers between
   an Experimental and standards track protocol farther down the line.

1) I know this is just mincing words, and I don't consider it an
   important issue, but a point of small reader confusion:

   The BSP - Bundle Security Protocol - consists of 3 different types of
   blocks, rules and policies for processing bundles and blocks, and
   algorithms for use within processing, but there doesn't really seem to
   be anything tangible that could be named "BSP".  It's more of a
   "framework" than a "protocol", right?

   I also realize that their are common elements like the abstract security
   block format and canonicalization rules, but these still strike me
   more as framework than protocol.

2) Figure 1 - "Net1", "Trans1", "Net3", and "Trans3" become "N1", "T1",
   "N3", and "T3", in the 2nd and 3rd nodes.  These should be consistently
   labelled.

3) Early on, I would appreciate more motivating discussion on lower layer
   and upper layer security mechanisms, and how they can (or can't)
   supplement/complement/replace each of the BAB, PSB, and CB services.
   I know this is already aimed at in the "Security Overview and
   Motivations" document, but I feel it would be helpful to summarize it
   in 1-2 paragraphs in the introduction here.

4) Labelling/naming of fields between the text of 2.1 and Figure 2 is not
   consistent.

5) In Section 2.1: "indicated by by" -> "indicated by"

6) Ciphersuite ID - why is this 16 bits?  Should it be an SDNV, even just
   for consistency's sake?  It wasn't clear to me why this was decided to
   be fixed-length.  It seemed to me like it should really be 2 SDNVs
   instead of a single 16-bit field (one for format flags indicating
   what other fields are present, and one for identifying the algorithms).
   This would currently yield the same on-wire length since there are only
   5 flags and a handful of algorithms, so it seems like a clear improvement
   unless I'm missing some point.

7) In 2.3 on the PSB - "the security information can be checked at any
   hop on the way to the destination that has access to the required keying
   information." Yes, but, SHOULD it?  Under what circumstances?  What
   should it do if the check fails?  I know this is discussed further later
   on within the document (although still a bit mushily), so maybe just
   adding text like "as discussed later within this document" would be a
   good idea.

8) Section 3.1 - In the paragraph "All nodes serve as ...", there is an
   either confusing or outright wrong mashup of terminology that muddles
   whether policies apply to the interaction with apps that request
   bundling services through a registration to a bundle agent, or to the
   interaction between bundle agents via bundle forwarding, or both.
   Rewriting this to clarify the intent is needed.  Perhaps splitting it
   into two paragraphs to address the two different policy sets would be
   advisable.

9) Section 6 - "PEP" is redundantly redefined (first instance was in 3.1).
   
10) Canonicalization - This isn't a very crunchy or actionable comment; I'm
    sorry.  Canonicalization seems like it could be the major impact on
    performance of the BSP, and it's certainly an ugly thing to have to do,
    although I understand and accept that it's needed.  Are there
    performance profiling numbers available on this?

11) "node SHALL discard" is better to my ear as an implementer if phrased
    as "node MUST discard", and equivalent by BCP 14, but this is just a
    small and unimportant suggestion.

12) The presence of the "At-Most-Once-Delivery" option affects the
    registration between an application and a bundle agent, since that's
    where it is specified, but I don't believe it's related to the BSP.
    Is it?

13) As a larger point to consider, if we can use registration signalling
    to turn on the At-Most-Once-Delivery behavior, should we also use it
    to let applications request CB or PSB services?  I do believe so.

14) Another, un-actionable comment: "This specification does not currently
    define any ciphersuite which can handle this reactive fragmentation case
    well."  Reactive fragmentation has been a thorn in the side of a few
    mechanisms in this RG.  I wonder if it is really a feasible part of
    the architecture in general, or if we have to take an IPv6-like path
    forwards and only allow proactive fragmentation, or convergence-layer
    "suspend/resume" functions for interupted bundle exchanges (rather than
    reactive fragmentation).  In anyone else's minds, would this simplify
    things significantly or at least alleviate some floundering on the issue
    that parts of the instantiated DTN architecture don't and forseably
    won't nicely support reactive framentation?

15) "Specification of a security-destination other than the bundle
    destination creates a routing requirement that the bundle somehow be
    directed to the security-destination node on its way to the final
    destination.  This requirement is presently private to the ciphersuite,
    since routing nodes are not required to implement security processing."

    This implication had bothered me from the moment I thought about the
    format of the abstract security block in 2.1, and is (I think) very
    bad.  If a security-destination is added that differs from the
    original bundle's destination EID, should the original be pushed into
    the security block, and popped later after processing by the security-
    destination?  I'm sure there could be huge problems with this too, but
    it seems to me like presently, without a security-source having some
    routing path knowledge, adding security-destinations that aren't the
    final destination is tricky at best.  You might often be forced to
    use a multicast EID as the security destination if you don't know
    exactly where a bundle will enter/exit your enclaves, which seems like it
    could be unpallatable for keying (but I guess that would be easier to
    answer after there's a crispy proposal for key management).

If you've survived reading to this point, thanks for your attention!

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Thu, 09 Aug 2007 13:59:17 +0100
To: "dtn interest" <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re(6): [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Sender: [email-masked]

At Thursday 09/08/2007 08:32 -0400, Peter Lovell wrote:
>Hi Wes,
>
>the recent paper is 
>"Attacking the IPsec Standards in Encryption-only Configurations"
><http://eprint.iacr.org/2007/125.pdf>
>
>and earlier work by Bellovin is 
>"Problem Areas for the IP Security Protocols"
><ftp://ftp.research.att.com/dist/smb/badesp.ps>

These papers make remarks that are very relevant to the work of this group:

Bellovin:
"People assume that since decrypting with the wrong key will yield garbage, additional integrity checking is not needed. Regrettably, this is not the case."
[..]
"Against many of these attacks, the proper defense is use of integrity checking."

Degabriele and Paterson:
"The need to use integrity protection along with encryption in order to prevent active attacks is
well-understood in the theoretical cryptography community. Moreover, there are plenty of highprofile
examples where lack of strong integrity checks (or their inappropriate application) has
allowed attacks to succeed"

... so lack of integrity checking has consequences for security as well as for reliability.

L.

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 

From: "Peter Lovell" <[email-masked]>
To: "Wesley Eddy" <[email-masked]>
Cc: "Peter Lovell" <[email-masked]>, "Lloyd Wood" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "Darren Long" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(6): [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Date: Thu, 9 Aug 2007 08:32:00 -0400
Sender: [email-masked]

On Wed, Aug 8, 2007, Peter Lovell <[email-masked]> wrote:

>On Wed, Aug 8, 2007, Wesley Eddy <[email-masked]> wrote:
>
>>On Thu, Jul 26, 2007 at 08:28:46AM -0400, Peter Lovell wrote:
>>> >
>>> >Is this a real concern? (As in, are there known attacks on IPsec and
>>> >tunnelled IP headers using the position of the header's one's-complement
>>> >checksum? And are the one's-complement checksum's weaknesses - not
>>> >detecting reordering - suddenly a strength in making attacks harder?)
>>> 
>>> There are known exploits against IPSec using position of certain fields
>>> in the header. At present I don't recall it it's the checksum or not.
>>
>>
>>Can you share pointers to those?  They might be instructive references
>>to have in explaining the checksum <-> privacy interaction.
>>
>
>Hi Wes,
>
>I have it but not at my fingertips. I'll try to get it for the morning.
>
>Cheers.....Peter
>

Hi Wes,

the recent paper is 
"Attacking the IPsec Standards in Encryption-only Configurations"
<http://eprint.iacr.org/2007/125.pdf>

and earlier work by Bellovin is 
"Problem Areas for the IP Security Protocols"
<ftp://ftp.research.att.com/dist/smb/badesp.ps>

Cheers.....Peter

Date: Wed, 8 Aug 2007 15:54:39 -0400
From: Wesley Eddy <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: Lloyd Wood <[email-masked]>, Stephen Farrell <[email-masked]>, Darren Long <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: Re(3): [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Jul 26, 2007 at 08:28:46AM -0400, Peter Lovell wrote:
> >
> >Is this a real concern? (As in, are there known attacks on IPsec and
> >tunnelled IP headers using the position of the header's one's-complement
> >checksum? And are the one's-complement checksum's weaknesses - not
> >detecting reordering - suddenly a strength in making attacks harder?)
> 
> There are known exploits against IPSec using position of certain fields
> in the header. At present I don't recall it it's the checksum or not.

Can you share pointers to those?  They might be instructive references
to have in explaining the checksum <-> privacy interaction.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Cc: "Symington, Susan F." <[email-masked]>, dtn interest <[email-masked]>
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] I-D submission
Date: Mon, 6 Aug 2007 11:23:03 -0700
To: Stephen Farrell <[email-masked]>
Sender: [email-masked]

> Michael Demmer wrote:
>> I also think that having an explicit specification for end to end  
>> metadata is more convenient both for implementation and for use by  
>> applications.
>> The system can open an interface to applications allowing them to  
>> specify an arbitrary ontology and contents for the metadata block  
>> and know how to process it. As Susan said, this is especially  
>> convenient for security blocks, methinks.
>> For apps, they can specify an arbitrary ontology with no risk of  
>> conflicting with any other block type, current or future, nor any  
>> need to register the ontology in any sort of database. It's purely  
>> app-specific.
>
> That I don't get. Why is a number inside a block less prone to
> collisions than one that identifies a block?

My point is that I see the number inside the block as application- 
specific, so all apps can use it with the expectation that the bundle  
agents in the core of the network won't be paying attention to the  
number, so it's free to use whatever it wants, even if they conflict  
with well-known block numbers, or block numbers that have yet to be  
defined.

In contrast, the block number space is up for future extension by  
people working on additions to the core bundle protocol. So an app  
may be written and deployed to use some number to identify its  
metadata which then gets overloaded by some other block number, and a  
bundle agent somewhere misinterprets the block.

-mike

Date: Mon, 06 Aug 2007 19:19:05 +0100
From: Stephen Farrell <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: "Symington, Susan F." <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: [dtn-interest] I-D submission
Sender: [email-masked]

Michael Demmer wrote:
> I also think that having an explicit specification for end to end 
> metadata is more convenient both for implementation and for use by 
> applications.
> 
> The system can open an interface to applications allowing them to 
> specify an arbitrary ontology and contents for the metadata block and 
> know how to process it. As Susan said, this is especially convenient for 
> security blocks, methinks.
> 
> For apps, they can specify an arbitrary ontology with no risk of 
> conflicting with any other block type, current or future, nor any need 
> to register the ontology in any sort of database. It's purely app-specific.

That I don't get. Why is a number inside a block less prone to
collisions than one that identifies a block?

S.

> 
> -m
> 
> On Aug 6, 2007, at 7:14 AM, Symington, Susan F. wrote:
> 
>> Well, I'm not sure that it is necessarily better to do this rather than
>> have each metadata ontology defined as its own block type. It could be
>> done either way, and I suppose there are pros and cons of each that we
>> should explore.
>>
>> One benefit that I see from doing it this way is that it provides a
>> single way of reasoning about any metadata block. For example, in
>> defining a ciphersuite to protect the metadata block separately from
>> the payload you just have to define a single ciphersuite and say it
>> applies to the metadata block, no matter what the ontology is, rather
>> than define a separate ciphersuite for each individual
>> ontology-specific block.
>>
>> But I see your point that there is not very much to this block, and
>> essentially the block type plus ontology type combine to be equivalent
>> to a new block type. If we decide that it would be better to define
>> each metadata ontology as its own block type then that's fine with me.
>>
>> -susan
>>
>> *****************************************************************
>> Susan Symington
>> The MITRE Corporation
>> [email-masked]
>> 703-983-7209 (voice)
>> 703-983-7142 (fax)
>> ******************************************************************
>>
>>
>>> -----Original Message-----
>>> From: Stephen Farrell [mailto:[email-masked]]
>>> Sent: Saturday, August 04, 2007 10:24 AM
>>> To: Symington, Susan F.
>>> Cc: dtn interest
>>> Subject: Re: [dtn-interest] I-D submission
>>>
>>>
>>>
>>> Symington, Susan F. wrote:
>>>> Attached is an I-D submission titled "Delay-Tolerant
>>> Networking Metadata
>>>> Extension Block",
>> draft-symington-dtnrg-bundle-metadata-block-00.txt.
>>>
>>> Hi Susan,
>>>
>>> I don't get why its better to do this rather than have each
>>> metadata "ontology" defined as its own block type?
>>>
>>> S.
>>>
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Cc: Stephen Farrell <[email-masked]>, dtn interest <[email-masked]>
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] I-D submission
Date: Mon, 6 Aug 2007 10:02:04 -0700
To: "Symington, Susan F." <[email-masked]>
Sender: [email-masked]

I also think that having an explicit specification for end to end  
metadata is more convenient both for implementation and for use by  
applications.

The system can open an interface to applications allowing them to  
specify an arbitrary ontology and contents for the metadata block and  
know how to process it. As Susan said, this is especially convenient  
for security blocks, methinks.

For apps, they can specify an arbitrary ontology with no risk of  
conflicting with any other block type, current or future, nor any  
need to register the ontology in any sort of database. It's purely  
app-specific.

-m

On Aug 6, 2007, at 7:14 AM, Symington, Susan F. wrote:

> Well, I'm not sure that it is necessarily better to do this rather  
> than
> have each metadata ontology defined as its own block type. It could be
> done either way, and I suppose there are pros and cons of each that we
> should explore.
>
> One benefit that I see from doing it this way is that it provides a
> single way of reasoning about any metadata block. For example, in
> defining a ciphersuite to protect the metadata block separately from
> the payload you just have to define a single ciphersuite and say it
> applies to the metadata block, no matter what the ontology is, rather
> than define a separate ciphersuite for each individual
> ontology-specific block.
>
> But I see your point that there is not very much to this block, and
> essentially the block type plus ontology type combine to be equivalent
> to a new block type. If we decide that it would be better to define
> each metadata ontology as its own block type then that's fine with me.
>
> -susan
>
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
>
>
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]]
>> Sent: Saturday, August 04, 2007 10:24 AM
>> To: Symington, Susan F.
>> Cc: dtn interest
>> Subject: Re: [dtn-interest] I-D submission
>>
>>
>>
>> Symington, Susan F. wrote:
>>> Attached is an I-D submission titled "Delay-Tolerant
>> Networking Metadata
>>> Extension Block",
> draft-symington-dtnrg-bundle-metadata-block-00.txt.
>>
>> Hi Susan,
>>
>> I don't get why its better to do this rather than have each
>> metadata "ontology" defined as its own block type?
>>
>> S.
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] I-D submission
Date: Mon, 6 Aug 2007 10:14:17 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "dtn interest" <[email-masked]>
Sender: [email-masked]

Well, I'm not sure that it is necessarily better to do this rather than
have each metadata ontology defined as its own block type. It could be
done either way, and I suppose there are pros and cons of each that we
should explore.

One benefit that I see from doing it this way is that it provides a
single way of reasoning about any metadata block. For example, in
defining a ciphersuite to protect the metadata block separately from
the payload you just have to define a single ciphersuite and say it
applies to the metadata block, no matter what the ontology is, rather
than define a separate ciphersuite for each individual
ontology-specific block. 

But I see your point that there is not very much to this block, and
essentially the block type plus ontology type combine to be equivalent
to a new block type. If we decide that it would be better to define
each metadata ontology as its own block type then that's fine with me. 

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Saturday, August 04, 2007 10:24 AM
>To: Symington, Susan F.
>Cc: dtn interest
>Subject: Re: [dtn-interest] I-D submission
>
>
>
>Symington, Susan F. wrote:
>> Attached is an I-D submission titled "Delay-Tolerant 
>Networking Metadata 
>> Extension Block",
draft-symington-dtnrg-bundle-metadata-block-00.txt.
>
>Hi Susan,
>
>I don't get why its better to do this rather than have each
>metadata "ontology" defined as its own block type?
>
>S.
>
>

Date: Sat, 04 Aug 2007 15:24:17 +0100
From: Stephen Farrell <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
CC: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] I-D submission
Sender: [email-masked]

Symington, Susan F. wrote:
> Attached is an I-D submission titled "Delay-Tolerant Networking Metadata 
> Extension Block", draft-symington-dtnrg-bundle-metadata-block-00.txt.

Hi Susan,

I don't get why its better to do this rather than have each
metadata "ontology" defined as its own block type?

S.

Content-class: urn:content-classes:message
Date: Fri, 3 Aug 2007 14:50:25 -0400
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Cc: "dtn interest" <[email-masked]>
Subject: [dtn-interest] I-D submission
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7D5FF.25DEFC26
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C7D5FF.25DEFC26"

------_=_NextPart_002_01C7D5FF.25DEFC26
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached is an I-D submission titled "Delay-Tolerant Networking
Metadata Extension Block",
draft-symington-dtnrg-bundle-metadata-block-00.txt.
=20
-susan
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

------_=_NextPart_002_01C7D5FF.25DEFC26
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16481" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D224554518-03082007>Attached is an I-D=20
submission titled "<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Delay-Tolerant=20
Networking Metadata Extension Block"</SPAN>,=20
draft-symington-dtnrg-bundle-metadata-block-00.txt.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D224554518-03082007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D224554518-03082007>-susan</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C7D5FF.25DEFC26--

------_=_NextPart_001_01C7D5FF.25DEFC26
Content-Type: text/plain;
	name="draft-symington-dtnrg-bundle-metadata-block-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-symington-dtnrg-bundle-metadata-block-00.txt
Content-Disposition: attachment;
	filename="draft-symington-dtnrg-bundle-metadata-block-00.txt"

------_=_NextPart_001_01C7D5FF.25DEFC26--

Date: Thu, 02 Aug 2007 19:45:53 +0100
From: Stephen Farrell <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dtn-interest] review of draft-irtf-dtnrg-ltp-motivation-04.txt
Sender: [email-masked]

Henderson, Thomas R wrote:
>  
> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]] 
>> Sent: Thursday, August 02, 2007 9:30 AM
>> To: Henderson, Thomas R
>> Cc: Scott Burleigh; [email-masked]; [email-masked]
>> Subject: Re: [dtn-interest] review of 
>> draft-irtf-dtnrg-ltp-motivation-04.txt
> 
>> Thomas,
>>
>> If you could also indicate which of the issues you raise above
>> you consider "blocking" (in the sense of this not being ready
>> to be an informational RFC), that'd be useful. It wasn't clear
>> to me for all the points you made,
>>
>> Thanks,
>> Stephen.
> 
> Stephen,
> Many of my comments were in response to document length/organization,
> and I think it is up to the authors to decide how far (if at all) they'd
> like to respond to those comments; i.e., I don't consider them blockers,
> just editorial suggestions.  
> 
> We are not at the IRSG poll stage yet, but if we were to go to IRSG poll
> with the existing document, I would probably lean towards saying "not
> ready to publish" until the below comments were addressed:
> 
> "Areas that are not sufficiently covered are descriptions of interfaces
> to different protocol layers (for instance, how an upper layer signals
> the parts of a block that are to be reliably transferred) and also side
> information that is required (Section 5.2).  Also, it was not clear how
> message integrity is provided (either within LTP or provided by another
> layer).  Finally, my read of the security considerations section was
> that it described the risks and options for avoiding these risks, but
> was very noncommittal about which measures LTP has actually adopted."

Thanks Tom,

That's helpful,
S.

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] review of draft-irtf-dtnrg-ltp-motivation-04.txt
Date: Thu, 2 Aug 2007 10:38:18 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Scott Burleigh" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]] 
> Sent: Thursday, August 02, 2007 9:30 AM
> To: Henderson, Thomas R
> Cc: Scott Burleigh; [email-masked]; [email-masked]
> Subject: Re: [dtn-interest] review of 
> draft-irtf-dtnrg-ltp-motivation-04.txt

> Thomas,
> 
> If you could also indicate which of the issues you raise above
> you consider "blocking" (in the sense of this not being ready
> to be an informational RFC), that'd be useful. It wasn't clear
> to me for all the points you made,
> 
> Thanks,
> Stephen.

Stephen,
Many of my comments were in response to document length/organization,
and I think it is up to the authors to decide how far (if at all) they'd
like to respond to those comments; i.e., I don't consider them blockers,
just editorial suggestions.  

We are not at the IRSG poll stage yet, but if we were to go to IRSG poll
with the existing document, I would probably lean towards saying "not
ready to publish" until the below comments were addressed:

"Areas that are not sufficiently covered are descriptions of interfaces
to different protocol layers (for instance, how an upper layer signals
the parts of a block that are to be reliably transferred) and also side
information that is required (Section 5.2).  Also, it was not clear how
message integrity is provided (either within LTP or provided by another
layer).  Finally, my read of the security considerations section was
that it described the risks and options for avoiding these risks, but
was very noncommittal about which measures LTP has actually adopted."

Regards,
Tom

Date: Thu, 02 Aug 2007 17:29:47 +0100
From: Stephen Farrell <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dtn-interest] review of draft-irtf-dtnrg-ltp-motivation-04.txt
Sender: [email-masked]

Scott Burleigh wrote:
> Henderson, Thomas R wrote:
>> Hi,
>> I've reviewed the Licklider Transmission Protocol - Motivation I-D.
>> This document provides the motivation, requirements, and operational
>> overview of LTP, which is an ARQ protocol tailored for deep space links.
>>
>> The document provides a wealth of information, but IMHO could be written
>> much more tightly.  It would probably benefit from an editing exercise
>> where the goal was to cut the number of pages by half, for instance.
>> Some areas where it could be trimmed are the detailed comparison to TCP
>> (it should be fairly quick to establish that TCP or SCTP can not be used
>> to meet these requirements) and detailed descriptions of things like
>> planetary occultations and propagation.
>>
>> Presently, the requirements for LTP are initially described in section 2
>> but are also found scattered throughout the protocol description
>> sections when trying to justify the design choices.  Sections 3 and 4
>> constitute a protocol overview, but split into two sections called
>> Features and Overall Operation.  I would recommend consolidating all of
>> the requirements into an initial section, then follow with a "Protocol
>> Overview" section.  RFC 4101 may be of guidance of how to structure the
>> protocol overview.
>> Areas that are not sufficiently covered are descriptions of interfaces
>> to different protocol layers (for instance, how an upper layer signals
>> the parts of a block that are to be reliably transferred) and also side
>> information that is required (Section 5.2).  Also, it was not clear how
>> message integrity is provided (either within LTP or provided by another
>> layer).  Finally, my read of the security considerations section was
>> that it described the risks and options for avoiding these risks, but
>> was very noncommittal about which measures LTP has actually adopted.
>>
>> I will send some private nits to the authors.
>>   
> Thanks for this review, Tom.  We'll need to wait until any other planned 
> reviews are in, but then we'll take a shot at editing as you suggest.
> 
> The intent of the detailed comparison to TCP is not so much to explain 
> why TCP won't meet the requirements as to illuminate the design 
> decisions underlying LTP, but as you say this may well be overkill.  
> It's gratifying to hear a reader asking for less explanation of these 
> topics, for once,  rather than more.

Thomas,

If you could also indicate which of the issues you raise above
you consider "blocking" (in the sense of this not being ready
to be an informational RFC), that'd be useful. It wasn't clear
to me for all the points you made,

Thanks,
Stephen.

Date: Thu, 02 Aug 2007 08:34:29 -0700
From: Scott Burleigh <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [dtn-interest] review of draft-irtf-dtnrg-ltp-motivation-04.txt
Sender: [email-masked]

Henderson, Thomas R wrote:
> Hi,
> I've reviewed the Licklider Transmission Protocol - Motivation I-D.
> This document provides the motivation, requirements, and operational
> overview of LTP, which is an ARQ protocol tailored for deep space links.
>
> The document provides a wealth of information, but IMHO could be written
> much more tightly.  It would probably benefit from an editing exercise
> where the goal was to cut the number of pages by half, for instance.
> Some areas where it could be trimmed are the detailed comparison to TCP
> (it should be fairly quick to establish that TCP or SCTP can not be used
> to meet these requirements) and detailed descriptions of things like
> planetary occultations and propagation.
>
> Presently, the requirements for LTP are initially described in section 2
> but are also found scattered throughout the protocol description
> sections when trying to justify the design choices.  Sections 3 and 4
> constitute a protocol overview, but split into two sections called
> Features and Overall Operation.  I would recommend consolidating all of
> the requirements into an initial section, then follow with a "Protocol
> Overview" section.  RFC 4101 may be of guidance of how to structure the
> protocol overview. 
>
> Areas that are not sufficiently covered are descriptions of interfaces
> to different protocol layers (for instance, how an upper layer signals
> the parts of a block that are to be reliably transferred) and also side
> information that is required (Section 5.2).  Also, it was not clear how
> message integrity is provided (either within LTP or provided by another
> layer).  Finally, my read of the security considerations section was
> that it described the risks and options for avoiding these risks, but
> was very noncommittal about which measures LTP has actually adopted.
>
> I will send some private nits to the authors.
>   
Thanks for this review, Tom.  We'll need to wait until any other planned 
reviews are in, but then we'll take a shot at editing as you suggest.

The intent of the detailed comparison to TCP is not so much to explain 
why TCP won't meet the requirements as to illuminate the design 
decisions underlying LTP, but as you say this may well be overkill.  
It's gratifying to hear a reader asking for less explanation of these 
topics, for once,  rather than more.

Scott

Content-class: urn:content-classes:message
Date: Wed, 1 Aug 2007 10:27:18 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [dtn-interest] review of draft-irtf-dtnrg-ltp-motivation-04.txt
Sender: [email-masked]

Hi,
I've reviewed the Licklider Transmission Protocol - Motivation I-D.
This document provides the motivation, requirements, and operational
overview of LTP, which is an ARQ protocol tailored for deep space links.

The document provides a wealth of information, but IMHO could be written
much more tightly.  It would probably benefit from an editing exercise
where the goal was to cut the number of pages by half, for instance.
Some areas where it could be trimmed are the detailed comparison to TCP
(it should be fairly quick to establish that TCP or SCTP can not be used
to meet these requirements) and detailed descriptions of things like
planetary occultations and propagation.

Presently, the requirements for LTP are initially described in section 2
but are also found scattered throughout the protocol description
sections when trying to justify the design choices.  Sections 3 and 4
constitute a protocol overview, but split into two sections called
Features and Overall Operation.  I would recommend consolidating all of
the requirements into an initial section, then follow with a "Protocol
Overview" section.  RFC 4101 may be of guidance of how to structure the
protocol overview. 

Areas that are not sufficiently covered are descriptions of interfaces
to different protocol layers (for instance, how an upper layer signals
the parts of a block that are to be reliably transferred) and also side
information that is required (Section 5.2).  Also, it was not clear how
message integrity is provided (either within LTP or provided by another
layer).  Finally, my read of the security considerations section was
that it described the risks and options for avoiding these risks, but
was very noncommittal about which measures LTP has actually adopted.

I will send some private nits to the authors.

Tom