Subject: [dtn-interest] FW: New Version Notification for draft-irtf-dtnrg-bundle-metadata-block-02
From: "Symington, Susan F." <[email-masked]>
To: dtn interest <[email-masked]>
Date: Tue, 31 Mar 2009 16:48:25 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

All,

I just posted a revision to the DTN Metadata Block I-D.  I tried to respond to the many good comments and suggestions that I got from Joerg, Stephen, and Kevin. Both the discussion that we had recently at Mountain View and recent email exchanges in response to postings from Armando and Nacho also helped.

As you will see, I am trying to strike a compromise between Kevin's desire to use URIs as THE metadata type and competing desires for a more efficient alternative. I defined a URI metadata type in this I-D and if someone wants, they can just use that. But if someone wants to define their own metadata type, that's okay too.

I also added some text about what the appropriate (and inappropriate) uses of the block might be, since folks seemed to want this. Thank you, Nacho, for your good examples.

Please let me know what you think. Thanks!

http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-metadata-block-02.txt

-susan

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

>-----Original Message-----
>From: IETF I-D Submission Tool [mailto:[email-masked]]
>Sent: Tuesday, March 31, 2009 4:38 PM
>To: Symington, Susan F.
>Subject: New Version Notification for draft-irtf-dtnrg-bundle-metadata-
>block-02
>
>
>A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-02.txt has
>been successfuly submitted by Susan Symington and posted to the IETF
>repository.
>
>Filename:	 draft-irtf-dtnrg-bundle-metadata-block
>Revision:	 02
>Title:		 Delay-Tolerant Networking Metadata Extension Block
>Creation_date:	 2009-03-31
>WG ID:		 Independent Submission
>Number_of_pages: 12
>
>Abstract:
>This document defines an extension block that may be used with the
>Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>Network architecture [refs.DTNarch].  This Metadata Extension Block
>is designed to be used to carry application-level information that
>DTN nodes can use to make DTN-level processing decisions regarding
>bundles, such as deciding whether to store a bundle or determining to
>which nodes to forward a bundle.  The actual metadata that is carried
>in a metadata block must be formatted according to the metadata type
>that is identified in the block's metadata type field.  One specific
>metadata type, for encoding metadata as URIs, is defined in this
>document.  Other metadata types may be defined in separate documents.
>
>
>
>The IETF Secretariat.
>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Symington, Susan F." <[email-masked]>, Ignacio Solis <[email-masked]>,  dtn interest <[email-masked]>
Date: Tue, 31 Mar 2009 06:55:25 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] metadata block - 01

> It is true that the SSR needs to receive a key for decrypting 
> the meta-data. This strikes me as similar to the fact that 
> each DTN node that is supporting the BAB needs to receive a 
> key for calculating and verifying the security result in the 
> BAB. We have not yet defined DTN key management so we haven't 
> yet discussed how the component within the DTN node that is 
> supporting the BAB will get this key. The same is true for 
> the DTN nodes that are supporting the PCB and the PIB; they 
> will need keys and we haven't yet discussed how we'll get the 
> keys to them (other than pre-stored).

I suspect that initial key distribution will be via the network management systems (network configuration).  Hence the need for very good security on that system.  

Pre-storing of a few keys will be necessary (boot strap problem).  However, I don't believe that is a workable solution for the DTN  Secure Searching and Routing (SSR).  One would have to be quite clairvoyant.

From: Peter Lovell <[email-masked]>
To: Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Mon, 30 Mar 2009 23:05:03 -0400
Subject: [dtn-interest] Re(2):  metadata block - 01

On Mon, Mar 30, 2009, Ignacio Solis <[email-masked]> wrote:

>You'd
>assume
>that
>by
>now
>all
>mailers
>would
>have
>figured
>out
>how
>to
>do
>quoted
>text-rewrapping

Problem? What Problem?

Date: Mon, 30 Mar 2009 15:37:01 PDT
From: Ignacio Solis <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

(You'd assume that by now all mailers would have figured out how to do quoted 
text-rewrapping)

Symington, Susan F. wrote:
> Yes, it is true that you can provide security as part of the application
layer instead of using the security services that are part of DTN. The
application can encrypt the application data and sign it and send these as the
bundle's payload. This is what you would have to do to have end-to-end
confidentiality and end-to-end integrity in an application overlay system such
as the one that you are describing, assuming the bundle needs to travel more
than a single DTN hop to get from its source to its destination.
> 
> Your original question was why use the router API rather than the
application API and my answer is that one reason to use the router API is that
this enables you to take advantage of DTN security. If you don't want
end-to-end security or you are willing to code end-to-end security into each
one of your applications instead of using DTN security, then this reason for
preferring the router API rather than the application API is not important to you.
> 
> In response to the many questions "Yes?," "Is this correct?," etc. that you
> 
pose throughout your narrative, my answers are yes. If I understand you
correctly, I pretty much agree with what you are saying. And yes, I envision
users as being allowed to make up their own metadata types (and registering
their IDs to ensure global uniqueness). And yes, there could be several
external routers, each supporting a different metadata type. I would add the
following elaboration:
> 
> It is true that the SSR needs to receive a key for decrypting the
> meta-data.
This strikes me as similar to the fact that each DTN node that is supporting
the BAB needs to receive a key for calculating and verifying the security
result in the BAB. We have not yet defined DTN key management so we haven't
yet discussed how the component within the DTN node that is supporting the BAB
will get this key. The same is true for the DTN nodes that are supporting the
PCB and the PIB; they will need keys and we haven't yet discussed how we'll
get the keys to them (other than pre-stored).

Well, apparently we're on the same page then and I might be confused because 
there are parts of the system that have yet to be defined.

> I don't understand your intended meaning at the end when you say, "Maybe we
> 
should talk about this as we talk about naming?"

This was referring to me saying that some of the things we might want to 
achieve with meta-data might be doable over the normal names using a some 
carefully designed naming scheme.  To which you replied maybe.  So I was just 
saying that as naming is being considered, we might want to keep in mind 
possible uses for the names other than simple endpoint IDs.  Though I guess if 
we follow Kevin's proposal nothing will be simple any more :-). (For example 
dtn:role:local:commander)

Nacho

>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Ignacio
>> Solis
>> Sent: Monday, March 30, 2009 3:07 PM
>> To: dtn interest
>> Subject: Re: [dtn-interest] metadata block - 01
>>
>> Note: I'm not opposed to our current approach, I'm just trying to make
>> sure we
>> (I) understand all the design decisions.
>>
>> Symington, Susan F. wrote:
>>> My answers are interspersed below.  One short answer to your "real
>>> question" is that if you try to get metadata block-type functionality
>> by
>>> implementing an overlay of applications, then a bundle has to be
>> delivered
>>> to an application at every DTN node that it traverses. This means that
>> a
>>> bundle can't be protected from its source to its final destination
>> using
>>> DTN's end-to-end security services.
>> So, basically, the point you're making here is that if we use the
>> "overlay"
>> approach we won't be able to use DTN's security services (to their full
>> extent).
>>
>> You could, however, have some alternate setup where you don't use the
>> DTN
>> security services for everything and do some end-to-end security with
>> the
>> overlay app. In this case the overlay apps share keys to the "meta-data"
>> (for
>> searching) and only the end apps have the data key.
>>
>> App
>> |
>> HLAPI
>> |
>> Secure-Searching-Lib-App
>> |
>> AAPI
>> |
>> DTN
>> |
>> CLAPI
>> |
>> Network
>>
>>
>> HLAPI = High-Level API
>> AAPI = Application level API
>> CLAPI = Convergence Layer API
>>
>>
>> Where the Secure-Searching-Lib-App lives at every node of the "overlay".
>> As
>> far as I understand it, the current approach goes something like this:
>>
>>
>> App
>> |
>> AAPI
>> |
>> DTN -RAPI- Secure-Searching-and-Routing (SSR)
>> |
>> CLAPI
>> |
>> Network
>>
>>
>> RAPI = Routing API
>>
>>
>> So, in this case when I send something with meta-data the
>> Secure-Searching-and-Routing (lets call it SSR) will determine where
>> this
>> needs to be forwarded, according to some policies.
>>
>> The SSR needs to receive a key on how to decrypt the meta-data. This
>> would
>> imply that it 1) has to be a destination to a bundle (so we can send it
>> the
>> key) 2) there is an AAPI call that tells the SSR the key, 3) The SSR
>> reads the
>> key from the local file-system or some external tool, or 4) the key
>> needed to
>> read the meta-data is somehow embedded in some bundle not destined for
>> the SSR
>> but that the SSR will process.   Is this correct?
>>
>> For every type of meta-data, there has to exist a different SSR. Or, at
>> the
>> very least, an SSR that understands that type of meta-data.  If this SSR
>> is
>> not present at a node, the bundle might be dropped (depending on policy
>> and
>> flags). Yes?
>>
>> When I want to "search" for this data, or do a request, or something
>> similar,
>> I will have to communicate to the SSR. How will this happen? This seems
>> similar to the problem of the key. 1) We can send a search request to
>> the SSR
>> directly (SSR EID?). 2) With a mixture of the bundle destination EID and
>> a
>> meta-data block we can tell the SSR what to do. 3) There could be some
>> new API
>> to access the SSR directly. 4) There could be a new API call that is
>> sent
>> diretly to the SSR, which will then generate traffic.  Is this correct?
>>
>>
>>
>>>> Who can add a meta-data block? Sender? Intermediate node?
>>> [Susan] Any dtn node that supports the metadata block, subject to
>> local
>>> policy and the metadata type being used in the block. ("metadata type"
>> is
>>> the term we are using for what used to be called "ontology")
>>
>>>> Who can remove a meta-data block? Is it removable at all?
>>> [Susan] Any dtn node that supports the metadata block, subject to
>> local
>>> policy and the metadata type being used in the block.
>>>> Who can view a meta data block?
>>> [Susan] Any dtn node, but in order to be able to make sense of it, the
>> node
>>> has to support both the metadata block and the metadata type being
>> used in
>>> the block.
>>>> Who will 'process' a meta-data block?
>>> [Susan] Any dtn node, but in order to be able to process it correctly,
>> the
>>> node has to support both the metadata block and the metadata type
>> being
>>> used in the block.
>>>> Is a DTN router required to understand a meta-data block? What if it
>>>> doesn't?
>>> [Susan] If a dtn node receives a bundle with a metadata block and it
>>> doesn't support metadata blocks or it supports metadata blocks but it
>>> doesn't support the metadata type used in the block, or it supports
>> the
>>> metadata type being used but the metadata itself is not well-formed,
>> the
>>> node must process the bundle as if it cannot process the metadata
>> block.
>>> (This means that the node must operate according to the settings of
>> the
>>> Block Processing Control flags, including the "Delete bundle if block
>> can't
>>> be processed" flag, the "Discard block if it can't be processed" flag,
>> the
>>> "Block was forwarded without being processed" flag, etc.)
>>>> From the discussions, we will have multiple types of meta-data
>>>> (ontologies, name spaces, etc). Does this mean some might be pre-
>> defined,
>>>> some might be by convention, some might be user defined?
>>> [Susan] I'm not sure I understand this question. All the metadata
>> types
>>> have to be defined somehow in order to be interpreted correctly. In
>>> Mountain View, Kevin was advocating for using URIs as metadata. Use of
>> URIs
>>> may be adequate for representing most or all metadata. However, it may
>> not
>>> be the most efficient method for such encoding. Therefore, I would
>> like to
>>> have a "URI" metadata type defined, but also have the possibility of
>> using
>>> other metadata types, which would have to be defined, of course, and
>> the
>>> metadata type ID would have to be registered, to ensure global
>> uniqueness.
>>
>> This question was independent on the encoding used for the meta-data
>> (URI,
>> XML, binary or anything else).
>>
>> We will have meta-data that might be related to keywords, we might have
>> meta
>> data that is related to location, we might have meta-data that is
>> related to
>> rank, we might have meta-data that is related to users, we might have
>> meta-data that works like DRM.  Is this not the case?
>>
>> So, there might be a standard document (RFC?) that defines how the
>> keyword
>> meta data is defined. There might be some other definition for location
>> meta-data.
>>
>> Will we allow users to make up their own meta-data type? For example, I
>> wanted
>> to add time-of-day or time-this-bundle-has-been-flowing-through-the-
>> network.
>> Will this be allowed?
>>
>>
>>>> If we have user defined meta-data, does this mean we need to have a
>>>> plug-in/module system at the DTN router level to add the
>> functionality to
>>>>  parse these meta-data blocks?
>>> [Susan] The capability to parse and process the metadata of any given
>> type
>>> must be present in a DTN node in order for that node to support that
>>> metadata type. The functionality can be built into an external router
>>> module.
>> So, from my previous example with the time-in-network info, I will have
>> to
>> write an external router module that will deal with this, yes?  In order
>> for
>> me to load this external router, there has to be some form of plugin-
>> module
>> system (not necessarily on-the-fly, could be at compile time).  And,
>> this
>> system has to allow for multiple of these modules, after all, I don't
>> want to
>> get rid of the keyword meta-data option in order to have my time-in-
>> network
>> option.
>>
>>
>>>> Can the meta-data block be used for: - adding keywords? - adding a
>> list
>>>> of allowed users? - adding a DRM scheme? - adding a thumbnail? -
>> adding
>>>> an icon? - adding publisher information? - adding a business card? -
>>>> adding a color histogram? - adding a gps coordinate? - adding a
>> sender
>>>> military rank? - adding a DTN QoS priority level? - adding a link to
>> a
>>>> separate bundle? - adding the singer, album, track name and number of
>> a
>>>> song? - adding a cumulative cost for sending this bundle? - adding
>>>> network debugging information?
>>>>
>>>> The reason I ask this is because sometimes it seems to me that we are
>>>> blurring the lines between application level meta-data and network
>> level
>>>> meta- data. Who knows, maybe that is the goal (Cross layer design?).
>>> [Susan] I see the "data" part of metadata as referring to payload
>> data, not
>>> DTN network data. So metadata seems to me to be most appropriate for
>> the
>>> case of carrying information about the payload. Even though it is
>>> information about the payload, it is used by dtn nodes to make
>>> network-level decisions such as whether they should store the bundle
>> or how
>>> they should forward the bundle. I don't think the metadata block, for
>>> example, would be a good choice of how to carry previous hop EID
>>> information; previous hop EID information is not information about the
>>> payload. (That's why I think we need a separate Previous Hop block.)
>> So, from this description you are saying that:
>> Meta-Data is data about the payload that can be used to make network-
>> level
>> decisions
>> ...excluding...
>> information that is tied to the bundle but not tied to the payload.
>>
>> Yes?
>>
>> So, from my previous time-in-network example you would support that as a
>> meta-data block if I can justify how this is related to the payload,
>> otherwise
>> you would argue I need a separate block.
>>
>> If I'm using it as a type of TTL field, then it would merit it's own
>> block.
>> But if I use it at the application level to determine if the orders
>> contained
>> in this payload are fresh, then it should go in the meta-data block.
>> Yes?
>>
>>>> What is the difference between sending 1 bundle with payload and
>> meta-
>>>> data  OR sending 2 bundles, one with payload and the other with the
>>>> "meta-data" in the payload?
>>>>
>>>> Lets say 1 bundle payload+meta-data needs to be sent-processed
>> together.
>>>> If the meta-data needs a plugin/module to be understood, this means
>> we
>>>> need a customized DTN router.  IF we had a customized DTN router,
>>>> couldn't we just use the 2 bundle version then? All we would need is
>> some
>>>> way to associate the 2 bundles together. One disadvantage to this is
>> that
>>>> a "non-customized" DTN router might not understand the association
>>>> between the 2 bundles without making understanding the association
>>>> mandatory. (I understand that this might just seem like a meta-data
>> block
>>>> in disguise)
>>> [Susan] Another difference is that a dtn node wouldn't know how to
>> process
>>> one bundle until/unless it receives its "pair" bundle. However, there
>> is no
>>> guarantee it will even receive its "pair", unless you force that
>> through
>>> routing. If all the information is intended to go together, and I
>> believe
>>> it is in the case in which the metadata provides information regarding
>> how
>>> to act on the bundle, then it seems sensible that all the information
>>> should be shipped together and not as two separate bundles. Suppose
>> you
>>> don't trust a dtn node very much so you don't want to give it the
>> ability
>>> to decrypt the payload in your bundle. However, you do want the node
>> to be
>>> able to store the bundle and provide it to new subscribers if they
>> express
>>> an interest in bundles with payloads that are about what your bundle
>> is
>>> about. You can tag the bundle with metadata about the payload subject
>>> ("soccer"), encrypt the payload, and transmit it.  A dtn node that has
>> no
>>> way of decrypting the payload can store it and, in response to future
>>> requests, provide it to new subscribers who are interested in soccer.
>> I agree that if things are supposed to be processed together they should
>> somehow go together.
>> I also agree that it's nice to have a separation so that an insecure
>> node can
>> cache a bundle and still be able to process requests.
>> Both of these could be potentially done using 2 bundles though. (Maybe
>> with a
>> "Related-To" field to tell DTN routers to send both together, for
>> example).
>>
>>
>>>> Alright, enough rambling for now, here's my real questions:
>>>>
>>>> What are the differences between having a subset of nodes
>> understanding
>>>> meta-data blocks of a certain type (via these addons/modules/plugins)
>> and
>>>>  running an "overlay" of applications on those same nodes and
>> transmit
>>>> everything in the payload?
>>>>
>>>> Storage handling? Cleaner design? Lower overhead?
>>>>
>>>> If I'm a new developer, and want to write something for DTN, why use
>> the
>>>> router API vs the application API?
>>> [Susan] Well, for one thing, if you are using the application API
>> instead
>>> of the router API, then suppose you have three nodes in a network A--
>> B--C,
>>> with a topology such that for a bundle to be sent from A to C, it has
>> to go
>>> through node B. In the application API example, if I understand you
>>> correctly, the Bundle would be sent from A to B, delivered to an
>>> application at B, and then sent from B to C. In this case, it is not
>>> possible to take advantage of any end-to-end security services from A
>> (the
>>> source) to C (the ultimate destination).  All transmissions in such a
>>> network overlay would have to be 1-hop transmissions.
>> All (most) transmissions in any network are 1-hop transmissions.
>> Seriously
>> though, it depends where the processing happens in the middle nodes.
>> I'm sure
>> there are alternative ways that things could be done to "solve" the
>> security
>> problem.
>>
>>>> I think we will need some concrete use cases to answer some of these
>>>> questions.
>>>>
>>>> I'm sorry I had to leave the meeting Thursday, would have loved to
>> stayed
>>>> and discussed there.
>>>>
>>>> Cheers,
>>>>
>>>> Nacho
>>>>
>>>>
>>>> PS. Finally, can't some of the things we want to use meta-data blocks
>> for
>>>> be solved by a good naming scheme? or even the bundle-in-bundle?
>>> [Susan] Maybe.
>> Maybe we should talk about this as we talk about naming?
>>
>> Nacho
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Symington, Susan F." <[email-masked]>
To: Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Mon, 30 Mar 2009 17:54:31 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] metadata block - 01

Nacho,

I think it might get too confusing to follow this discussion if I intersperse my comments below, so I'll try just providing a self-contained response here up top.

Yes, it is true that you can provide security as part of the application layer instead of using the security services that are part of DTN. The application can encrypt the application data and sign it and send these as the bundle's payload. This is what you would have to do to have end-to-end confidentiality and end-to-end integrity in an application overlay system such as the one that you are describing, assuming the bundle needs to travel more than a single DTN hop to get from its source to its destination.

Your original question was why use the router API rather than the application API and my answer is that one reason to use the router API is that this enables you to take advantage of DTN security. If you don't want end-to-end security or you are willing to code end-to-end security into each one of your applications instead of using DTN security, then this reason for preferring the router API rather than the application API is not important to you.

In response to the many questions "Yes?," "Is this correct?," etc. that you pose throughout your narrative, my answers are yes. If I understand you correctly, I pretty much agree with what you are saying. And yes, I envision users as being allowed to make up their own metadata types (and registering their IDs to ensure global uniqueness). And yes, there could be several external routers, each supporting a different metadata type. I would add the following elaboration:

It is true that the SSR needs to receive a key for decrypting the meta-data. This strikes me as similar to the fact that each DTN node that is supporting the BAB needs to receive a key for calculating and verifying the security result in the BAB. We have not yet defined DTN key management so we haven't yet discussed how the component within the DTN node that is supporting the BAB will get this key. The same is true for the DTN nodes that are supporting the PCB and the PIB; they will need keys and we haven't yet discussed how we'll get the keys to them (other than pre-stored).

I don't understand your intended meaning at the end when you say, "Maybe we should talk about this as we talk about naming?"

-susan

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Ignacio
>Solis
>Sent: Monday, March 30, 2009 3:07 PM
>To: dtn interest
>Subject: Re: [dtn-interest] metadata block - 01
>
>Note: I'm not opposed to our current approach, I'm just trying to make
>sure we
>(I) understand all the design decisions.
>
>Symington, Susan F. wrote:
>> My answers are interspersed below.  One short answer to your "real
>> question" is that if you try to get metadata block-type functionality
>by
>> implementing an overlay of applications, then a bundle has to be
>delivered
>> to an application at every DTN node that it traverses. This means that
>a
>> bundle can't be protected from its source to its final destination
>using
>> DTN's end-to-end security services.
>
>So, basically, the point you're making here is that if we use the
>"overlay"
>approach we won't be able to use DTN's security services (to their full
>extent).
>
>You could, however, have some alternate setup where you don't use the
>DTN
>security services for everything and do some end-to-end security with
>the
>overlay app. In this case the overlay apps share keys to the "meta-data"
>(for
>searching) and only the end apps have the data key.
>
>App
>|
>HLAPI
>|
>Secure-Searching-Lib-App
>|
>AAPI
>|
>DTN
>|
>CLAPI
>|
>Network
>
>
>HLAPI = High-Level API
>AAPI = Application level API
>CLAPI = Convergence Layer API
>
>
>Where the Secure-Searching-Lib-App lives at every node of the "overlay".
>As
>far as I understand it, the current approach goes something like this:
>
>
>App
>|
>AAPI
>|
>DTN -RAPI- Secure-Searching-and-Routing (SSR)
>|
>CLAPI
>|
>Network
>
>
>RAPI = Routing API
>
>
>So, in this case when I send something with meta-data the
>Secure-Searching-and-Routing (lets call it SSR) will determine where
>this
>needs to be forwarded, according to some policies.
>
>The SSR needs to receive a key on how to decrypt the meta-data. This
>would
>imply that it 1) has to be a destination to a bundle (so we can send it
>the
>key) 2) there is an AAPI call that tells the SSR the key, 3) The SSR
>reads the
>key from the local file-system or some external tool, or 4) the key
>needed to
>read the meta-data is somehow embedded in some bundle not destined for
>the SSR
>but that the SSR will process.   Is this correct?
>
>For every type of meta-data, there has to exist a different SSR. Or, at
>the
>very least, an SSR that understands that type of meta-data.  If this SSR
>is
>not present at a node, the bundle might be dropped (depending on policy
>and
>flags). Yes?
>
>When I want to "search" for this data, or do a request, or something
>similar,
>I will have to communicate to the SSR. How will this happen? This seems
>similar to the problem of the key. 1) We can send a search request to
>the SSR
>directly (SSR EID?). 2) With a mixture of the bundle destination EID and
>a
>meta-data block we can tell the SSR what to do. 3) There could be some
>new API
>to access the SSR directly. 4) There could be a new API call that is
>sent
>diretly to the SSR, which will then generate traffic.  Is this correct?
>
>
>
>>> Who can add a meta-data block? Sender? Intermediate node?
>> [Susan] Any dtn node that supports the metadata block, subject to
>local
>> policy and the metadata type being used in the block. ("metadata type"
>is
>> the term we are using for what used to be called "ontology")
>
>
>>> Who can remove a meta-data block? Is it removable at all?
>> [Susan] Any dtn node that supports the metadata block, subject to
>local
>> policy and the metadata type being used in the block.
>
>>> Who can view a meta data block?
>> [Susan] Any dtn node, but in order to be able to make sense of it, the
>node
>> has to support both the metadata block and the metadata type being
>used in
>> the block.
>
>>> Who will 'process' a meta-data block?
>> [Susan] Any dtn node, but in order to be able to process it correctly,
>the
>> node has to support both the metadata block and the metadata type
>being
>> used in the block.
>
>>> Is a DTN router required to understand a meta-data block? What if it
>>> doesn't?
>> [Susan] If a dtn node receives a bundle with a metadata block and it
>> doesn't support metadata blocks or it supports metadata blocks but it
>> doesn't support the metadata type used in the block, or it supports
>the
>> metadata type being used but the metadata itself is not well-formed,
>the
>> node must process the bundle as if it cannot process the metadata
>block.
>> (This means that the node must operate according to the settings of
>the
>> Block Processing Control flags, including the "Delete bundle if block
>can't
>> be processed" flag, the "Discard block if it can't be processed" flag,
>the
>> "Block was forwarded without being processed" flag, etc.)
>
>>> From the discussions, we will have multiple types of meta-data
>>> (ontologies, name spaces, etc). Does this mean some might be pre-
>defined,
>>> some might be by convention, some might be user defined?
>>
>> [Susan] I'm not sure I understand this question. All the metadata
>types
>> have to be defined somehow in order to be interpreted correctly. In
>> Mountain View, Kevin was advocating for using URIs as metadata. Use of
>URIs
>> may be adequate for representing most or all metadata. However, it may
>not
>> be the most efficient method for such encoding. Therefore, I would
>like to
>> have a "URI" metadata type defined, but also have the possibility of
>using
>> other metadata types, which would have to be defined, of course, and
>the
>> metadata type ID would have to be registered, to ensure global
>uniqueness.
>
>This question was independent on the encoding used for the meta-data
>(URI,
>XML, binary or anything else).
>
>We will have meta-data that might be related to keywords, we might have
>meta
>data that is related to location, we might have meta-data that is
>related to
>rank, we might have meta-data that is related to users, we might have
>meta-data that works like DRM.  Is this not the case?
>
>So, there might be a standard document (RFC?) that defines how the
>keyword
>meta data is defined. There might be some other definition for location
>meta-data.
>
>Will we allow users to make up their own meta-data type? For example, I
>wanted
>to add time-of-day or time-this-bundle-has-been-flowing-through-the-
>network.
>Will this be allowed?
>
>
>>> If we have user defined meta-data, does this mean we need to have a
>>> plug-in/module system at the DTN router level to add the
>functionality to
>>>  parse these meta-data blocks?
>>
>> [Susan] The capability to parse and process the metadata of any given
>type
>> must be present in a DTN node in order for that node to support that
>> metadata type. The functionality can be built into an external router
>> module.
>
>So, from my previous example with the time-in-network info, I will have
>to
>write an external router module that will deal with this, yes?  In order
>for
>me to load this external router, there has to be some form of plugin-
>module
>system (not necessarily on-the-fly, could be at compile time).  And,
>this
>system has to allow for multiple of these modules, after all, I don't
>want to
>get rid of the keyword meta-data option in order to have my time-in-
>network
>option.
>
>
>>> Can the meta-data block be used for: - adding keywords? - adding a
>list
>>> of allowed users? - adding a DRM scheme? - adding a thumbnail? -
>adding
>>> an icon? - adding publisher information? - adding a business card? -
>>> adding a color histogram? - adding a gps coordinate? - adding a
>sender
>>> military rank? - adding a DTN QoS priority level? - adding a link to
>a
>>> separate bundle? - adding the singer, album, track name and number of
>a
>>> song? - adding a cumulative cost for sending this bundle? - adding
>>> network debugging information?
>>>
>>> The reason I ask this is because sometimes it seems to me that we are
>>> blurring the lines between application level meta-data and network
>level
>>> meta- data. Who knows, maybe that is the goal (Cross layer design?).
>>
>> [Susan] I see the "data" part of metadata as referring to payload
>data, not
>> DTN network data. So metadata seems to me to be most appropriate for
>the
>> case of carrying information about the payload. Even though it is
>> information about the payload, it is used by dtn nodes to make
>> network-level decisions such as whether they should store the bundle
>or how
>> they should forward the bundle. I don't think the metadata block, for
>> example, would be a good choice of how to carry previous hop EID
>> information; previous hop EID information is not information about the
>> payload. (That's why I think we need a separate Previous Hop block.)
>
>So, from this description you are saying that:
>Meta-Data is data about the payload that can be used to make network-
>level
>decisions
>...excluding...
>information that is tied to the bundle but not tied to the payload.
>
>Yes?
>
>So, from my previous time-in-network example you would support that as a
>meta-data block if I can justify how this is related to the payload,
>otherwise
>you would argue I need a separate block.
>
>If I'm using it as a type of TTL field, then it would merit it's own
>block.
>But if I use it at the application level to determine if the orders
>contained
>in this payload are fresh, then it should go in the meta-data block.
>Yes?
>
>>> What is the difference between sending 1 bundle with payload and
>meta-
>>> data  OR sending 2 bundles, one with payload and the other with the
>>> "meta-data" in the payload?
>>>
>>> Lets say 1 bundle payload+meta-data needs to be sent-processed
>together.
>>> If the meta-data needs a plugin/module to be understood, this means
>we
>>> need a customized DTN router.  IF we had a customized DTN router,
>>> couldn't we just use the 2 bundle version then? All we would need is
>some
>>> way to associate the 2 bundles together. One disadvantage to this is
>that
>>> a "non-customized" DTN router might not understand the association
>>> between the 2 bundles without making understanding the association
>>> mandatory. (I understand that this might just seem like a meta-data
>block
>>> in disguise)
>>
>> [Susan] Another difference is that a dtn node wouldn't know how to
>process
>> one bundle until/unless it receives its "pair" bundle. However, there
>is no
>> guarantee it will even receive its "pair", unless you force that
>through
>> routing. If all the information is intended to go together, and I
>believe
>> it is in the case in which the metadata provides information regarding
>how
>> to act on the bundle, then it seems sensible that all the information
>> should be shipped together and not as two separate bundles. Suppose
>you
>> don't trust a dtn node very much so you don't want to give it the
>ability
>> to decrypt the payload in your bundle. However, you do want the node
>to be
>> able to store the bundle and provide it to new subscribers if they
>express
>> an interest in bundles with payloads that are about what your bundle
>is
>> about. You can tag the bundle with metadata about the payload subject
>> ("soccer"), encrypt the payload, and transmit it.  A dtn node that has
>no
>> way of decrypting the payload can store it and, in response to future
>> requests, provide it to new subscribers who are interested in soccer.
>
>I agree that if things are supposed to be processed together they should
>somehow go together.
>I also agree that it's nice to have a separation so that an insecure
>node can
>cache a bundle and still be able to process requests.
>Both of these could be potentially done using 2 bundles though. (Maybe
>with a
>"Related-To" field to tell DTN routers to send both together, for
>example).
>
>
>>> Alright, enough rambling for now, here's my real questions:
>>>
>>> What are the differences between having a subset of nodes
>understanding
>>> meta-data blocks of a certain type (via these addons/modules/plugins)
>and
>>>  running an "overlay" of applications on those same nodes and
>transmit
>>> everything in the payload?
>>>
>>> Storage handling? Cleaner design? Lower overhead?
>>>
>>> If I'm a new developer, and want to write something for DTN, why use
>the
>>> router API vs the application API?
>>
>> [Susan] Well, for one thing, if you are using the application API
>instead
>> of the router API, then suppose you have three nodes in a network A--
>B--C,
>> with a topology such that for a bundle to be sent from A to C, it has
>to go
>> through node B. In the application API example, if I understand you
>> correctly, the Bundle would be sent from A to B, delivered to an
>> application at B, and then sent from B to C. In this case, it is not
>> possible to take advantage of any end-to-end security services from A
>(the
>> source) to C (the ultimate destination).  All transmissions in such a
>> network overlay would have to be 1-hop transmissions.
>
>All (most) transmissions in any network are 1-hop transmissions.
>Seriously
>though, it depends where the processing happens in the middle nodes.
>I'm sure
>there are alternative ways that things could be done to "solve" the
>security
>problem.
>
>>> I think we will need some concrete use cases to answer some of these
>>> questions.
>>>
>>> I'm sorry I had to leave the meeting Thursday, would have loved to
>stayed
>>> and discussed there.
>>>
>>> Cheers,
>>>
>>> Nacho
>>>
>>>
>>> PS. Finally, can't some of the things we want to use meta-data blocks
>for
>>> be solved by a good naming scheme? or even the bundle-in-bundle?
>> [Susan] Maybe.
>
>Maybe we should talk about this as we talk about naming?
>
>Nacho
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 30 Mar 2009 12:16:30 PDT
From: Ignacio Solis <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

Ivancic, William D. (GRC-RHN0) wrote:
> From what I observed at Google and the conversations taking place regarding
> meta data and particularly regarding security and the key information
> block,  here is my take on Meta-data.
> 
> *  DARPA is tying to morph Bundling into a secure content distribution and
> caching system.  I can encrypted different meta-data blocks with different
> keys for different class users.  I also can give great detail of the
> contents in a meta-data block destined for a secure gateway.

As a general philosophy I don't disagree with secure-content distribution and 
caching, after all, that's the work I'm supposed to be doing ( as a 
disclaimer, Van Jacobson @ PARC is working on such a system ).

> Link the complexity of the bundle security protocol (or whatever it will
> eventually be called - security extension blocks) and the meta-data blocks
> and this all falls together.
> 
> Bundles will be stored (if appropriate) as well at transmitted.  The
> meta-data block will be search for content, not the bundle.  That will be
> securely stored with some other key.
> 
> Key management will be interesting.

My argument is this, if we are trying to give bundles content-based features, 
lets make sure the system as a whole falls into place.

I was playing devil's advocate (or maybe just a discussant) asking what the 
benefits are to bringing all these features inside DTN as opposed to 
along-side DTN or on-top of DTN. And if we do decide to bring them inside DTN, 
then we should be looking at what possible changes are needed in other parts 
of the system.

Nacho

>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On 
>> Behalf Of Ignacio Solis
>> Sent: Friday, March 27, 2009 12:38 PM
>> To: dtn interest
>> Subject: Re: [dtn-interest] metadata block - 01
>>
>> I've been part of many meta-data discussions before and I 
>> still don't get what we're trying to do. As time goes on what 
>> I get is more questions. So, before I (or others) get more 
>> confused, let me ask some of them.  Please respond what _you_ 
>> think is the direction we should be going.  Some of the 
>> answers might seem obvious, I understand. And some of them 
>> might be "policy" dependent, I understand that too.
>>
>>
>> Who can add a meta-data block? Sender? Intermediate node?
>>
>> Who can remove a meta-data block? Is it removable at all?
>>
>> Who can view a meta data block?
>>
>> Who will 'process' a meta-data block?
>>
>> Is a DTN router required to understand a meta-data block? 
>> What if it doesn't?
>>
>>  From the discussions, we will have multiple types of 
>> meta-data (ontologies, name spaces, etc). Does this mean some 
>> might be pre-defined, some might be by convention, some might 
>> be user defined?
>>
>> If we have user defined meta-data, does this mean we need to 
>> have a plug-in/module system at the DTN router level to add 
>> the functionality to parse these meta-data blocks?
>>
>> Can the meta-data block be used for:
>> - adding keywords?
>> - adding a list of allowed users?
>> - adding a DRM scheme?
>> - adding a thumbnail?
>> - adding an icon?
>> - adding publisher information?
>> - adding a business card?
>> - adding a color histogram?
>> - adding a gps coordinate?
>> - adding a sender military rank?
>> - adding a DTN QoS priority level?
>> - adding a link to a separate bundle?
>> - adding the singer, album, track name and number of a song?
>> - adding a cumulative cost for sending this bundle?
>> - adding network debugging information?
>>
>> The reason I ask this is because sometimes it seems to me 
>> that we are blurring the lines between application level 
>> meta-data and network level meta-data. Who knows, maybe that 
>> is the goal (Cross layer design?).
>>
>> What is the difference between sending 1 bundle with payload 
>> and meta-data  OR sending 2 bundles, one with payload and the 
>> other with the "meta-data" in the payload?
>>
>> Lets say 1 bundle payload+meta-data needs to be 
>> sent-processed together. If the meta-data needs a 
>> plugin/module to be understood, this means we need a 
>> customized DTN router.  IF we had a customized DTN router, 
>> couldn't we just use the 2 bundle version then? All we would 
>> need is some way to associate the
>> 2 bundles together. One disadvantage to this is that a 
>> "non-customized" DTN router might not understand the 
>> association between the 2 bundles without making 
>> understanding the association mandatory. (I understand that 
>> this might just seem like a meta-data block in disguise)
>>
>>
>> Alright, enough rambling for now, here's my real questions:
>>
>> What are the differences between having a subset of nodes 
>> understanding meta-data blocks of a certain type (via these 
>> addons/modules/plugins) and running an "overlay" of 
>> applications on those same nodes and transmit everything in 
>> the payload?
>>
>> Storage handling? Cleaner design? Lower overhead?
>>
>> If I'm a new developer, and want to write something for DTN, 
>> why use the router API vs the application API?
>>
>> I think we will need some concrete use cases to answer some 
>> of these questions.
>>
>> I'm sorry I had to leave the meeting Thursday, would have 
>> loved to stayed and discussed there.
>>
>> Cheers,
>>
>> Nacho
>>
>>
>> PS. Finally, can't some of the things we want to use 
>> meta-data blocks for be solved by a good naming scheme? or 
>> even the bundle-in-bundle?
>>
>>
>> Stephen Farrell wrote:
>>> So a related, but different, question.
>>>
>>> In Mountain View when we discussed this there seemed to be two
>>> fairly different purposes that folks had in mind when talking
>>> about this.
>>>
>>> Susan and some others, (who've written this I-D) were talking
>>> about using the extension block to pass around routing information
>>> of some sort. I think the main example related to security
>>> labels, so that some bundles can be routed only on appropriate
>>> "secure" paths. So that meta-data, while associated with the
>>> content, seems to be intended for routers and/or forwarders.
>>>
>>> Kevin and a couple of others (I think) seemed to be talking
>>> more about content-distribution. I think the example there that
>>> doesn't fit with the above might be meta-data that identifies
>>> the bundle payload in a fine-grained manner for applications.
>>>
>>> Do we think the same extension block would/should be used for
>>> both purposes? (Assuming we think they differ.)
>>>
>>> S.
>>>
>>> Armando Caro wrote:
>>>> Peter Lovell wrote:
>>>>> There is NO mechanism by which any block other than the 
>> payload can be
>>>>> fragmented.
>>>>>
>>>>> None, at all, in any way.
>>>> Yes, I realize that.. And that was my point.
>>>>
>>>>> Path MTU is not relevant to dtn. That's entirely a CL 
>> issue. It's up to
>>>>> the CL to determine how to transport the bundle over the 
>> next-hop and
>>>>> dtn cares little (although more than zero) about that.
>>>>  >
>>>>> To take a cue from RFC1149, one could print it, employ 
>> aerial conveyance
>>>>> to the next node, scan it there and send it on its way. 
>> The only MTU
>>>>> issue is the size allowable for the aerial conveyance, 
>> which is defined
>>>>> by rfc as being variable. If that is too restrictive then 
>> the CL might
>>>>> send two or more parts by separate conveyance, 
>> reassembling the stack
>>>>> before the scan process. Higher bandwidth could probably 
>> be obtained by
>>>>> writing to a micro SD card rather than the print/scan 
>> scheme, but the
>>>>> effect is the same.
>>>>>
>>>>> So there is no sense in which control overhead crowds out 
>> the payload,
>>>>> or other blocks. The space available is quite large and 
>> not constrained
>>>>> by path MTU, unless a dtn implementation should choose to be so
>>>>> constrained (and I would hope not).
>>>> I would argue that putting the burden on the CL is more 
>> restrictive, not 
>>>> less. If you let bundles grow arbitrarily large, each 
>> hop's CL may be 
>>>> forced to reassemble before the bundle can be forwarded. That's 
>>>> inefficient, especially for DTNs (when the D=Disruption). 
>> The bundles 
>>>> have a notion of lifetime, not the CL-specific fragments.
>>>>
>>>> Suppose a bundle's non-payload blocks grow so large, that 
>> a CL needs to 
>>>> fragment the bundle to forward it to the next hop. Now 
>> suppose that the 
>>>> CL successfully sends all but one fragment to the next hop 
>> right before 
>>>> the link goes down. The receiving CL cannot do anything with the 
>>>> fragments. This means that when the link comes back up, 
>> the sending CL 
>>>> needs to retransmit all the fragments again. This could be 
>> a problem for 
>>>> flaky links with small MTUs relative to the size of the bundles.
>>>>
>>>> The CL could do something smarter and try to hold onto the 
>> fragments, 
>>>> but then the CL would need to do DTN itself.
>>>>
>>>> I don't know what the right solution is. Clearly, we don't 
>> want to limit 
>>>> the flexibility of the control blocks, but at the same 
>> time, I think we 
>>>> do need some provision of what is reasonable use/size of 
>> these blocks 
>>>> that are not fragmentable.
>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 30 Mar 2009 12:07:25 PDT
From: Ignacio Solis <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

Note: I'm not opposed to our current approach, I'm just trying to make sure we 
(I) understand all the design decisions.

Symington, Susan F. wrote:
> My answers are interspersed below.  One short answer to your "real
> question" is that if you try to get metadata block-type functionality by
> implementing an overlay of applications, then a bundle has to be delivered
> to an application at every DTN node that it traverses. This means that a
> bundle can't be protected from its source to its final destination using
> DTN's end-to-end security services.

So, basically, the point you're making here is that if we use the "overlay" 
approach we won't be able to use DTN's security services (to their full extent).

You could, however, have some alternate setup where you don't use the DTN 
security services for everything and do some end-to-end security with the 
overlay app. In this case the overlay apps share keys to the "meta-data" (for 
searching) and only the end apps have the data key.

App
|
HLAPI
|
Secure-Searching-Lib-App
|
AAPI
|
DTN
|
CLAPI
|
Network

HLAPI = High-Level API
AAPI = Application level API
CLAPI = Convergence Layer API

Where the Secure-Searching-Lib-App lives at every node of the "overlay". As 
far as I understand it, the current approach goes something like this:

App
|
AAPI
|
DTN -RAPI- Secure-Searching-and-Routing (SSR)
|
CLAPI
|
Network

RAPI = Routing API

So, in this case when I send something with meta-data the 
Secure-Searching-and-Routing (lets call it SSR) will determine where this 
needs to be forwarded, according to some policies.

The SSR needs to receive a key on how to decrypt the meta-data. This would 
imply that it 1) has to be a destination to a bundle (so we can send it the 
key) 2) there is an AAPI call that tells the SSR the key, 3) The SSR reads the 
key from the local file-system or some external tool, or 4) the key needed to 
read the meta-data is somehow embedded in some bundle not destined for the SSR 
but that the SSR will process.   Is this correct?

For every type of meta-data, there has to exist a different SSR. Or, at the 
very least, an SSR that understands that type of meta-data.  If this SSR is 
not present at a node, the bundle might be dropped (depending on policy and 
flags). Yes?

When I want to "search" for this data, or do a request, or something similar, 
I will have to communicate to the SSR. How will this happen? This seems 
similar to the problem of the key. 1) We can send a search request to the SSR 
directly (SSR EID?). 2) With a mixture of the bundle destination EID and a 
meta-data block we can tell the SSR what to do. 3) There could be some new API 
to access the SSR directly. 4) There could be a new API call that is sent 
diretly to the SSR, which will then generate traffic.  Is this correct?

>> Who can add a meta-data block? Sender? Intermediate node? 
> [Susan] Any dtn node that supports the metadata block, subject to local
> policy and the metadata type being used in the block. ("metadata type" is
> the term we are using for what used to be called "ontology")

>> Who can remove a meta-data block? Is it removable at all?
> [Susan] Any dtn node that supports the metadata block, subject to local
> policy and the metadata type being used in the block.

>> Who can view a meta data block?
> [Susan] Any dtn node, but in order to be able to make sense of it, the node
> has to support both the metadata block and the metadata type being used in
> the block.

>> Who will 'process' a meta-data block?
> [Susan] Any dtn node, but in order to be able to process it correctly, the
> node has to support both the metadata block and the metadata type being
> used in the block.

>> Is a DTN router required to understand a meta-data block? What if it 
>> doesn't?
> [Susan] If a dtn node receives a bundle with a metadata block and it
> doesn't support metadata blocks or it supports metadata blocks but it
> doesn't support the metadata type used in the block, or it supports the
> metadata type being used but the metadata itself is not well-formed, the
> node must process the bundle as if it cannot process the metadata block.
> (This means that the node must operate according to the settings of the
> Block Processing Control flags, including the "Delete bundle if block can't
> be processed" flag, the "Discard block if it can't be processed" flag, the
> "Block was forwarded without being processed" flag, etc.)

>> From the discussions, we will have multiple types of meta-data 
>> (ontologies, name spaces, etc). Does this mean some might be pre-defined,
>> some might be by convention, some might be user defined?
> 
> [Susan] I'm not sure I understand this question. All the metadata types
> have to be defined somehow in order to be interpreted correctly. In
> Mountain View, Kevin was advocating for using URIs as metadata. Use of URIs
> may be adequate for representing most or all metadata. However, it may not
> be the most efficient method for such encoding. Therefore, I would like to
> have a "URI" metadata type defined, but also have the possibility of using
> other metadata types, which would have to be defined, of course, and the
> metadata type ID would have to be registered, to ensure global uniqueness.

This question was independent on the encoding used for the meta-data (URI, 
XML, binary or anything else).

We will have meta-data that might be related to keywords, we might have meta 
data that is related to location, we might have meta-data that is related to 
rank, we might have meta-data that is related to users, we might have 
meta-data that works like DRM.  Is this not the case?

So, there might be a standard document (RFC?) that defines how the keyword 
meta data is defined. There might be some other definition for location meta-data.

Will we allow users to make up their own meta-data type? For example, I wanted 
to add time-of-day or time-this-bundle-has-been-flowing-through-the-network. 
Will this be allowed?

>> If we have user defined meta-data, does this mean we need to have a 
>> plug-in/module system at the DTN router level to add the functionality to
>>  parse these meta-data blocks?
> 
> [Susan] The capability to parse and process the metadata of any given type
> must be present in a DTN node in order for that node to support that
> metadata type. The functionality can be built into an external router
> module.

So, from my previous example with the time-in-network info, I will have to 
write an external router module that will deal with this, yes?  In order for 
me to load this external router, there has to be some form of plugin-module 
system (not necessarily on-the-fly, could be at compile time).  And, this 
system has to allow for multiple of these modules, after all, I don't want to 
get rid of the keyword meta-data option in order to have my time-in-network 
option.

>> Can the meta-data block be used for: - adding keywords? - adding a list
>> of allowed users? - adding a DRM scheme? - adding a thumbnail? - adding
>> an icon? - adding publisher information? - adding a business card? -
>> adding a color histogram? - adding a gps coordinate? - adding a sender
>> military rank? - adding a DTN QoS priority level? - adding a link to a
>> separate bundle? - adding the singer, album, track name and number of a
>> song? - adding a cumulative cost for sending this bundle? - adding
>> network debugging information?
>> 
>> The reason I ask this is because sometimes it seems to me that we are 
>> blurring the lines between application level meta-data and network level
>> meta- data. Who knows, maybe that is the goal (Cross layer design?).
> 
> [Susan] I see the "data" part of metadata as referring to payload data, not
> DTN network data. So metadata seems to me to be most appropriate for the
> case of carrying information about the payload. Even though it is
> information about the payload, it is used by dtn nodes to make
> network-level decisions such as whether they should store the bundle or how
> they should forward the bundle. I don't think the metadata block, for
> example, would be a good choice of how to carry previous hop EID
> information; previous hop EID information is not information about the
> payload. (That's why I think we need a separate Previous Hop block.)

So, from this description you are saying that:
Meta-Data is data about the payload that can be used to make network-level 
decisions
...excluding...
information that is tied to the bundle but not tied to the payload.

Yes?

So, from my previous time-in-network example you would support that as a 
meta-data block if I can justify how this is related to the payload, otherwise 
you would argue I need a separate block.

If I'm using it as a type of TTL field, then it would merit it's own block. 
But if I use it at the application level to determine if the orders contained 
in this payload are fresh, then it should go in the meta-data block.  Yes?

>> What is the difference between sending 1 bundle with payload and meta- 
>> data  OR sending 2 bundles, one with payload and the other with the
>> "meta-data" in the payload?
>> 
>> Lets say 1 bundle payload+meta-data needs to be sent-processed together. 
>> If the meta-data needs a plugin/module to be understood, this means we
>> need a customized DTN router.  IF we had a customized DTN router,
>> couldn't we just use the 2 bundle version then? All we would need is some
>> way to associate the 2 bundles together. One disadvantage to this is that
>> a "non-customized" DTN router might not understand the association
>> between the 2 bundles without making understanding the association
>> mandatory. (I understand that this might just seem like a meta-data block
>> in disguise)
> 
> [Susan] Another difference is that a dtn node wouldn't know how to process
> one bundle until/unless it receives its "pair" bundle. However, there is no
> guarantee it will even receive its "pair", unless you force that through
> routing. If all the information is intended to go together, and I believe
> it is in the case in which the metadata provides information regarding how
> to act on the bundle, then it seems sensible that all the information
> should be shipped together and not as two separate bundles. Suppose you
> don't trust a dtn node very much so you don't want to give it the ability
> to decrypt the payload in your bundle. However, you do want the node to be
> able to store the bundle and provide it to new subscribers if they express
> an interest in bundles with payloads that are about what your bundle is
> about. You can tag the bundle with metadata about the payload subject
> ("soccer"), encrypt the payload, and transmit it.  A dtn node that has no
> way of decrypting the payload can store it and, in response to future
> requests, provide it to new subscribers who are interested in soccer.

I agree that if things are supposed to be processed together they should 
somehow go together.
I also agree that it's nice to have a separation so that an insecure node can 
cache a bundle and still be able to process requests.
Both of these could be potentially done using 2 bundles though. (Maybe with a 
"Related-To" field to tell DTN routers to send both together, for example).

>> Alright, enough rambling for now, here's my real questions:
>> 
>> What are the differences between having a subset of nodes understanding 
>> meta-data blocks of a certain type (via these addons/modules/plugins) and
>>  running an "overlay" of applications on those same nodes and transmit 
>> everything in the payload?
>> 
>> Storage handling? Cleaner design? Lower overhead?
>> 
>> If I'm a new developer, and want to write something for DTN, why use the 
>> router API vs the application API?
> 
> [Susan] Well, for one thing, if you are using the application API instead
> of the router API, then suppose you have three nodes in a network A--B--C,
> with a topology such that for a bundle to be sent from A to C, it has to go
> through node B. In the application API example, if I understand you
> correctly, the Bundle would be sent from A to B, delivered to an
> application at B, and then sent from B to C. In this case, it is not
> possible to take advantage of any end-to-end security services from A (the
> source) to C (the ultimate destination).  All transmissions in such a
> network overlay would have to be 1-hop transmissions.

All (most) transmissions in any network are 1-hop transmissions. Seriously 
though, it depends where the processing happens in the middle nodes.  I'm sure 
there are alternative ways that things could be done to "solve" the security 
problem.

>> I think we will need some concrete use cases to answer some of these 
>> questions.
>> 
>> I'm sorry I had to leave the meeting Thursday, would have loved to stayed
>> and discussed there.
>> 
>> Cheers,
>> 
>> Nacho
>> 
>> 
>> PS. Finally, can't some of the things we want to use meta-data blocks for
>> be solved by a good naming scheme? or even the bundle-in-bundle?
> [Susan] Maybe.

Maybe we should talk about this as we talk about naming?

Nacho

From: Peter Lovell <[email-masked]>
To: "William D. (GRC-RCN0) Ivancic" <[email-masked]>, Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Mon, 30 Mar 2009 13:53:42 -0400
Subject: [dtn-interest] Re(2):  metadata block - 01

Hi Will,

I have noticed this, and in fact made a couple of comments about it at
the recent meeting. I've been thinking about some of the security issues
and implications will be, and how these may be reflected in the Bundle
Security Protocol.

It will soon be time to start another I-D to collect these ideas.

Cheers.....Peter

On Mon, Mar 30, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>>From what I observed at Google and the conversations taking place
>regarding meta data and particularly regarding security and the key
>information block,  here is my take on Meta-data.
>
>*  DARPA is tying to morph Bundling into a secure content distribution
>and caching system.  I can encrypted different meta-data blocks with
>different keys for different class users.  I also can give great detail
>of the contents in a meta-data block destined for a secure gateway.
>
>Link the complexity of the bundle security protocol (or whatever it will
>eventually be called - security extension blocks) and the meta-data
>blocks and this all falls together.
>
>Bundles will be stored (if appropriate) as well at transmitted.  The
>meta-data block will be search for content, not the bundle.  That will
>be securely stored with some other key.
>
>Key management will be interesting.
>
>
>/Will

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Mon, 30 Mar 2009 12:00:42 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] metadata block - 01

>From what I observed at Google and the conversations taking place regarding meta data and particularly regarding security and the key information block,  here is my take on Meta-data.

*  DARPA is tying to morph Bundling into a secure content distribution and caching system.  I can encrypted different meta-data blocks with different keys for different class users.  I also can give great detail of the contents in a meta-data block destined for a secure gateway.  

Link the complexity of the bundle security protocol (or whatever it will eventually be called - security extension blocks) and the meta-data blocks and this all falls together.

Bundles will be stored (if appropriate) as well at transmitted.  The meta-data block will be search for content, not the bundle.  That will be securely stored with some other key.

Key management will be interesting.

/Will

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Ignacio Solis
> Sent: Friday, March 27, 2009 12:38 PM
> To: dtn interest
> Subject: Re: [dtn-interest] metadata block - 01
> 
> I've been part of many meta-data discussions before and I 
> still don't get what we're trying to do. As time goes on what 
> I get is more questions. So, before I (or others) get more 
> confused, let me ask some of them.  Please respond what _you_ 
> think is the direction we should be going.  Some of the 
> answers might seem obvious, I understand. And some of them 
> might be "policy" dependent, I understand that too.
> 
> 
> Who can add a meta-data block? Sender? Intermediate node?
> 
> Who can remove a meta-data block? Is it removable at all?
> 
> Who can view a meta data block?
> 
> Who will 'process' a meta-data block?
> 
> Is a DTN router required to understand a meta-data block? 
> What if it doesn't?
> 
>  From the discussions, we will have multiple types of 
> meta-data (ontologies, name spaces, etc). Does this mean some 
> might be pre-defined, some might be by convention, some might 
> be user defined?
> 
> If we have user defined meta-data, does this mean we need to 
> have a plug-in/module system at the DTN router level to add 
> the functionality to parse these meta-data blocks?
> 
> Can the meta-data block be used for:
> - adding keywords?
> - adding a list of allowed users?
> - adding a DRM scheme?
> - adding a thumbnail?
> - adding an icon?
> - adding publisher information?
> - adding a business card?
> - adding a color histogram?
> - adding a gps coordinate?
> - adding a sender military rank?
> - adding a DTN QoS priority level?
> - adding a link to a separate bundle?
> - adding the singer, album, track name and number of a song?
> - adding a cumulative cost for sending this bundle?
> - adding network debugging information?
> 
> The reason I ask this is because sometimes it seems to me 
> that we are blurring the lines between application level 
> meta-data and network level meta-data. Who knows, maybe that 
> is the goal (Cross layer design?).
> 
> What is the difference between sending 1 bundle with payload 
> and meta-data  OR sending 2 bundles, one with payload and the 
> other with the "meta-data" in the payload?
> 
> Lets say 1 bundle payload+meta-data needs to be 
> sent-processed together. If the meta-data needs a 
> plugin/module to be understood, this means we need a 
> customized DTN router.  IF we had a customized DTN router, 
> couldn't we just use the 2 bundle version then? All we would 
> need is some way to associate the
> 2 bundles together. One disadvantage to this is that a 
> "non-customized" DTN router might not understand the 
> association between the 2 bundles without making 
> understanding the association mandatory. (I understand that 
> this might just seem like a meta-data block in disguise)
> 
> 
> Alright, enough rambling for now, here's my real questions:
> 
> What are the differences between having a subset of nodes 
> understanding meta-data blocks of a certain type (via these 
> addons/modules/plugins) and running an "overlay" of 
> applications on those same nodes and transmit everything in 
> the payload?
> 
> Storage handling? Cleaner design? Lower overhead?
> 
> If I'm a new developer, and want to write something for DTN, 
> why use the router API vs the application API?
> 
> I think we will need some concrete use cases to answer some 
> of these questions.
> 
> I'm sorry I had to leave the meeting Thursday, would have 
> loved to stayed and discussed there.
> 
> Cheers,
> 
> Nacho
> 
> 
> PS. Finally, can't some of the things we want to use 
> meta-data blocks for be solved by a good naming scheme? or 
> even the bundle-in-bundle?
> 
> 
> Stephen Farrell wrote:
> > So a related, but different, question.
> > 
> > In Mountain View when we discussed this there seemed to be two
> > fairly different purposes that folks had in mind when talking
> > about this.
> > 
> > Susan and some others, (who've written this I-D) were talking
> > about using the extension block to pass around routing information
> > of some sort. I think the main example related to security
> > labels, so that some bundles can be routed only on appropriate
> > "secure" paths. So that meta-data, while associated with the
> > content, seems to be intended for routers and/or forwarders.
> > 
> > Kevin and a couple of others (I think) seemed to be talking
> > more about content-distribution. I think the example there that
> > doesn't fit with the above might be meta-data that identifies
> > the bundle payload in a fine-grained manner for applications.
> > 
> > Do we think the same extension block would/should be used for
> > both purposes? (Assuming we think they differ.)
> > 
> > S.
> > 
> > Armando Caro wrote:
> >> Peter Lovell wrote:
> >>> There is NO mechanism by which any block other than the 
> payload can be
> >>> fragmented.
> >>>
> >>> None, at all, in any way.
> >> Yes, I realize that.. And that was my point.
> >>
> >>> Path MTU is not relevant to dtn. That's entirely a CL 
> issue. It's up to
> >>> the CL to determine how to transport the bundle over the 
> next-hop and
> >>> dtn cares little (although more than zero) about that.
> >>  >
> >>> To take a cue from RFC1149, one could print it, employ 
> aerial conveyance
> >>> to the next node, scan it there and send it on its way. 
> The only MTU
> >>> issue is the size allowable for the aerial conveyance, 
> which is defined
> >>> by rfc as being variable. If that is too restrictive then 
> the CL might
> >>> send two or more parts by separate conveyance, 
> reassembling the stack
> >>> before the scan process. Higher bandwidth could probably 
> be obtained by
> >>> writing to a micro SD card rather than the print/scan 
> scheme, but the
> >>> effect is the same.
> >>>
> >>> So there is no sense in which control overhead crowds out 
> the payload,
> >>> or other blocks. The space available is quite large and 
> not constrained
> >>> by path MTU, unless a dtn implementation should choose to be so
> >>> constrained (and I would hope not).
> >> I would argue that putting the burden on the CL is more 
> restrictive, not 
> >> less. If you let bundles grow arbitrarily large, each 
> hop's CL may be 
> >> forced to reassemble before the bundle can be forwarded. That's 
> >> inefficient, especially for DTNs (when the D=Disruption). 
> The bundles 
> >> have a notion of lifetime, not the CL-specific fragments.
> >>
> >> Suppose a bundle's non-payload blocks grow so large, that 
> a CL needs to 
> >> fragment the bundle to forward it to the next hop. Now 
> suppose that the 
> >> CL successfully sends all but one fragment to the next hop 
> right before 
> >> the link goes down. The receiving CL cannot do anything with the 
> >> fragments. This means that when the link comes back up, 
> the sending CL 
> >> needs to retransmit all the fragments again. This could be 
> a problem for 
> >> flaky links with small MTUs relative to the size of the bundles.
> >>
> >> The CL could do something smarter and try to hold onto the 
> fragments, 
> >> but then the CL would need to do DTN itself.
> >>
> >> I don't know what the right solution is. Clearly, we don't 
> want to limit 
> >> the flexibility of the control blocks, but at the same 
> time, I think we 
> >> do need some provision of what is reasonable use/size of 
> these blocks 
> >> that are not fragmentable.
> >>
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Eiko Yoneki" <[email-masked]>
To: <[email-masked]>
Date: Mon, 30 Mar 2009 09:57:33 +0100
Organization: University of Cambridge
Sender: "E. Yoneki" <[email-masked]>
Subject: [dtn-interest] [deadline extension ExtremeCom] Extreme Workshop on Communication - The Midnight Sun Expedition
Reply-To: [email-masked]

[Our apologies if you receive multiple copies of this message.]

New submission deadline: April 30, 2009 
ExtremeCom 2009 - http://www.extremecom.org  

Call for Papers and Demos for 1st Extreme Workshop on Communication - The
Midnight Sun Expedition

The Extreme Workshop on Communication (ExtremeCom) intends to bring together
researchers and practitioners in areas related to delay tolerant networks
and other networking paradigms for rural and remote areas, in order to gain
experience and insight into the challenges that such environments pose for
the network and the users.

We aim to do this through real-life experience in the Arctic Circle region.
The Padjelanta national park in Laponia, Sweden is a UNESCO World Heritage
site, and the home of the Saami population of semi-nomadic reindeer herders.
Due to the lack of infrastructure in this area, a DTN-based networking
system for the area has been developed by the SNC and N4C projects. During
the summer of 2009, the fourth summer of deployment and testing for this
system will take place, which makes this a unique opportunity to experience
a real deployment of a DTN system.

The workshop will start with a 5 day field trip into the mountain regions
where the DTN system is deployed. During this time, participants will be
given the opportunity to hike along the trails in the mountains and visit
the Saami settlements to meet the local population and users of the system.
Not only will this give a better idea of both the technical and user
requirements of such a system, but it will also give many opportunities for
informal research discussions between the participants. Participants that
have their own software for scenarios like this will also, to as great an
extent as possible, be encouraged to test and demonstrate it within this
environment. (We are currently planning the mountain-based part of the
workshop together with the local population, and some details are subject to
change.) Upon reaching the end of the hike, there will be two days of paper
presentations and demos in a more traditional conference venue. Focus will
still be on informal research discussions, with the hope that the field
experience will give participants the ability to discuss the topics in a new
light.

Participants should submit 2-page position papers about ideas and visions
about the topics of the workshop or demo proposals to be shown during the
workshop. Visionary and thought-provoking papers that are likely to generate
much discussion during the workshop are especially solicited. The aim of the
workshop is to maintain an informal environment, where new research ideas
can be discussed and developed.

Topics for the workshop include, but are not limited to:

* Testbeds for large-scale sustainable testing of DTN systems
* Real deployments of networks in extreme environments
* Business and service models for networks in rural, remote, and other
challenging environments
* User experience research
* Delay tolerant networking
* Low-power and intermittent-power protocols
* Mechanisms for emergency and urgent communications
* Networked applications and services

Due to logistics and the need to conduct the workshop in harmony with the
local population and the environment, the number of participants will be
limited. Priority will be given to authors of papers.

Important dates
---------------
Workshop dates: August 8-14, 2009
Submission deadline: April 30, 2009
Notification of acceptance: May 14, 2009
Registration deadline: May 28, 2009

Organizers
----------
General co-chairs:
Pan Hui, Deutsche Telekom Laboratories and TU Berlin, Germany
Anders Lindgren, Swedish Institute of Computer Science, Sweden

Local arrangements:
Karin Kuoljok, Tannak AB, Sweden
Anders Lindgren, Swedish Institute of Computer Science, Sweden
Susanne Spik, Tannak AB, Sweden
Maria Uden, Lule� University of Technology, Sweden

Publicity chair:
Eiko Yoneki, University of Cambridge, UK

Web chair:
Fehmi Ben Abdesslem, University of St. Andrews, UK

Technical Program Committee:
Bengt Ahlgren, Swedish Insitute of Computer Science
Kevin Almeroth, University of California Santa Barbara, USA
Elizabeth M. Belding, University of California Santa Barbara, USA
Elwyn Davies, Folly Consulting, UK
Nathan Eagle, MIT and Univ of Nairobi, Kenya
Kevin Fall, Intel Research Berkeley, USA
Stephen Farrell, Trinity College Dublin, Ireland
Tristan Henderson, University of St. Andrews, UK
David Johnson, CSIR, South Africa
Srinivasan Keshav, University of Waterloo, Canada

Steering Committee:
Jon Crowcroft, University of Cambridge, UK
Avri Doria, Lule� University of Technology, Sweden
Tristan Henderson, University of St. Andrews, UK
Pan Hui, Deutsche Telekom Laboratories and TU Berlin, Germany
Anders Lindgren, Swedish Institute of Computer Science, Sweden

Date: Sun, 29 Mar 2009 21:54:25 -0400
From: Marc Blanchet <[email-masked]>
To: Daniel Ellard <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Initial planning for the first Disconnectathon

1 a).  simpler, efficient, together with discussions on protocol.

marc.

Daniel Ellard a �crit :
> For those of you who did not attend the DTNRG meeting last
> week, one idea that was proposed (and received positively)
> was to have regular meetings where all the people writing
> BPAs, apps, and other DTN-related software could get
> together in the same room and do interoperability,
> compatibility, and other hands-on testing.
> 
> The basic idea is taken from the "Connectathons"
> (http://www.connectathon.org/) organized by the NFS
> community, and so the name "Disconnectathon" was proposed.
> (Don't like the name?  Propose a better one... on a
> different thread, please.  Let's plan it first.)
> 
> The first question is when to have the first one.  A
> proposal was to do it during the next IETF meeting, in
> Stockholm, at the end of July.  This isn't perfectly ideal
> for several reasons, however, most importantly the cost of
> having everyone attend IETF and travel to Stockholm.  A
> second proposal was to have two concurrent (and
> network-connected Disconnectathons--one in Stockholm, for
> IETF attendees, and the second in Boston, hosted by BBN.  A
> third idea is to schedule the Disconnectathon a week or two
> prior to the IETF meeting, to make it a preamble to the
> DTNRG and IETF meetings.  Again, BBN is happy to host the
> meeting, if Boston is a good location for everyone.
> 
> In any case, given the complicated logistics of planning
> something around the IETF (or during the height of summer
> vacation season) I think it makes sense to choose one of
> these approaches soon, and start nailing down dates.
> Therefore, if the idea of a Disconnectathon appeals to you,
> please send me your current best guess of:
> 
> 1.  Which schedule/site works best for you:
> 
> 	a)  At and during the IETF meeting
> 
> 	b)  Split between BBN and the IETF meeting
> 
> 	c)  A week or two beforehand, at BBN or elsewhere
> 
> 	d)  Some other option (please elaborate)
> 
> 2.  How many people you anticipate sending to your preferred
> choice.  If your preference is b), please provide numbers
> for each location.
> 
> 3.  Any suggestions you have.
> 
> Thanks,
> 	-Dan
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

Date: Fri, 27 Mar 2009 21:53:29 -0400
From: "Armando L. Caro, Jr." <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

I just wanted to say that I agree with Susan's response.

Also, I now see Susan's distinction of what metadata block would be used 
for. So in her view, control information that is purely for routing 
(such as the retrans block) should not be put into a metadata block.

Does that mean that routing specific needs should each be separately 
defined blocks instead of a "routing block" with different subtypes?

Armando

Symington, Susan F. wrote:
> Nacho,
> 
> My answers are interspersed below.  One short answer to your "real question" is that if you try to get metadata block-type functionality by implementing an overlay of applications, then a bundle has to be delivered to an application at every DTN node that it traverses. This means that a bundle can't be protected from its source to its final destination using DTN's end-to-end security services.
> 
> I have tried to answer all your questions below. 
> 
> -susan
> 
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Ignacio
>> Solis
>> Sent: Friday, March 27, 2009 12:38 PM
>> To: dtn interest
>> Subject: Re: [dtn-interest] metadata block - 01
>>
>> I've been part of many meta-data discussions before and I still don't
>> get what
>> we're trying to do. As time goes on what I get is more questions. So,
>> before I
>> (or others) get more confused, let me ask some of them.  Please respond
>> what
>> _you_ think is the direction we should be going.  Some of the answers
>> might
>> seem obvious, I understand. And some of them might be "policy"
>> dependent, I
>> understand that too.
>>
>>
>> Who can add a meta-data block? Sender? Intermediate node?
> 
> [Susan] Any dtn node that supports the metadata block, subject to local policy and the metadata type being used in the block. ("metadata type" is the term we are using for what used to be called "ontology")
> 
>> Who can remove a meta-data block? Is it removable at all?
>  
> [Susan] Any dtn node that supports the metadata block, subject to local policy and the metadata type being used in the block.
>> Who can view a meta data block?
>  
> [Susan] Any dtn node, but in order to be able to make sense of it, the node has to support both the metadata block and the metadata type being used in the block.
> 
>> Who will 'process' a meta-data block?
> 
> [Susan] Any dtn node, but in order to be able to process it correctly, the node has to support both the metadata block and the metadata type being used in the block.
>> Is a DTN router required to understand a meta-data block? What if it
>> doesn't?
> [Susan] If a dtn node receives a bundle with a metadata block and it doesn't support metadata blocks or it supports metadata blocks but it doesn't support the metadata type used in the block, or it supports the metadata type being used but the metadata itself is not well-formed, the node must process the bundle as if it cannot process the metadata block. (This means that the node must operate according to the settings of the Block Processing Control flags, including the "Delete bundle if block can't be processed" flag, the "Discard block if it can't be processed" flag, the "Block was forwarded without being processed" flag, etc.) 
>> From the discussions, we will have multiple types of meta-data
>> (ontologies,
>> name spaces, etc). Does this mean some might be pre-defined, some might
>> be by
>> convention, some might be user defined?
> 
> [Susan] I'm not sure I understand this question. All the metadata types have to be defined somehow in order to be interpreted correctly. In Mountain View, Kevin was advocating for using URIs as metadata. Use of URIs may be adequate for representing most or all metadata. However, it may not be the most efficient method for such encoding. Therefore, I would like to have a "URI" metadata type defined, but also have the possibility of using other metadata types, which would have to be defined, of course, and the metadata type ID would have to be registered, to ensure global uniqueness.
>> If we have user defined meta-data, does this mean we need to have a
>> plug-in/module system at the DTN router level to add the functionality
>> to
>> parse these meta-data blocks?
> 
> [Susan] The capability to parse and process the metadata of any given type must be present in a DTN node in order for that node to support that metadata type. The functionality can be built into an external router module.
>> Can the meta-data block be used for:
>> - adding keywords?
>> - adding a list of allowed users?
>> - adding a DRM scheme?
>> - adding a thumbnail?
>> - adding an icon?
>> - adding publisher information?
>> - adding a business card?
>> - adding a color histogram?
>> - adding a gps coordinate?
>> - adding a sender military rank?
>> - adding a DTN QoS priority level?
>> - adding a link to a separate bundle?
>> - adding the singer, album, track name and number of a song?
>> - adding a cumulative cost for sending this bundle?
>> - adding network debugging information?
>>
>> The reason I ask this is because sometimes it seems to me that we are
>> blurring
>> the lines between application level meta-data and network level meta-
>> data. Who
>> knows, maybe that is the goal (Cross layer design?).
> 
> [Susan] I see the "data" part of metadata as referring to payload data, not DTN network data. So metadata seems to me to be most appropriate for the case of carrying information about the payload. Even though it is information about the payload, it is used by dtn nodes to make network-level decisions such as whether they should store the bundle or how they should forward the bundle. I don't think the metadata block, for example, would be a good choice of how to carry previous hop EID information; previous hop EID information is not information about the payload. (That's why I think we need a separate Previous Hop block.) 
> 
>> What is the difference between sending 1 bundle with payload and meta-
>> data  OR
>> sending 2 bundles, one with payload and the other with the "meta-data"
>> in the
>> payload?
>>
>> Lets say 1 bundle payload+meta-data needs to be sent-processed together.
>> If
>> the meta-data needs a plugin/module to be understood, this means we need
>> a
>> customized DTN router.  IF we had a customized DTN router, couldn't we
>> just
>> use the 2 bundle version then? All we would need is some way to
>> associate the
>> 2 bundles together. One disadvantage to this is that a "non-customized"
>> DTN
>> router might not understand the association between the 2 bundles
>> without
>> making understanding the association mandatory. (I understand that this
>> might
>> just seem like a meta-data block in disguise)
> 
> [Susan] Another difference is that a dtn node wouldn't know how to process one bundle until/unless it receives its "pair" bundle. However, there is no guarantee it will even receive its "pair", unless you force that through routing. If all the information is intended to go together, and I believe it is in the case in which the metadata provides information regarding how to act on the bundle, then it seems sensible that all the information should be shipped together and not as two separate bundles. Suppose you don't trust a dtn node very much so you don't want to give it the ability to decrypt the payload in your bundle. However, you do want the node to be able to store the bundle and provide it to new subscribers if they express an interest in bundles with payloads that are about what your bundle is about. You can tag the bundle with metadata about the payload subject ("soccer"), encrypt the payload, and transmit it.  A dtn node that has no way of decrypting the payload can
 !
>  store it and, in response to future requests, provide it to new subscribers who are interested in soccer.
>>
>> Alright, enough rambling for now, here's my real questions:
>>
>> What are the differences between having a subset of nodes understanding
>> meta-data blocks of a certain type (via these addons/modules/plugins)
>> and
>> running an "overlay" of applications on those same nodes and transmit
>> everything in the payload?
>>
>> Storage handling? Cleaner design? Lower overhead?
>>
>> If I'm a new developer, and want to write something for DTN, why use the
>> router API vs the application API?
> 
> [Susan] Well, for one thing, if you are using the application API instead of the router API, then suppose you have three nodes in a network A--B--C, with a topology such that for a bundle to be sent from A to C, it has to go through node B. In the application API example, if I understand you correctly, the Bundle would be sent from A to B, delivered to an application at B, and then sent from B to C. In this case, it is not possible to take advantage of any end-to-end security services from A (the source) to C (the ultimate destination).  All transmissions in such a network overlay would have to be 1-hop transmissions.
> 
>> I think we will need some concrete use cases to answer some of these
>> questions.
>>
>> I'm sorry I had to leave the meeting Thursday, would have loved to
>> stayed and
>> discussed there.
>>
>> Cheers,
>>
>> Nacho
>>
>>
>> PS. Finally, can't some of the things we want to use meta-data blocks
>> for be
>> solved by a good naming scheme? or even the bundle-in-bundle?
> [Susan] Maybe. 
> 
> [Susan] -susan
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Fri, 27 Mar 2009 21:31:03 -0400
From: "Armando L. Caro, Jr." <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

Symington, Susan F. wrote:
> You ask, "Do we think the same extension block would/should be used for "both purposes?"  I don't understand what you consider to be the "other" purpose (other than the type of content-based distribution example I give above).

I don't know about Stephen's other purpose, but I can see the metadata 
block being used for general purpose routing as well. Metadata 
inserted/deleted/modified hop-by-hop can help routing algorithms make 
forwarding decisions.

Should there be two separate block types, one for content routing and 
one for general purpose routing?  I don't know. I don't have an opinion 
on that.

Armando

Date: Fri, 27 Mar 2009 21:25:10 -0400
From: "Armando L. Caro, Jr." <[email-masked]>
To: Hans Kruse <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

Hans Kruse wrote:
> Armando, take a look at LTP as an example of a CL that "knows" how to do 
> this.

I'll take a look.

> That includes a pretty good timer management to deal at least 
> with scheduled transmission times.

If that timer mgmt requires synchronized clocks across nodes, then it 
won't work well for many DTNs where the D=Disruption.

> The CL really is the right place to 
> do this, IMHO.

There are times when the CL might be the only place to do it. But I 
think it behooves us to avoid that when possible. Please see the example 
I put in the other email in this thread.

> That said, putting what really is content/payload data 
> into extension blocks is probably a bad idea;

I don't think anyone is talking about putting content/payload data into 
extension blocks, just metadata. Somewhat different, but it could be a 
slippery slope if we are not careful.

> keeping the bundle header 
> at a "reasonable" length should be the goal.

I agree about the goal. What's is reasonable is one question, and 
whether to enforce that in the block formats is the other question.

-Armando

Date: Fri, 27 Mar 2009 21:16:30 -0400
From: "Armando L. Caro, Jr." <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  metadata block - 01

Peter Lovell wrote:
> Ahhh. That makes a lot more sense. But only in a way.

Sorry for the confusion. I thought I was being clear, but I'll try to be 
more careful.

> The CL will often have to break up a bundle into smaller pieces to get
> it to the next hop, regardless of the size of the individual blocks. I
> refrain from saying "fragment" for this as that has specific dtn
> meaning, and it was that that was confusing.

Fragmentation is a general network term, and I was using it in that way. 
I'll use "fragments" to refer Bundle Fragments, and "pieces" to refer to 
the MTU sized chunks that a CL sends when a full bundle or bundle 
fragment doesn't fit in the MTU.

> I am not acquainted with the intricacies of CL but it seems that the
> breakup/reassembly is just "the way it is".

Yes, but that is good reason to attempt to prevent bloated control 
blocks. Also a good reason to allow control blocks to be fragmented, if 
the control info is only useful to the source and destination endpoints. 
(probably NOT the common case).

> I am not sure that one big
> block is any worse than lots of smaller blocks -- if the whole bundle
> exceeds the MTU of the underlying path then CL has to break into pieces.
> Is it any worse for a big block as opposed to a collection of smaller ones?

Yes. In a disruption prone environment, it is more useful to forward 
self-containing blocks when possible. Consider the following network 
topology of 4 nodes (A, B, C, D), where each link has the same MTU.

   B
  / \
A   D
  \ /
   C

Now consider Scenario 1 ("big block").

1a. Links A-B, B-D, and C-D are up. Link A-C is down.

1b. Node A has a bundle of size 2*MTU destined for Node D.

1c. Node A's BPA passes to its CL a bundle of size 2*MTU.

1d. Node A's CL breaks the bundle into 2 pieces of size MTU.

1e. Node A's CL successfully sends first piece to Node B.

1f. Link A-B goes down.

1g. Link A-C comes up.

1h. Since Node A didn't send the complete bundle to Node B, it tries 
sending the bundle to Node C. Node A's CL successfully sends the first 
piece to Node C.

1i. Link A-C goes down.

End result of Scenario 1: bundle never reaches the destination Node D.

Now consider Scenario 2 ("collection of smaller blocks"), which has the 
same link up/down events.

2a. Links A-B, B-D, and C-D are up. Link A-C is down.

2b. Node A has a bundle of size 2*MTU destined for Node D.

2c. Node A's BPA fragments the bundle into two bundle fragments, each of 
size MTU.

2d. Node A's BPA passes both bundle fragments to its CL.

2e. Node A's CL successfully sends Bundle Fragment 1 to Node B.

2f. Link A-B goes down. Meanwhile, Node B successfully forwards Bundle 
Fragment 1 to Node D.

2g. Link A-C comes up.

2h. Node A's CL successfully sends Bundle Fragment 2 to Node C.

2i. Link A-C goes down. Meanwhile, Node C successfully forwards Bundle 
Fragment 2 to Node D.

2j. Node D reassembles the complete bundle from Bundle Fragment 1 and 
Bundle Fragment 2.

End Result of Scenario 2: bundle successfully delivered to the 
destination Node D.

-Armando

From: Peter Lovell <[email-masked]>
To: Hans Kruse <[email-masked]>
Date: Fri, 27 Mar 2009 17:24:42 -0400
Cc: dtn interest <[email-masked]>
Subject: [dtn-interest] Re(2):  Re(2):  metadata block - 01

Ahhh. That makes a lot more sense. But only in a way.

The CL will often have to break up a bundle into smaller pieces to get
it to the next hop, regardless of the size of the individual blocks. I
refrain from saying "fragment" for this as that has specific dtn
meaning, and it was that that was confusing.

I am not acquainted with the intricacies of CL but it seems that the
breakup/reassembly is just "the way it is". I am not sure that one big
block is any worse than lots of smaller blocks -- if the whole bundle
exceeds the MTU of the underlying path then CL has to break into pieces.
Is it any worse for a big block as opposed to a collection of smaller ones?

Cheers.....Peter

On Fri, Mar 27, 2009, Hans Kruse <[email-masked]> wrote:

>Peter, I think the concern is about a bundle fragment with really
>large header blocks, which makes the bundle fragment so large that the
>CL has to do extensive fragmentation of its own (which would require
>re-assembly at the CL layer).
>
>On Mar 27, 2009, at 9:04 AM, Peter Lovell wrote:
>
>> On Thu, Mar 26, 2009, Armando Caro <[email-masked]> wrote:
>>
>>> I would argue that putting the burden on the CL is more
>>> restrictive, not
>>> less. If you let bundles grow arbitrarily large, each hop's CL may be
>>> forced to reassemble before the bundle can be forwarded. That's
>>> inefficient, especially for DTNs (when the D=Disruption). The bundles
>>> have a notion of lifetime, not the CL-specific fragments.
>>>
>>> Suppose a bundle's non-payload blocks grow so large, that a CL
>>> needs to
>>> fragment the bundle to forward it to the next hop. Now suppose that
>>> the
>>> CL successfully sends all but one fragment to the next hop right
>>> before
>>> the link goes down. The receiving CL cannot do anything with the
>>> fragments. This means that when the link comes back up, the sending
>>> CL
>>> needs to retransmit all the fragments again. This could be a
>>> problem for
>>> flaky links with small MTUs relative to the size of the bundles.
>>>
>>> The CL could do something smarter and try to hold onto the fragments,
>>> but then the CL would need to do DTN itself.
>>>
>>> I don't know what the right solution is. Clearly, we don't want to
>>> limit
>>> the flexibility of the control blocks, but at the same time, I
>>> think we
>>> do need some provision of what is reasonable use/size of these blocks
>>> that are not fragmentable.
>>
>>
>> Hi Armando,
>>
>> I think you misunderstand the fragmentation process.
>>
>> When a bundle is fragmented, the fragments become free-standing
>> bundles.
>> There is no reassembly required at the next hop. In fact, the various
>> fragments might take different paths and never meet again until
>> arrival
>> at the bundle-destination. A next-hop node *could* reassemble but
>> there's no requirement or expectation that it do so.
>>
>> So there's no need to "hold on" to the fragments anywhere -- the next
>> hop just sends each one on its way separately to the destination.
>>
>> Regards.....Peter
>>
>>
>> p.s.  this is why a gateway-to-gateway tunnel SHOULD change the
>> bundle-
>> dest to be the other end of the tunnel, and restore the original
>> bundle-
>> dest when it exits the tunnel. If it does not do this and some
>> fragments
>> take alternate paths to the bundle-dest the exit point cannot process
>> the pieces it has. The security-dest MUST reassemble in order to
>> decrypt.
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>Hans Kruse, Professor
>J. Warren McClure School of Information and Telecommunication Systems
>Adjunct Associate Professor of Electrical Engineering and Computer
>Science
>292 Lindley Hall, Ohio University, Athens, OH, 45701
>740-593-4891 voice, 740-593-4889 fax
>
>

From: "Symington, Susan F." <[email-masked]>
To: Ignacio Solis <[email-masked]>, dtn interest <[email-masked]>
Date: Fri, 27 Mar 2009 13:45:44 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] metadata block - 01

Nacho,

My answers are interspersed below.  One short answer to your "real question" is that if you try to get metadata block-type functionality by implementing an overlay of applications, then a bundle has to be delivered to an application at every DTN node that it traverses. This means that a bundle can't be protected from its source to its final destination using DTN's end-to-end security services.

I have tried to answer all your questions below. 

-susan

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Ignacio
>Solis
>Sent: Friday, March 27, 2009 12:38 PM
>To: dtn interest
>Subject: Re: [dtn-interest] metadata block - 01
>
>I've been part of many meta-data discussions before and I still don't
>get what
>we're trying to do. As time goes on what I get is more questions. So,
>before I
>(or others) get more confused, let me ask some of them.  Please respond
>what
>_you_ think is the direction we should be going.  Some of the answers
>might
>seem obvious, I understand. And some of them might be "policy"
>dependent, I
>understand that too.
>
>
>Who can add a meta-data block? Sender? Intermediate node?

[Susan] Any dtn node that supports the metadata block, subject to local policy and the metadata type being used in the block. ("metadata type" is the term we are using for what used to be called "ontology")

>
>Who can remove a meta-data block? Is it removable at all?
 
[Susan] Any dtn node that supports the metadata block, subject to local policy and the metadata type being used in the block.
>
>Who can view a meta data block?
 
[Susan] Any dtn node, but in order to be able to make sense of it, the node has to support both the metadata block and the metadata type being used in the block.

>
>Who will 'process' a meta-data block?

[Susan] Any dtn node, but in order to be able to process it correctly, the node has to support both the metadata block and the metadata type being used in the block.
>
>Is a DTN router required to understand a meta-data block? What if it
>doesn't?
[Susan] If a dtn node receives a bundle with a metadata block and it doesn't support metadata blocks or it supports metadata blocks but it doesn't support the metadata type used in the block, or it supports the metadata type being used but the metadata itself is not well-formed, the node must process the bundle as if it cannot process the metadata block. (This means that the node must operate according to the settings of the Block Processing Control flags, including the "Delete bundle if block can't be processed" flag, the "Discard block if it can't be processed" flag, the "Block was forwarded without being processed" flag, etc.) 
>
> From the discussions, we will have multiple types of meta-data
>(ontologies,
>name spaces, etc). Does this mean some might be pre-defined, some might
>be by
>convention, some might be user defined?

[Susan] I'm not sure I understand this question. All the metadata types have to be defined somehow in order to be interpreted correctly. In Mountain View, Kevin was advocating for using URIs as metadata. Use of URIs may be adequate for representing most or all metadata. However, it may not be the most efficient method for such encoding. Therefore, I would like to have a "URI" metadata type defined, but also have the possibility of using other metadata types, which would have to be defined, of course, and the metadata type ID would have to be registered, to ensure global uniqueness.
>
>If we have user defined meta-data, does this mean we need to have a
>plug-in/module system at the DTN router level to add the functionality
>to
>parse these meta-data blocks?

[Susan] The capability to parse and process the metadata of any given type must be present in a DTN node in order for that node to support that metadata type. The functionality can be built into an external router module.
>
>Can the meta-data block be used for:
>- adding keywords?
>- adding a list of allowed users?
>- adding a DRM scheme?
>- adding a thumbnail?
>- adding an icon?
>- adding publisher information?
>- adding a business card?
>- adding a color histogram?
>- adding a gps coordinate?
>- adding a sender military rank?
>- adding a DTN QoS priority level?
>- adding a link to a separate bundle?
>- adding the singer, album, track name and number of a song?
>- adding a cumulative cost for sending this bundle?
>- adding network debugging information?
>
>The reason I ask this is because sometimes it seems to me that we are
>blurring
>the lines between application level meta-data and network level meta-
>data. Who
>knows, maybe that is the goal (Cross layer design?).

[Susan] I see the "data" part of metadata as referring to payload data, not DTN network data. So metadata seems to me to be most appropriate for the case of carrying information about the payload. Even though it is information about the payload, it is used by dtn nodes to make network-level decisions such as whether they should store the bundle or how they should forward the bundle. I don't think the metadata block, for example, would be a good choice of how to carry previous hop EID information; previous hop EID information is not information about the payload. (That's why I think we need a separate Previous Hop block.) 

>
>What is the difference between sending 1 bundle with payload and meta-
>data  OR
>sending 2 bundles, one with payload and the other with the "meta-data"
>in the
>payload?
>
>Lets say 1 bundle payload+meta-data needs to be sent-processed together.
>If
>the meta-data needs a plugin/module to be understood, this means we need
>a
>customized DTN router.  IF we had a customized DTN router, couldn't we
>just
>use the 2 bundle version then? All we would need is some way to
>associate the
>2 bundles together. One disadvantage to this is that a "non-customized"
>DTN
>router might not understand the association between the 2 bundles
>without
>making understanding the association mandatory. (I understand that this
>might
>just seem like a meta-data block in disguise)

[Susan] Another difference is that a dtn node wouldn't know how to process one bundle until/unless it receives its "pair" bundle. However, there is no guarantee it will even receive its "pair", unless you force that through routing. If all the information is intended to go together, and I believe it is in the case in which the metadata provides information regarding how to act on the bundle, then it seems sensible that all the information should be shipped together and not as two separate bundles. Suppose you don't trust a dtn node very much so you don't want to give it the ability to decrypt the payload in your bundle. However, you do want the node to be able to store the bundle and provide it to new subscribers if they express an interest in bundles with payloads that are about what your bundle is about. You can tag the bundle with metadata about the payload subject ("soccer"), encrypt the payload, and transmit it.  A dtn node that has no way of decrypting the payload can store it and, in response to future requests, provide it to new subscribers who are interested in soccer.
>
>
>Alright, enough rambling for now, here's my real questions:
>
>What are the differences between having a subset of nodes understanding
>meta-data blocks of a certain type (via these addons/modules/plugins)
>and
>running an "overlay" of applications on those same nodes and transmit
>everything in the payload?
>
>Storage handling? Cleaner design? Lower overhead?
>
>If I'm a new developer, and want to write something for DTN, why use the
>router API vs the application API?

[Susan] Well, for one thing, if you are using the application API instead of the router API, then suppose you have three nodes in a network A--B--C, with a topology such that for a bundle to be sent from A to C, it has to go through node B. In the application API example, if I understand you correctly, the Bundle would be sent from A to B, delivered to an application at B, and then sent from B to C. In this case, it is not possible to take advantage of any end-to-end security services from A (the source) to C (the ultimate destination).  All transmissions in such a network overlay would have to be 1-hop transmissions.

>
>I think we will need some concrete use cases to answer some of these
>questions.
>
>I'm sorry I had to leave the meeting Thursday, would have loved to
>stayed and
>discussed there.
>
>Cheers,
>
>Nacho
>
>
>PS. Finally, can't some of the things we want to use meta-data blocks
>for be
>solved by a good naming scheme? or even the bundle-in-bundle?
[Susan] Maybe. 

[Susan] -susan

Date: Fri, 27 Mar 2009 09:38:04 PDT
From: Ignacio Solis <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

I've been part of many meta-data discussions before and I still don't get what 
we're trying to do. As time goes on what I get is more questions. So, before I 
(or others) get more confused, let me ask some of them.  Please respond what 
_you_ think is the direction we should be going.  Some of the answers might 
seem obvious, I understand. And some of them might be "policy" dependent, I 
understand that too.

Who can add a meta-data block? Sender? Intermediate node?

Who can remove a meta-data block? Is it removable at all?

Who can view a meta data block?

Who will 'process' a meta-data block?

Is a DTN router required to understand a meta-data block? What if it doesn't?

 From the discussions, we will have multiple types of meta-data (ontologies, 
name spaces, etc). Does this mean some might be pre-defined, some might be by 
convention, some might be user defined?

If we have user defined meta-data, does this mean we need to have a 
plug-in/module system at the DTN router level to add the functionality to 
parse these meta-data blocks?

Can the meta-data block be used for:
- adding keywords?
- adding a list of allowed users?
- adding a DRM scheme?
- adding a thumbnail?
- adding an icon?
- adding publisher information?
- adding a business card?
- adding a color histogram?
- adding a gps coordinate?
- adding a sender military rank?
- adding a DTN QoS priority level?
- adding a link to a separate bundle?
- adding the singer, album, track name and number of a song?
- adding a cumulative cost for sending this bundle?
- adding network debugging information?

The reason I ask this is because sometimes it seems to me that we are blurring 
the lines between application level meta-data and network level meta-data. Who 
knows, maybe that is the goal (Cross layer design?).

What is the difference between sending 1 bundle with payload and meta-data  OR 
sending 2 bundles, one with payload and the other with the "meta-data" in the 
payload?

Lets say 1 bundle payload+meta-data needs to be sent-processed together. If 
the meta-data needs a plugin/module to be understood, this means we need a 
customized DTN router.  IF we had a customized DTN router, couldn't we just 
use the 2 bundle version then? All we would need is some way to associate the 
2 bundles together. One disadvantage to this is that a "non-customized" DTN 
router might not understand the association between the 2 bundles without 
making understanding the association mandatory. (I understand that this might 
just seem like a meta-data block in disguise)

Alright, enough rambling for now, here's my real questions:

What are the differences between having a subset of nodes understanding 
meta-data blocks of a certain type (via these addons/modules/plugins) and 
running an "overlay" of applications on those same nodes and transmit 
everything in the payload?

Storage handling? Cleaner design? Lower overhead?

If I'm a new developer, and want to write something for DTN, why use the 
router API vs the application API?

I think we will need some concrete use cases to answer some of these questions.

I'm sorry I had to leave the meeting Thursday, would have loved to stayed and 
discussed there.

Cheers,

Nacho

PS. Finally, can't some of the things we want to use meta-data blocks for be 
solved by a good naming scheme? or even the bundle-in-bundle?

Stephen Farrell wrote:
> So a related, but different, question.
> 
> In Mountain View when we discussed this there seemed to be two
> fairly different purposes that folks had in mind when talking
> about this.
> 
> Susan and some others, (who've written this I-D) were talking
> about using the extension block to pass around routing information
> of some sort. I think the main example related to security
> labels, so that some bundles can be routed only on appropriate
> "secure" paths. So that meta-data, while associated with the
> content, seems to be intended for routers and/or forwarders.
> 
> Kevin and a couple of others (I think) seemed to be talking
> more about content-distribution. I think the example there that
> doesn't fit with the above might be meta-data that identifies
> the bundle payload in a fine-grained manner for applications.
> 
> Do we think the same extension block would/should be used for
> both purposes? (Assuming we think they differ.)
> 
> S.
> 
> Armando Caro wrote:
>> Peter Lovell wrote:
>>> There is NO mechanism by which any block other than the payload can be
>>> fragmented.
>>>
>>> None, at all, in any way.
>> Yes, I realize that.. And that was my point.
>>
>>> Path MTU is not relevant to dtn. That's entirely a CL issue. It's up to
>>> the CL to determine how to transport the bundle over the next-hop and
>>> dtn cares little (although more than zero) about that.
>>  >
>>> To take a cue from RFC1149, one could print it, employ aerial conveyance
>>> to the next node, scan it there and send it on its way. The only MTU
>>> issue is the size allowable for the aerial conveyance, which is defined
>>> by rfc as being variable. If that is too restrictive then the CL might
>>> send two or more parts by separate conveyance, reassembling the stack
>>> before the scan process. Higher bandwidth could probably be obtained by
>>> writing to a micro SD card rather than the print/scan scheme, but the
>>> effect is the same.
>>>
>>> So there is no sense in which control overhead crowds out the payload,
>>> or other blocks. The space available is quite large and not constrained
>>> by path MTU, unless a dtn implementation should choose to be so
>>> constrained (and I would hope not).
>> I would argue that putting the burden on the CL is more restrictive, not 
>> less. If you let bundles grow arbitrarily large, each hop's CL may be 
>> forced to reassemble before the bundle can be forwarded. That's 
>> inefficient, especially for DTNs (when the D=Disruption). The bundles 
>> have a notion of lifetime, not the CL-specific fragments.
>>
>> Suppose a bundle's non-payload blocks grow so large, that a CL needs to 
>> fragment the bundle to forward it to the next hop. Now suppose that the 
>> CL successfully sends all but one fragment to the next hop right before 
>> the link goes down. The receiving CL cannot do anything with the 
>> fragments. This means that when the link comes back up, the sending CL 
>> needs to retransmit all the fragments again. This could be a problem for 
>> flaky links with small MTUs relative to the size of the bundles.
>>
>> The CL could do something smarter and try to hold onto the fragments, 
>> but then the CL would need to do DTN itself.
>>
>> I don't know what the right solution is. Clearly, we don't want to limit 
>> the flexibility of the control blocks, but at the same time, I think we 
>> do need some provision of what is reasonable use/size of these blocks 
>> that are not fragmentable.
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Symington, Susan F." <[email-masked]>
To: Stephen Farrell <[email-masked]>, dtn interest <[email-masked]>
Date: Fri, 27 Mar 2009 10:55:51 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] metadata block - 01

Stephen,

I'm not sure I understand your question. Actually, I'm sure I don't understand your question, but I'm going to respond anyway.

I believe it was Kevin who brought up at the Mountain View meeting the idea of putting security labels in metadata and having them somehow "bound" to the payload. That wasn't me.

I envision the metadata to be used for content distribution, where the metadata might contain a keyword that describes the subject that the payload is about, for example. Although this metadata may contain information about the payload, I see it as intended for DTN "routers and forwarders". In DTN, the "routers and forwarders" are also storage caches. So, the metadata in a bundle may be used by the dtn node to determine whether or not it should store the bundle in its cache. Alternatively, the metadata in some bundle may be used to indicate to the dtn node that it should search it's cache for certain bundles (identified by their metadata) that it should forward somewhere (this somewhere possibly also being provided as part of the metadata). This is metadata that happens to be "about" the payload, but that is intended for use by routers and forwarders. 

You ask, "Do we think the same extension block would/should be used for "both purposes?"  I don't understand what you consider to be the "other" purpose (other than the type of content-based distribution example I give above).

-susan

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Stephen
>Farrell
>Sent: Thursday, March 26, 2009 10:07 PM
>To: dtn interest
>Subject: Re: [dtn-interest] metadata block - 01
>
>
>So a related, but different, question.
>
>In Mountain View when we discussed this there seemed to be two
>fairly different purposes that folks had in mind when talking
>about this.
>
>Susan and some others, (who've written this I-D) were talking
>about using the extension block to pass around routing information
>of some sort. I think the main example related to security
>labels, so that some bundles can be routed only on appropriate
>"secure" paths. So that meta-data, while associated with the
>content, seems to be intended for routers and/or forwarders.
>
>Kevin and a couple of others (I think) seemed to be talking
>more about content-distribution. I think the example there that
>doesn't fit with the above might be meta-data that identifies
>the bundle payload in a fine-grained manner for applications.
>
>Do we think the same extension block would/should be used for
>both purposes? (Assuming we think they differ.)
>
>S.
>
>Armando Caro wrote:
>> Peter Lovell wrote:
>>> There is NO mechanism by which any block other than the payload can
>be
>>> fragmented.
>>>
>>> None, at all, in any way.
>>
>> Yes, I realize that.. And that was my point.
>>
>>> Path MTU is not relevant to dtn. That's entirely a CL issue. It's up
>to
>>> the CL to determine how to transport the bundle over the next-hop and
>>> dtn cares little (although more than zero) about that.
>>  >
>>> To take a cue from RFC1149, one could print it, employ aerial
>conveyance
>>> to the next node, scan it there and send it on its way. The only MTU
>>> issue is the size allowable for the aerial conveyance, which is
>defined
>>> by rfc as being variable. If that is too restrictive then the CL
>might
>>> send two or more parts by separate conveyance, reassembling the stack
>>> before the scan process. Higher bandwidth could probably be obtained
>by
>>> writing to a micro SD card rather than the print/scan scheme, but the
>>> effect is the same.
>>>
>>> So there is no sense in which control overhead crowds out the
>payload,
>>> or other blocks. The space available is quite large and not
>constrained
>>> by path MTU, unless a dtn implementation should choose to be so
>>> constrained (and I would hope not).
>>
>> I would argue that putting the burden on the CL is more restrictive,
>not
>> less. If you let bundles grow arbitrarily large, each hop's CL may be
>> forced to reassemble before the bundle can be forwarded. That's
>> inefficient, especially for DTNs (when the D=Disruption). The bundles
>> have a notion of lifetime, not the CL-specific fragments.
>>
>> Suppose a bundle's non-payload blocks grow so large, that a CL needs
>to
>> fragment the bundle to forward it to the next hop. Now suppose that
>the
>> CL successfully sends all but one fragment to the next hop right
>before
>> the link goes down. The receiving CL cannot do anything with the
>> fragments. This means that when the link comes back up, the sending CL
>> needs to retransmit all the fragments again. This could be a problem
>for
>> flaky links with small MTUs relative to the size of the bundles.
>>
>> The CL could do something smarter and try to hold onto the fragments,
>> but then the CL would need to do DTN itself.
>>
>> I don't know what the right solution is. Clearly, we don't want to
>limit
>> the flexibility of the control blocks, but at the same time, I think
>we
>> do need some provision of what is reasonable use/size of these blocks
>> that are not fragmentable.
>>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Hans Kruse <[email-masked]>
To: Peter Lovell <[email-masked]>
Date: Fri, 27 Mar 2009 09:14:15 -0400
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  metadata block - 01

Peter, I think the concern is about a bundle fragment with really  
large header blocks, which makes the bundle fragment so large that the  
CL has to do extensive fragmentation of its own (which would require  
re-assembly at the CL layer).

On Mar 27, 2009, at 9:04 AM, Peter Lovell wrote:

> On Thu, Mar 26, 2009, Armando Caro <[email-masked]> wrote:
>
>> I would argue that putting the burden on the CL is more  
>> restrictive, not
>> less. If you let bundles grow arbitrarily large, each hop's CL may be
>> forced to reassemble before the bundle can be forwarded. That's
>> inefficient, especially for DTNs (when the D=Disruption). The bundles
>> have a notion of lifetime, not the CL-specific fragments.
>>
>> Suppose a bundle's non-payload blocks grow so large, that a CL  
>> needs to
>> fragment the bundle to forward it to the next hop. Now suppose that  
>> the
>> CL successfully sends all but one fragment to the next hop right  
>> before
>> the link goes down. The receiving CL cannot do anything with the
>> fragments. This means that when the link comes back up, the sending  
>> CL
>> needs to retransmit all the fragments again. This could be a  
>> problem for
>> flaky links with small MTUs relative to the size of the bundles.
>>
>> The CL could do something smarter and try to hold onto the fragments,
>> but then the CL would need to do DTN itself.
>>
>> I don't know what the right solution is. Clearly, we don't want to  
>> limit
>> the flexibility of the control blocks, but at the same time, I  
>> think we
>> do need some provision of what is reasonable use/size of these blocks
>> that are not fragmentable.
>
>
> Hi Armando,
>
> I think you misunderstand the fragmentation process.
>
> When a bundle is fragmented, the fragments become free-standing  
> bundles.
> There is no reassembly required at the next hop. In fact, the various
> fragments might take different paths and never meet again until  
> arrival
> at the bundle-destination. A next-hop node *could* reassemble but
> there's no requirement or expectation that it do so.
>
> So there's no need to "hold on" to the fragments anywhere -- the next
> hop just sends each one on its way separately to the destination.
>
> Regards.....Peter
>
>
> p.s.  this is why a gateway-to-gateway tunnel SHOULD change the  
> bundle-
> dest to be the other end of the tunnel, and restore the original  
> bundle-
> dest when it exits the tunnel. If it does not do this and some  
> fragments
> take alternate paths to the bundle-dest the exit point cannot process
> the pieces it has. The security-dest MUST reassemble in order to  
> decrypt.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

From: Hans Kruse <[email-masked]>
To: Armando Caro <[email-masked]>
Date: Fri, 27 Mar 2009 09:12:27 -0400
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

Armando, take a look at LTP as an example of a CL that "knows" how to  
do this.   That includes a pretty good timer management to deal at  
least with scheduled transmission times.  The CL really is the right  
place to do this, IMHO.  That said, putting what really is content/ 
payload data into extension blocks is probably a bad idea; keeping the  
bundle header at a "reasonable" length should be the goal.

On Mar 26, 2009, at 9:33 PM, Armando Caro wrote:

> I would argue that putting the burden on the CL is more restrictive,  
> not
> less. If you let bundles grow arbitrarily large, each hop's CL may be
> forced to reassemble before the bundle can be forwarded. That's
> inefficient, especially for DTNs (when the D=Disruption). The bundles
> have a notion of lifetime, not the CL-specific fragments.
>
> Suppose a bundle's non-payload blocks grow so large, that a CL needs  
> to
> fragment the bundle to forward it to the next hop. Now suppose that  
> the
> CL successfully sends all but one fragment to the next hop right  
> before
> the link goes down. The receiving CL cannot do anything with the
> fragments. This means that when the link comes back up, the sending CL
> needs to retransmit all the fragments again. This could be a problem  
> for
> flaky links with small MTUs relative to the size of the bundles.
>
> The CL could do something smarter and try to hold onto the fragments,
> but then the CL would need to do DTN itself.
>
> I don't know what the right solution is. Clearly, we don't want to  
> limit
> the flexibility of the control blocks, but at the same time, I think  
> we
> do need some provision of what is reasonable use/size of these blocks
> that are not fragmentable.
>
> -- 
> Armando
>

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

From: Peter Lovell <[email-masked]>
To: Armando Caro <[email-masked]>
Date: Fri, 27 Mar 2009 09:04:51 -0400
Cc: dtn interest <[email-masked]>
Subject: [dtn-interest] Re(2):  metadata block - 01

On Thu, Mar 26, 2009, Armando Caro <[email-masked]> wrote:

>I would argue that putting the burden on the CL is more restrictive, not 
>less. If you let bundles grow arbitrarily large, each hop's CL may be 
>forced to reassemble before the bundle can be forwarded. That's 
>inefficient, especially for DTNs (when the D=Disruption). The bundles 
>have a notion of lifetime, not the CL-specific fragments.
>
>Suppose a bundle's non-payload blocks grow so large, that a CL needs to 
>fragment the bundle to forward it to the next hop. Now suppose that the 
>CL successfully sends all but one fragment to the next hop right before 
>the link goes down. The receiving CL cannot do anything with the 
>fragments. This means that when the link comes back up, the sending CL 
>needs to retransmit all the fragments again. This could be a problem for 
>flaky links with small MTUs relative to the size of the bundles.
>
>The CL could do something smarter and try to hold onto the fragments, 
>but then the CL would need to do DTN itself.
>
>I don't know what the right solution is. Clearly, we don't want to limit 
>the flexibility of the control blocks, but at the same time, I think we 
>do need some provision of what is reasonable use/size of these blocks 
>that are not fragmentable.

Hi Armando,

I think you misunderstand the fragmentation process.

When a bundle is fragmented, the fragments become free-standing bundles.
There is no reassembly required at the next hop. In fact, the various
fragments might take different paths and never meet again until arrival
at the bundle-destination. A next-hop node *could* reassemble but
there's no requirement or expectation that it do so.

So there's no need to "hold on" to the fragments anywhere -- the next
hop just sends each one on its way separately to the destination.

Regards.....Peter

p.s.  this is why a gateway-to-gateway tunnel SHOULD change the bundle-
dest to be the other end of the tunnel, and restore the original bundle-
dest when it exits the tunnel. If it does not do this and some fragments
take alternate paths to the bundle-dest the exit point cannot process
the pieces it has. The security-dest MUST reassemble in order to decrypt.

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, dtn interest <[email-masked]>
Date: Fri, 27 Mar 2009 07:39:34 -0400
Subject: [dtn-interest] Re(2):  metadata block - 01

On Fri, Mar 27, 2009, Stephen Farrell <[email-masked]> wrote:

>
>So a related, but different, question.
>
>In Mountain View when we discussed this there seemed to be two
>fairly different purposes that folks had in mind when talking
>about this.
>
>Susan and some others, (who've written this I-D) were talking
>about using the extension block to pass around routing information
>of some sort. I think the main example related to security
>labels, so that some bundles can be routed only on appropriate
>"secure" paths. So that meta-data, while associated with the
>content, seems to be intended for routers and/or forwarders.
>
>Kevin and a couple of others (I think) seemed to be talking
>more about content-distribution. I think the example there that
>doesn't fit with the above might be meta-data that identifies
>the bundle payload in a fine-grained manner for applications.
>
>Do we think the same extension block would/should be used for
>both purposes? (Assuming we think they differ.)
>
>S.

Hi Stephen,

I'm certain that metadata blocks will be used to assist content-
distribution, such as by providing terms upon which to search or index
without necessarily providing access to the payload data.

I think that the "security label" routing scenario will probably happen
but this could also be done using another block type specified for such
purposes. I've not heard any suggestion or proposal for this but it
wouldn't surprise me. Some routers are lightweight devices and they may
perform better if the information is more easily accessible rather than
digging through general-purpose blocks.

Cheers.....Peter

Date: Fri, 27 Mar 2009 02:06:47 +0000
From: Stephen Farrell <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

So a related, but different, question.

In Mountain View when we discussed this there seemed to be two
fairly different purposes that folks had in mind when talking
about this.

Susan and some others, (who've written this I-D) were talking
about using the extension block to pass around routing information
of some sort. I think the main example related to security
labels, so that some bundles can be routed only on appropriate
"secure" paths. So that meta-data, while associated with the
content, seems to be intended for routers and/or forwarders.

Kevin and a couple of others (I think) seemed to be talking
more about content-distribution. I think the example there that
doesn't fit with the above might be meta-data that identifies
the bundle payload in a fine-grained manner for applications.

Do we think the same extension block would/should be used for
both purposes? (Assuming we think they differ.)

S.

Armando Caro wrote:
> Peter Lovell wrote:
>> There is NO mechanism by which any block other than the payload can be
>> fragmented.
>>
>> None, at all, in any way.
> 
> Yes, I realize that.. And that was my point.
> 
>> Path MTU is not relevant to dtn. That's entirely a CL issue. It's up to
>> the CL to determine how to transport the bundle over the next-hop and
>> dtn cares little (although more than zero) about that.
>  >
>> To take a cue from RFC1149, one could print it, employ aerial conveyance
>> to the next node, scan it there and send it on its way. The only MTU
>> issue is the size allowable for the aerial conveyance, which is defined
>> by rfc as being variable. If that is too restrictive then the CL might
>> send two or more parts by separate conveyance, reassembling the stack
>> before the scan process. Higher bandwidth could probably be obtained by
>> writing to a micro SD card rather than the print/scan scheme, but the
>> effect is the same.
>>
>> So there is no sense in which control overhead crowds out the payload,
>> or other blocks. The space available is quite large and not constrained
>> by path MTU, unless a dtn implementation should choose to be so
>> constrained (and I would hope not).
> 
> I would argue that putting the burden on the CL is more restrictive, not 
> less. If you let bundles grow arbitrarily large, each hop's CL may be 
> forced to reassemble before the bundle can be forwarded. That's 
> inefficient, especially for DTNs (when the D=Disruption). The bundles 
> have a notion of lifetime, not the CL-specific fragments.
> 
> Suppose a bundle's non-payload blocks grow so large, that a CL needs to 
> fragment the bundle to forward it to the next hop. Now suppose that the 
> CL successfully sends all but one fragment to the next hop right before 
> the link goes down. The receiving CL cannot do anything with the 
> fragments. This means that when the link comes back up, the sending CL 
> needs to retransmit all the fragments again. This could be a problem for 
> flaky links with small MTUs relative to the size of the bundles.
> 
> The CL could do something smarter and try to hold onto the fragments, 
> but then the CL would need to do DTN itself.
> 
> I don't know what the right solution is. Clearly, we don't want to limit 
> the flexibility of the control blocks, but at the same time, I think we 
> do need some provision of what is reasonable use/size of these blocks 
> that are not fragmentable.
> 

Date: Thu, 26 Mar 2009 21:59:17 -0400
From: Armando Caro <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] retrans block

Susan,

Yes, I agree. The hop count idea doesn't work. I realize that there are 
other issues with this idea when you introduce multiple copy routing. I 
still think that the retrans block could be encoded by a metadata block, 
no?

BTW, the example I was referring to was the one in Section 4, that 
talked about a custodial node using an auxiliary storage node 
temporarily to free up some of its own disk space. I was trying to give 
this example a term: storage load balancing. It seemed like the example 
was alluding to a group of well-connected nodes sharing the burden of 
storage while they wait for a forwarding opportunity.

-Armando

Symington, Susan F. wrote:
> If the retransmission block isn't really needed that would be delightful, but I'm not convinced by your example that a "hop count" block type could replace it. Of course, there is always the chance that I am not understanding your idea fully.
> 
> Consider a node that receives a bundle. It decides to take custody of the bundle so it stores it and starts a custody timer for the bundle. The bundle had a hop count of 5 when it was received, so the node forwards it with a hop count of 6. 
> 
> Three hours later the custody timer for the bundle expires and the custodian responds by retransmitting the bundle. The hop count of the stored bundle is 5. So, the custodian forwards it with a hop count of 6. Since this is the second bundle with this source, timestamp, etc. with a hop count of 6, won't it erroneously get deleted as a replay? 
> 
> In other words, I don't see how your hop count idea can be used to ensure that custodially retransmitted bundles don't get deleted.
> 
> It seems to have promise as a mechanism for enabling routing loops to exist without automatically deleting them as replays, but I don't see how it can do away with the need for the retransmission block.
> 
> Also, I was a little confused by something you wrote: "The example presented in the draft presents a storage load balancing use case". I'm not sure what example you are referring to. 
> 
> -susan
> 
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************

Date: Thu, 26 Mar 2009 21:33:55 -0400
From: Armando Caro <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] metadata block - 01

Peter Lovell wrote:
> There is NO mechanism by which any block other than the payload can be
> fragmented.
> 
> None, at all, in any way.

Yes, I realize that.. And that was my point.

> Path MTU is not relevant to dtn. That's entirely a CL issue. It's up to
> the CL to determine how to transport the bundle over the next-hop and
> dtn cares little (although more than zero) about that.
 >
> To take a cue from RFC1149, one could print it, employ aerial conveyance
> to the next node, scan it there and send it on its way. The only MTU
> issue is the size allowable for the aerial conveyance, which is defined
> by rfc as being variable. If that is too restrictive then the CL might
> send two or more parts by separate conveyance, reassembling the stack
> before the scan process. Higher bandwidth could probably be obtained by
> writing to a micro SD card rather than the print/scan scheme, but the
> effect is the same.
> 
> So there is no sense in which control overhead crowds out the payload,
> or other blocks. The space available is quite large and not constrained
> by path MTU, unless a dtn implementation should choose to be so
> constrained (and I would hope not).

I would argue that putting the burden on the CL is more restrictive, not 
less. If you let bundles grow arbitrarily large, each hop's CL may be 
forced to reassemble before the bundle can be forwarded. That's 
inefficient, especially for DTNs (when the D=Disruption). The bundles 
have a notion of lifetime, not the CL-specific fragments.

Suppose a bundle's non-payload blocks grow so large, that a CL needs to 
fragment the bundle to forward it to the next hop. Now suppose that the 
CL successfully sends all but one fragment to the next hop right before 
the link goes down. The receiving CL cannot do anything with the 
fragments. This means that when the link comes back up, the sending CL 
needs to retransmit all the fragments again. This could be a problem for 
flaky links with small MTUs relative to the size of the bundles.

The CL could do something smarter and try to hold onto the fragments, 
but then the CL would need to do DTN itself.

I don't know what the right solution is. Clearly, we don't want to limit 
the flexibility of the control blocks, but at the same time, I think we 
do need some provision of what is reasonable use/size of these blocks 
that are not fragmentable.

-- 
Armando

From: "Symington, Susan F." <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, Armando Caro <[email-masked]>, DTN <[email-masked]>
Date: Thu, 26 Mar 2009 14:23:50 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] previous hop block

EID of the previous-hop DTN node. (That is what is carried in the previous hop block.)

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

>-----Original Message-----
>From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]]
>Sent: Thursday, March 26, 2009 2:10 PM
>To: Symington, Susan F.; Armando Caro; DTN
>Subject: RE: [dtn-interest] previous hop block
>
>Previous DTN node hop or previous IP node hop?
>
>Will
>
>******************************
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On
>> Behalf Of Symington, Susan F.
>> Sent: Thursday, March 26, 2009 1:26 PM
>> To: Armando Caro; DTN
>> Subject: Re: [dtn-interest] previous hop block
>>
>> If UDP is the convergence layer being used, I don't think it
>> has any indication of who the previous hop was. I think NORM
>> may have the same problem. My recollection was that there
>> were other examples as well, but the discussion was so long
>> ago I can't think of what they might have been.
>>
>> -susan
>>
>>
>>
>> *****************************************************************
>> Susan Symington
>> The MITRE Corporation
>> [email-masked]
>> 703-983-7209 (voice)
>> 703-983-7142 (fax)
>> ******************************************************************
>> >-----Original Message-----
>> >From: [email-masked] [mailto:dtn-
>> >[email-masked]] On Behalf Of Armando
>> >Caro
>> >Sent: Wednesday, March 25, 2009 9:08 PM
>> >To: DTN
>> >Subject: [dtn-interest] previous hop block
>> >
>> >Knowing the previous hop is useful information for routing and
>> >potentially other purposes. So I thought I was ok with this
>> draft, but
>> >a basic question popped into my mind. Why do we need to convey this
>> >information in the bundle at all? The receiving CLA should know the
>> >previous hop, so the receiving CLA can signal this
>> information to the
>> >BPA upon bundle reception. Am I missing something?
>> >
>> >Thanks,
>> >Armando
>> >
>> >
>> >_______________________________________________
>> >dtn-interest mailing list
>> >[email-masked]
>> >http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>

From: Peter Lovell <[email-masked]>
To: Armando Caro <[email-masked]>, dtn interest <[email-masked]>
Date: Thu, 26 Mar 2009 14:21:37 -0400
Subject: Re: [dtn-interest] metadata block - 01

Hi Armando,

On Wed, Mar 25, 2009, Armando Caro <[email-masked]> wrote:

>I have a couple of comments about the metadata block draft v01.
> ...
>There were a couple of us who raised the issue of fragmentation of
>non-payload blocks. Currently, there is no way to do so. For some
>blocks, there probably should be, but not for metadata blocks. Metadata
>blocks cannot and should not be fragmented, or else intermediate hops
>will not be able to process the metadata blocks without reassembly. So
>the question is: how do we ensure that metadata blocks never grow beyond
>what is reasonable for the path's MTU?

There is NO mechanism by which any block other than the payload can be
fragmented.

None, at all, in any way.

>There should at a minimum be some room for payload, and hopefully a
>bundle's control overhead doesn't outweigh the payload. This concern is
>not actually specific to the metadata block. I'm concerned that for
>smallish MTUs, all the possible control blocks will consume the majority
>of the space available. This issue is tricky because since we generally
>don't know the path, we don't know the path's MTU.

Path MTU is not relevant to dtn. That's entirely a CL issue. It's up to
the CL to determine how to transport the bundle over the next-hop and
dtn cares little (although more than zero) about that.

To take a cue from RFC1149, one could print it, employ aerial conveyance
to the next node, scan it there and send it on its way. The only MTU
issue is the size allowable for the aerial conveyance, which is defined
by rfc as being variable. If that is too restrictive then the CL might
send two or more parts by separate conveyance, reassembling the stack
before the scan process. Higher bandwidth could probably be obtained by
writing to a micro SD card rather than the print/scan scheme, but the
effect is the same.

So there is no sense in which control overhead crowds out the payload,
or other blocks. The space available is quite large and not constrained
by path MTU, unless a dtn implementation should choose to be so
constrained (and I would hope not).

Regards.....Peter

From: "Symington, Susan F." <[email-masked]>
To: Armando Caro <[email-masked]>, DTN <[email-masked]>
Date: Thu, 26 Mar 2009 14:20:35 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] retrans block

If the retransmission block isn't really needed that would be delightful, but I'm not convinced by your example that a "hop count" block type could replace it. Of course, there is always the chance that I am not understanding your idea fully.

Consider a node that receives a bundle. It decides to take custody of the bundle so it stores it and starts a custody timer for the bundle. The bundle had a hop count of 5 when it was received, so the node forwards it with a hop count of 6. 

Three hours later the custody timer for the bundle expires and the custodian responds by retransmitting the bundle. The hop count of the stored bundle is 5. So, the custodian forwards it with a hop count of 6. Since this is the second bundle with this source, timestamp, etc. with a hop count of 6, won't it erroneously get deleted as a replay? 

In other words, I don't see how your hop count idea can be used to ensure that custodially retransmitted bundles don't get deleted.

It seems to have promise as a mechanism for enabling routing loops to exist without automatically deleting them as replays, but I don't see how it can do away with the need for the retransmission block.

Also, I was a little confused by something you wrote: "The example presented in the draft presents a storage load balancing use case". I'm not sure what example you are referring to. 

-susan

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Armando Caro
>Sent: Wednesday, March 25, 2009 9:08 PM
>To: DTN
>Subject: [dtn-interest] retrans block
>
>I think the retrans block can be encoded in a metadata block, so it's
>not really needed.
>
>In any case... This block type seems to be of limited use and for a very
>specialized case. The example presented in the draft presents a storage
>load balancing use case, which I think makes sense. I can see the merits
>of doing such a thing. But I wonder if we need a more general solution
>for allowing intentional and unintentional routing loops, while
>maintaining replay attack suppression. I can imagine several scenarios
>where unintentional routing loops occur, yet we don't want to filter
>them with replay suppression.
>
>What if we add a "hop count" metadata block type? Each node increments
>the hop count when forwarding. Used in conjunction with the BAB, the
>receiving next hop can authenticate that the previous hop intentionally
>forwarded the bundle, even if doing so created a routing loop.
>
>Thoughts?
>
>--
>Armando
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Symington, Susan F." <[email-masked]>, Armando Caro <[email-masked]>, DTN <[email-masked]>
Date: Thu, 26 Mar 2009 13:09:51 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] previous hop block

Previous DTN node hop or previous IP node hop?

Will

******************************
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Symington, Susan F.
> Sent: Thursday, March 26, 2009 1:26 PM
> To: Armando Caro; DTN
> Subject: Re: [dtn-interest] previous hop block
> 
> If UDP is the convergence layer being used, I don't think it 
> has any indication of who the previous hop was. I think NORM 
> may have the same problem. My recollection was that there 
> were other examples as well, but the discussion was so long 
> ago I can't think of what they might have been.
> 
> -susan
> 
> 
> 
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
> >-----Original Message-----
> >From: [email-masked] [mailto:dtn- 
> >[email-masked]] On Behalf Of Armando 
> >Caro
> >Sent: Wednesday, March 25, 2009 9:08 PM
> >To: DTN
> >Subject: [dtn-interest] previous hop block
> >
> >Knowing the previous hop is useful information for routing and 
> >potentially other purposes. So I thought I was ok with this 
> draft, but 
> >a basic question popped into my mind. Why do we need to convey this 
> >information in the bundle at all? The receiving CLA should know the 
> >previous hop, so the receiving CLA can signal this 
> information to the 
> >BPA upon bundle reception. Am I missing something?
> >
> >Thanks,
> >Armando
> >
> >
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Symington, Susan F." <[email-masked]>
To: Armando Caro <[email-masked]>, DTN <[email-masked]>
Date: Thu, 26 Mar 2009 13:45:14 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] metadata block - 01

My replies are interspersed below.
-susan

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Armando Caro
>Sent: Wednesday, March 25, 2009 9:08 PM
>To: DTN
>Subject: [dtn-interest] metadata block - 01
>
>I have a couple of comments about the metadata block draft v01.
>
>Section 1, Paragraph 4. There's a capability missing that a BPA MUST
>support if it supports metadata blocks. Node must be capable of deleting
>one or more metadata blocks from a bundle before forwarding the bundle.
>This should also be refelcted in Section 3.2.
>
[Susan] Okay. Thanks. I will add this as a capability that must be supported and say that before forwarding a bundle, the node may delete one or more metadata blocks, depending on local policy.

>There were a couple of us who raised the issue of fragmentation of
>non-payload blocks. Currently, there is no way to do so. For some
>blocks, there probably should be, but not for metadata blocks. Metadata
>blocks cannot and should not be fragmented, or else intermediate hops
>will not be able to process the metadata blocks without reassembly. So
>the question is: how do we ensure that metadata blocks never grow beyond
>what is reasonable for the path's MTU?
>
[Susan] Mandate that metadata be formatted as URIs, preferably really complicated ones with embedded scripts;) (smile; sorry, I just couldn't resist.)
Seriously, you ask an important question, and it does seem to argue for the capability to be able to specify metadata using fewer rather than many bytes for those cases in which metadata block size must be kept small. While URIs may be a sensible way to encode metadata in many cases, if URIs are the only way to encode metadata, this may lead to situations in which metadata blocks grow so large that bundles cannot successfully be transmitted. It is not clear that such a capability to minimize metadata block size would be required often, but it is conceivable that it may be required. 

>There should at a minimum be some room for payload, and hopefully a
>bundle's control overhead doesn't outweigh the payload. This concern is
>not actually specific to the metadata block. I'm concerned that for
>smallish MTUs, all the possible control blocks will consume the majority
>of the space available. This issue is tricky because since we generally
>don't know the path, we don't know the path's MTU.
>
[Susan] I see your point. 
>--
>Armando
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Symington, Susan F." <[email-masked]>
To: Armando Caro <[email-masked]>, DTN <[email-masked]>
Date: Thu, 26 Mar 2009 13:26:13 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] previous hop block

If UDP is the convergence layer being used, I don't think it has any indication of who the previous hop was. I think NORM may have the same problem. My recollection was that there were other examples as well, but the discussion was so long ago I can't think of what they might have been.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Armando Caro
>Sent: Wednesday, March 25, 2009 9:08 PM
>To: DTN
>Subject: [dtn-interest] previous hop block
>
>Knowing the previous hop is useful information for routing and
>potentially other purposes. So I thought I was ok with this draft, but a
>basic question popped into my mind. Why do we need to convey this
>information in the bundle at all? The receiving CLA should know the
>previous hop, so the receiving CLA can signal this information to the
>BPA upon bundle reception. Am I missing something?
>
>Thanks,
>Armando
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Hans Kruse <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>,  [email-masked]
Date: Thu, 26 Mar 2009 10:35:50 -0400
Subject: [dtn-interest] DTN workshop at SMC-IT - Call for Presenters

--Apple-Mail-5--74570350
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Call for Presentations for
a Mini-Workshop on
   Standards Based Operational Network Structures for Future Space  
Missions
at the Third IEEE International Conference on
Space Mission Challenges in Information Technology (SMC-IT)
Pasadena, California; July 19 - 23, 2009

This one-day mini workshop focuses on the use of standards-based,  
automatic communications protocols in the design of future space  
missions, specifically the Delay Tolerant Networking (DTN) protocols.   
Invited and contributed presentations will explore the available  
technologies, and both potential benefits as well as challenges  
inherent in an evolution from classical mission-by-mission  
communications design to a design based on standard protocols.

We invite the submission of original research or concept design  
contributions in the following areas:

   Space communication network design based on DTN standards.
   Research results from operational experience with, or simulation  
of, DTN-based space communication networks.
   Routing and node/service discovery in DTN-based space networks.
   Naming and Addressing in DTN-based space networks.
   Network Management for DTN-based space networks.
   Command and Control of space assets based on DTN protocols.

The program committee invites the submission of contributions outside  
the areas listed above, and will make every effort to incorporate
quality presentations into the workshop program.  All submissions will  
be peer-reviewed.  The abstracts for the selected contributions, as
well as the presentation slides, will be published on the conference  
web site.

Deadline for 1-page abstracts: April 13, 2009 (Midnight EDT).

For more information and author instructions, please see http://www.ocp.ohiou.edu/smc-it/ 
  or e-mail [email-masked].
For more information on SMC-IT 2009, please see http://www.smc-it.org/

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-5--74570350
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; text-align: =
center; font: normal normal normal 13px/normal Helvetica; "><b>Call for =
Presentations for</b></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; text-align: center; font: =
normal normal normal 13px/normal Helvetica; "><b>a Mini-Workshop =
on</b></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; text-align: center; font: normal =
normal normal 13px/normal Helvetica; "><b>&nbsp; </b><span =
style=3D"text-decoration: underline"><b>Standards Based Operational =
Network Structures for Future Space Missions</b></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; text-align: center; font: normal normal normal =
13px/normal Helvetica; "><b>at the Third IEEE International Conference =
on&nbsp;</b></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; text-align: center; font: normal =
normal normal 13px/normal Helvetica; "><b>Space Mission Challenges in =
Information Technology (SMC-IT)</b></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; text-align: =
center; font: normal normal normal 13px/normal Helvetica; "><b>Pasadena, =
California; July 19 - 23, 2009</b></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; text-align: =
center; font: normal normal normal 12px/normal Helvetica; min-height: =
14px; "><b></b><br></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Helvetica; ">This one-day mini workshop focuses on the use =
of standards-based, automatic communications protocols in the design of =
future space missions, specifically the Delay Tolerant Networking (DTN) =
protocols.&nbsp; Invited and contributed presentations will explore the =
available technologies, and both potential benefits as well as =
challenges inherent in an evolution from classical mission-by-mission =
communications design to a design based on standard protocols.</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Helvetica; =
min-height: 13px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Helvetica; ">We invite the submission of =
original research or concept design contributions in the following =
areas:</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Helvetica; min-height: 13px; "><br></div>
<ul style=3D"list-style-type: hyphen">
<li style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px =
Helvetica">&nbsp; Space communication network design based on DTN =
standards.</li>
<li style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px =
Helvetica">&nbsp; Research results from operational experience with, or =
simulation of, DTN-based space communication networks.</li>
<li style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px =
Helvetica">&nbsp; Routing and node/service discovery in DTN-based space =
networks.</li>
<li style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px =
Helvetica">&nbsp; Naming and Addressing in DTN-based space =
networks.</li>
<li style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px =
Helvetica">&nbsp; Network Management for DTN-based space networks.</li>
<li style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px =
Helvetica">&nbsp; Command and Control of space assets based on DTN =
protocols.</li>
</ul><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; font: normal normal normal 11px/normal Helvetica; =
min-height: 13px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Helvetica; ">The program committee invites the =
submission of contributions outside the areas listed above, and will =
make every effort to incorporate</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Helvetica; ">quality presentations into the =
workshop program.&nbsp; All submissions will be peer-reviewed.&nbsp; The =
abstracts for the selected contributions, as</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Helvetica; =
">well as the presentation slides, will be published on the conference =
web site.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Helvetica; min-height: 13px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Helvetica; =
"><b>Deadline for 1-page abstracts: April 13, 2009 (Midnight =
EDT).</b></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Helvetica; min-height: 13px; "><b></b><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Helvetica; =
">For more information and author instructions, please see <a =
href=3D"http://www.ocp.ohiou.edu/smc-it/">http://www.ocp.ohiou.edu/smc-it/=
</a> or e-mail <a =
href=3D"mailto:[email-masked]">[email-masked]</a>.</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Helvetica; =
">For more information on SMC-IT 2009, please see <a =
href=3D"http://www.smc-it.org/">http://www.smc-it.org/</a></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Helvetica; =
min-height: 13px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Helvetica; min-height: 13px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Helvetica; =
min-height: 13px; "><br></div><div> <span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> </div><br></body></html>=

--Apple-Mail-5--74570350--

Date: Wed, 25 Mar 2009 21:08:14 -0400
From: Armando Caro <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] retrans block

I think the retrans block can be encoded in a metadata block, so it's
not really needed.

In any case... This block type seems to be of limited use and for a very
specialized case. The example presented in the draft presents a storage
load balancing use case, which I think makes sense. I can see the merits
of doing such a thing. But I wonder if we need a more general solution
for allowing intentional and unintentional routing loops, while
maintaining replay attack suppression. I can imagine several scenarios
where unintentional routing loops occur, yet we don't want to filter
them with replay suppression.

What if we add a "hop count" metadata block type? Each node increments
the hop count when forwarding. Used in conjunction with the BAB, the
receiving next hop can authenticate that the previous hop intentionally
forwarded the bundle, even if doing so created a routing loop.

Thoughts?

-- 
Armando

Date: Wed, 25 Mar 2009 21:08:08 -0400
From: Armando Caro <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] metadata block - 01

I have a couple of comments about the metadata block draft v01.

Section 1, Paragraph 4. There's a capability missing that a BPA MUST
support if it supports metadata blocks. Node must be capable of deleting
one or more metadata blocks from a bundle before forwarding the bundle.
This should also be refelcted in Section 3.2.

There were a couple of us who raised the issue of fragmentation of
non-payload blocks. Currently, there is no way to do so. For some
blocks, there probably should be, but not for metadata blocks. Metadata
blocks cannot and should not be fragmented, or else intermediate hops
will not be able to process the metadata blocks without reassembly. So
the question is: how do we ensure that metadata blocks never grow beyond
what is reasonable for the path's MTU?

There should at a minimum be some room for payload, and hopefully a
bundle's control overhead doesn't outweigh the payload. This concern is
not actually specific to the metadata block. I'm concerned that for
smallish MTUs, all the possible control blocks will consume the majority
of the space available. This issue is tricky because since we generally
don't know the path, we don't know the path's MTU.

-- 
Armando

Date: Wed, 25 Mar 2009 21:08:02 -0400
From: Armando Caro <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] previous hop block

Knowing the previous hop is useful information for routing and
potentially other purposes. So I thought I was ok with this draft, but a
basic question popped into my mind. Why do we need to convey this
information in the bundle at all? The receiving CLA should know the
previous hop, so the receiving CLA can signal this information to the
BPA upon bundle reception. Am I missing something?

Thanks,
Armando

Date: Tue, 24 Mar 2009 20:54:16 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Initial planning for the first Disconnectathon

For those of you who did not attend the DTNRG meeting last
week, one idea that was proposed (and received positively)
was to have regular meetings where all the people writing
BPAs, apps, and other DTN-related software could get
together in the same room and do interoperability,
compatibility, and other hands-on testing.

The basic idea is taken from the "Connectathons"
(http://www.connectathon.org/) organized by the NFS
community, and so the name "Disconnectathon" was proposed.
(Don't like the name?  Propose a better one... on a
different thread, please.  Let's plan it first.)

The first question is when to have the first one.  A
proposal was to do it during the next IETF meeting, in
Stockholm, at the end of July.  This isn't perfectly ideal
for several reasons, however, most importantly the cost of
having everyone attend IETF and travel to Stockholm.  A
second proposal was to have two concurrent (and
network-connected Disconnectathons--one in Stockholm, for
IETF attendees, and the second in Boston, hosted by BBN.  A
third idea is to schedule the Disconnectathon a week or two
prior to the IETF meeting, to make it a preamble to the
DTNRG and IETF meetings.  Again, BBN is happy to host the
meeting, if Boston is a good location for everyone.

In any case, given the complicated logistics of planning
something around the IETF (or during the height of summer
vacation season) I think it makes sense to choose one of
these approaches soon, and start nailing down dates.
Therefore, if the idea of a Disconnectathon appeals to you,
please send me your current best guess of:

1.  Which schedule/site works best for you:

	a)  At and during the IETF meeting

	b)  Split between BBN and the IETF meeting

	c)  A week or two beforehand, at BBN or elsewhere

	d)  Some other option (please elaborate)

2.  How many people you anticipate sending to your preferred
choice.  If your preference is b), please provide numbers
for each location.

3.  Any suggestions you have.

Thanks,
	-Dan

From: "Symington, Susan F." <[email-masked]>
To: dtn interest <[email-masked]>
Date: Tue, 24 Mar 2009 14:09:09 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN Previous Hop Insertion Block revision

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC022BFB4B73IMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

I revised the DTN Previous Hop Insertion Block I-D according to what we dec=
ided in Mountain View.  In summary, the revisions involved:

-Adding the capability to place the EID in the block itself rather than jus=
t referencing the EID in the dictionary.  (If the EID is already in the dic=
tionary, the Previous Hop Block can just reference it and have no block-spe=
cific fields. If the EID is not already in the dictionary, the previous hop=
 block can't insert it into the dictionary; it MUST carry  it in the block-=
specific field.)

-Restricting the information carried in the previous hop block to just the =
EID. (Remove the timestamp field.)
-Making the block non-extensible, meaning that it doesn't have the ability =
to carry any other type of information records. If someone wants more elabo=
rate information (like time of arrival, time of processing, time of departu=
re of bundle from previous hop, etc. to establish some sort of route record=
, they can define a different bundle to do this.)
-Incorporating Stephen's suggestions in the security considerations section=
.

Here is a link to the revised draft that I just uploaded.

http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-previous-hop-bl=
ock-06.txt

This is the version of the I-D that should be considered for last call from=
 now on. Thanks.

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

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC022BFB4B73IMCMBX2MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>All,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I revised the DTN Previous Hop Insertion Block I-D acc=
ording
to what we decided in Mountain View.&nbsp; In summary, the revisions involv=
ed:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-Adding the capability to place the EID in the block i=
tself rather
than just referencing the EID in the dictionary.&nbsp; (If the EID is alrea=
dy in the
dictionary, the Previous Hop Block can just reference it and have no
block-specific fields. If the EID is not already in the dictionary, the
previous hop block can&#8217;t insert it into the dictionary; it MUST carry=
&nbsp; it
in the block-specific field.)<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-Restricting the information carried in the previous h=
op
block to just the EID. (Remove the timestamp field.)<o:p></o:p></p>

<p class=3DMsoNormal><o:p></o:p></p>

<p class=3DMsoNormal>-Making the block non-extensible, meaning that it does=
n&#8217;t
have the ability to carry any other type of information records. If someone
wants more elaborate information (like time of arrival, time of processing,
time of departure of bundle from previous hop, etc. to establish some sort =
of
route record, they can define a different bundle to do this.)&nbsp; <o:p></=
o:p></p>

<p class=3DMsoNormal><o:p></o:p></p>

<p class=3DMsoNormal>-Incorporating Stephen&#8217;s suggestions in the secu=
rity
considerations section.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Here is a link to the revised draft that I just upload=
ed.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><a
href=3D"http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-previou=
s-hop-block-06.txt">http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bu=
ndle-previous-hop-block-06.txt</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>This is the version of the I-D that should be consider=
ed for
last call from now on. Thanks.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-susan<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
**</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>Susan
Symington</span><span style=3D'font-size:12.0pt;font-family:"Times New Roma=
n","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>The
MITRE Corporation</span><span style=3D'font-size:12.0pt;font-family:"Times =
New Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>[email-masked]</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7209
(voice)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman"=
,"serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7142
(fax)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman","=
serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
***</span><o:p></o:p></p>

</div>

</body>

</html>

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC022BFB4B73IMCMBX2MITREO_--

From: Matt Bromage <[email-masked]>
To: [email-masked]
Date: Sun, 22 Mar 2009 13:38:11 -0700
Subject: Re: [dtn-interest] dtn-interest Digest, Vol 18, Issue 47

Hi Laveen,

I think its a great idea. I was actually looking at blimps as a  
possible aerial component of our testbed. The great thing being that  
blimps can remain in a fixed position which greatly helps during link- 
quality testing. However while researching blimps, I found the ratio  
between carrying capacity and balloon-size was very high, and  
commercially available blimps the size you are talking about don't  
really exist (unless you know of some, let me know!). We ended up  
using fixed-wing and rotary craft because they were available,  
relatively cheap, and setup only requires charging batteries (as  
opposed to helium tanks).

-Matt

On Mar 22, 2009, at 12:00 PM, [email-masked] 
  wrote:

> Send dtn-interest mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dtn-interest digest..."
>
>
> Today's Topics:
>
>   1. Re: Aerial Nodes (Ivancic, William D. (GRC-RHN0))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 21 Mar 2009 23:40:22 -0500
> From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
> Subject: Re: [dtn-interest] Aerial Nodes
> To: laveen vikram sundararaj <[email-masked]>,
> 	"[email-masked]" <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Laveen,
>
> When someone build and aircraft it is for a specific purpose.  Then  
> they want communications.  A neutral buoyancy air craft cannot do  
> what an F14 can do or a black hawk gunship or a global hawk UAV.
>
> Unless the objective is to develop a communication platform that  
> flies, you have to work with what you've been given and develop the  
> proper antenna system.  Hence, it is NOT cheap!
>
> Note, High Altitude Airships (and perhaps Buoyancy Neutral comes  
> into play here) are about the only thing I know of that has one if  
> its main objectives as communication and surveillance.  Still the  
> antenna system have to be developed properly and those things are  
> still moving and the antenna patter will move on the ground.
>
> I am pretty close to some work with tethered dirigibles - up to  
> maybe a mile up.
>
> Unmeterred, unmanned blimp is a UAV and has limited operations over  
> unrestricted airspace due to FAA and other Civil air regulations -  
> think crashing a lawsuits and people getting hurt or killed.
>
>
> Will
>
>
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
>
>
>
>
>
> ________________________________
>
> 	From: [email-masked] [mailto:[email-masked] 
> ] On Behalf Of laveen vikram sundararaj
> 	Sent: Saturday, March 21, 2009 1:56 PM
> 	To: [email-masked]
> 	Subject: [dtn-interest] Aerial Nodes
> 	
> 	
>
> 	Hi,
> 	yesterday during DTNRG lunch break at Google cafeteria, some of the  
> folks were discussing about the problems they face with field trial  
> of aerial nodes. When Fixed wing and Rotary crafts are used to carry  
> nodes, they seem to face problems of controlling the flight and the  
> antenna orientation.
> 	I hereby suggest to consider the usage of Neutral buoyancy air  
> crafts similar to the Boeing's Sky hook which is currently under  
> development. While the Boeing's skyhook has the capacity to lift 40  
> tonnes (designed to lift the Oil drilling equipments in Frigid  
> zones), may be we can think of small prototypes to carry say 400 gms  
> or 4 lb of DTN payloads.
> 	regards,
> 	Laveen.
> 	
>
>
>
> 	 <http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle? 
> > 	
>
>
>
>
> ------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>
> End of dtn-interest Digest, Vol 18, Issue 47
> ********************************************

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: laveen vikram sundararaj <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 21 Mar 2009 23:40:22 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Aerial Nodes

 Laveen,

When someone build and aircraft it is for a specific purpose.  Then they want communications.  A neutral buoyancy air craft cannot do what an F14 can do or a black hawk gunship or a global hawk UAV.

Unless the objective is to develop a communication platform that flies, you have to work with what you've been given and develop the proper antenna system.  Hence, it is NOT cheap!

Note, High Altitude Airships (and perhaps Buoyancy Neutral comes into play here) are about the only thing I know of that has one if its main objectives as communication and surveillance.  Still the antenna system have to be developed properly and those things are still moving and the antenna patter will move on the ground.  

I am pretty close to some work with tethered dirigibles - up to maybe a mile up.  

Unmeterred, unmanned blimp is a UAV and has limited operations over unrestricted airspace due to FAA and other Civil air regulations - think crashing a lawsuits and people getting hurt or killed.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

 

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of laveen vikram sundararaj
	Sent: Saturday, March 21, 2009 1:56 PM
	To: [email-masked]
	Subject: [dtn-interest] Aerial Nodes

	Hi,
	yesterday during DTNRG lunch break at Google cafeteria, some of the folks were discussing about the problems they face with field trial of aerial nodes. When Fixed wing and Rotary crafts are used to carry nodes, they seem to face problems of controlling the flight and the antenna orientation.
	I hereby suggest to consider the usage of Neutral buoyancy air crafts similar to the Boeing's Sky hook which is currently under development. While the Boeing's skyhook has the capacity to lift 40 tonnes (designed to lift the Oil drilling equipments in Frigid zones), may be we can think of small prototypes to carry say 400 gms or 4 lb of DTN payloads.
	regards,
	Laveen.  

	 <http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?> 	

Content-class: urn:content-classes:message
Date: Sat, 21 Mar 2009 18:22:56 -0000
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9AA52.0E5FE5CB
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Yeah, the RFCs and CCSDS specs, implementations, interoperability =20
> tests, papers, PhD theses, millions of $/Euros in investments, books,
> awards, and other general mindshare aren't really enough either.=20

A lot of effort and expense went into developing the ISO networking
stack and into ATM, and they had a lot of mindshare in their time too.

L.

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

------_=_NextPart_001_01C9AA52.0E5FE5CB
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes =
roundup</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>&gt; Yeah, the RFCs and CCSDS specs, implementations, =
interoperability&nbsp;<BR>
&gt; tests, papers, PhD theses, millions of $/Euros in investments, =
books,<BR>
&gt; awards, and other general mindshare aren't really enough =
either.<BR>
<BR>
A lot of effort and expense went into developing the ISO networking<BR>
stack and into ATM, and they had a lot of mindshare in their time =
too.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9AA52.0E5FE5CB--

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
XX-CMAE-analysis: score=0 v=1.0 c=1 a=reRN_k78R_QA:10 a=85046rUVo5HqQWJ14RsA:9 a=VV34FKH7fK3sjfryLq96w3SDSXQA:4 a=50e4U0PicR4A:10 a=6SwCy3u5AAAA:8 a=K57tCgj2AAAA:8 a=LMunuUJYPrJKa_9KfZsA:7 a=LceGun9l2jxWRwRwjWyYGRh_5iQA:4 a=MRcuu4QPSFIA:10
Date: 21 Mar 2009 17:55:51 -0000
From: "laveen vikram sundararaj" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Aerial Nodes
Reply-To: laveen vikram sundararaj <[email-masked]>

 This is a multipart mime message

--Next_1237658151---0-202.137.234.122-21194
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,=0Ayesterday during DTNRG lunch break at Google cafeteria, some of the f=
olks were discussing about the problems they face with field trial of aeria=
l nodes. When Fixed wing and Rotary crafts are used to carry nodes, they se=
em to face problems of controlling the flight and the antenna orientation.=
=0AI hereby suggest to consider the usage of Neutral buoyancy air crafts si=
milar to the Boeing's Sky hook which is currently under development. While =
the Boeing's skyhook has the capacity to lift 40 tonnes (designed to lift t=
he Oil drilling equipments in Frigid zones), may be we can think of small p=
rototypes to carry say 400 gms or 4 lb of DTN payloads.=0Aregards,=0ALaveen=
. =A0=0A
--Next_1237658151---0-202.137.234.122-21194
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0AHi,<BR>=0Ayesterday during DTNRG lunch break at Google cafeteria, som=
e of the folks were discussing about the problems they face with field tria=
l of aerial nodes. When Fixed wing and Rotary crafts are used to carry node=
s, they seem to face problems of controlling the flight and the antenna ori=
entation.<BR>=0AI hereby suggest to consider the usage of Neutral buoyancy =
air crafts similar to the Boeing's Sky hook which is currently under develo=
pment. While the Boeing's skyhook has the capacity to lift 40 tonnes (desig=
ned to lift the Oil drilling equipments in Frigid zones), may be we can thi=
nk of small prototypes to carry say 400 gms or 4 lb of DTN payloads.<BR>=0A=
regards,<BR>=0ALaveen.&nbsp; <BR>=0A=0A</P>=0A<br><br>=0A<Table border=3D0 =
Width=3D644 Height=3D57 cellspacing=3D0 cellpadding=3D0 style=3D"font-famil=
y:Verdana;font-size:11px;line-height:15px;"><TR><td><A HREF=3D"http://sigad=
s.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.ht=
m@Middle?" target=3D"_blank"><IMG SRC=3D"http://sigads.rediff.com/RealMedia=
/ads/adstream_nx.ads/www.rediffmail.com/signatureline.htm@Middle"></A></td>=
</TR></Table>
--Next_1237658151---0-202.137.234.122-21194--

From: Kevin Fall <[email-masked]>
To: <[email-masked]>
Date: Sat, 21 Mar 2009 10:37:17 -0700
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup

--Apple-Mail-2--495683446
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Mar 21, 2009, at Mar 213:01 AMPDT, <[email-masked]> wrote:
....
>
>
> But really, it's just a symptom of a larger problem
> in how this group is directed, evidenced in protocol design
> and other problems. Enthusiasm and having a lot of activity
> and drafts isn't enough by itself.
>
> L.
>
>
Yeah, the RFCs and CCSDS specs, implementations, interoperability  
tests, papers, PhD theses, millions of $/Euros in investments, books,
awards, and other general mindshare aren't really enough either.  Its  
great that you here to help us fix all that.  And so
surprising we didn't notice before you arrived.

- K
--Apple-Mail-2--495683446
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Mar 21, 2009, =
at Mar 213:01 AMPDT, &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>> =
wrote:</div>....<br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"> <div> <!-- Converted from text/plain format --><p><font =
size=3D"2"><br> <br> But really, it's just a symptom of a larger =
problem<br> in how this group is directed, evidenced in protocol =
design<br> and other problems. Enthusiasm and having a lot of =
activity<br> and drafts isn't enough by itself.<br> <br> L.<br> =
<br></font></p></div></blockquote><div>Yeah, the RFCs and CCSDS specs, =
implementations, interoperability tests, papers, PhD theses, millions of =
$/Euros in investments, books,</div><div>awards, and other general =
mindshare aren't really enough either. &nbsp;Its great that you here to =
help us fix all that. &nbsp;And so</div><div>surprising we didn't notice =
before you arrived.</div><div><br></div><div>- =
K</div></div></body></html>=

--Apple-Mail-2--495683446--

Content-class: urn:content-classes:message
Date: Sat, 21 Mar 2009 10:01:21 -0000
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9AA0B.FCA45F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I did some digging - here are details, and I hope the IETF
webmaster can take action here.

Webmaster:
the missing minutes of the IETF 73 DTNRG meet are below
at end. You have the slides, which you have been converting
from ppt to pdf where needed.

Even though the chairs missed your deadlines for submitting
minutes, can you put the DTNRG meet on the record and in the
IRTF section of the official proceedings at
http://www.ietf.org/proceedings/08nov/index.html
, please?

Reply to Will:
It appears that several of the presentations
(mine, Will Ivancic's, Scott's and the chairs) have now been
converted to html from powerpoint by someone using a Mac,
and the links on the 'hidden' non-official agenda page at
http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
, which is all there is, since the chairs did not send minutes
in in time, have not been updated to match.

Look under:
http://www.ietf.org/proceedings/08nov/slides/DTNRG-0/
http://www.ietf.org/proceedings/08nov/slides/DTNRG-1/
http://www.ietf.org/proceedings/08nov/slides/DTNRG-4/
http://www.ietf.org/proceedings/08nov/slides/DTNRG-5/

Only give the chairs pdfs to avoid this happening. If
there are no animations, you can present fullscreen
from Acrobat in much the same way, so ppt is not needed.
(A pdf copy of my own presentation is at the bottom of:
http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
I gave Stephen both ppt to present and pdf for archival. )

It would be churlish to complain about the lack of organisation
of the chairs that led to this situation - even though it's
hardly the first time that deadlines have been missed, or
reminder emails have passed by without action. I believe
they're doing their best.

But really, it's just a symptom of a larger problem
in how this group is directed, evidenced in protocol design
and other problems. Enthusiasm and having a lot of activity
and drafts isn't enough by itself.

L.

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

-----Original Message-----
From: Will Leland [mailto:[email-masked]]
Sent: Sat 2009-03-21 3:50
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes =
roundup
=20
Thanks for posting this info, Lloyd.

A possible glitch: the following URLs all generated
an object-not-found (404) error when I tried to access them just
now:
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt
http://www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt
-- Will

Lloyd Wood wrote:
> This email is intended to round up the non-final IETF 73 Minneapolis =
November 2009 Delay Tolerant Networking research group (DTNRG) minutes =
and presentations to provide information in one place in the list =
archive.
>
> Minutes were not submitted to the IETF in time by the chairs, so the =
minutes and presentations aren't officially in the IETF 73 proceedings =
at:
> http://www.ietf.org/proceedings/08nov/index.html
> which does not link to the hidden:
> http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
> where a number of presentations are stored:
> 0900-0905       Welcome & agenda bash   Chairs =
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt
> 0905-0915    DTNRG document status Chairs=20
> 0915-1000    Planning to finish existing documents All
> 1000-1020       Bundle Checksums        Lloyd Wood =
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt
> 1020-1030       Ohio Univ. testbed work         Hans Kruse =
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-2.pdf
> 1030-1040       UDP CL  Hans Kruse =
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-3.pdf
> 1040-1050       NASA/CCSDS DTN update   Will Ivancic =
http://www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt
> 1050-1100       N4C/PRoPHET     Avri Doria =
http://www.ietf.org/proceedings/08nov/slides/DTNRG-6.ppt
> 1100-1115    Bundle encapsulation discussion  Susan Symmington=20
> 1115-1129       Deep Impact Experiment  Scott Burleigh =
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt
>
> (Scott and Lloyd presented on two separate tests of the DTN bundle =
protocol using spacecraft.)
>
> The draft minutes, taken by Elwyn Davies, were posted to the list by =
the chairs:
> =
http://maillists.intel-research.net/pipermail/dtn-interest/2009-February/=
003521.html
> but in word and pdf format - and only text is archived on the list =
(so, no point in sending the above powerpoints to the list). Those draft =
minutes are repeated at end below as text to at least provide a readable =
copy in the list archive. To my knowledge, there are no final minutes or =
comments on these draft minutes.
>
> ***
>
> Notes on DTNRG meeting @ IETF 73 Thursday 9-11.30=20
>
> Highlights:
> "       We'll do a "last call" on the following documents "now," where =
"now" means as soon as the authors say they're ready on the list:
> "       draft-irtf-dtnrg-prophet
> "       draft-irtf-dtnrg-tcp-clayer
> "       draft-irtf-dtnrg-bundle-security
> "       draft-irtf-dtnrg-sec-overview
> "       draft-irtf-dtnrg-sdnv
> "       draft-irtf-dtnrg-bundle-previous-hop-block
> "       draft-irtf-dtnrg-cbhe
> "       A bunch of people (about 10-12) agreed to put up bundle =
protocol nodes on the Internet and we'll use Hans Kruse's dtnbone =
mailing list to co-ordinate that; we set ourselves some goals to meet =
before the March meeting.
> "       http://korgano.eecs.ohiou.edu/mailman/listinfo/dtnbone=20
> "       Scott Burleigh reported on their experiment with a BP/LTP =
router running on the Deep Impact spacecraft and communicating 25 =
million km back to Earth
>
> Kevin Fall: Introduction
> "       Intros and agenda bashing - no changes requested
> "       Doc status (LTP RFCs now published)
> "       Announcement of standalone meeting (March 20/21 SF, hosted by =
Google, Logistics later)
> Stephen Farrell: Looking at drafts status
> "       Aaron Falk: Expressed wonder at number of potential RFCs
> "       Lloyd Wood: Saratoga docs future:  Saratoga base docs in =
Transport Area; dtnrg docs future are bundle over Saratoga.. what goes =
on depends on what goes on in transport area
> "       Susan Symmington:  Asked for input on retrans block.  Metadata =
drafts - would like them to go forward
> "       Joerg Ott:  Thinks metadata 'ontology' system is too vague for =
proto developers. =20
> "       SF: Please start discussion on list
> "       ?: dtnbadisc.. has been implemented but not sure if author =
still working on it
> "       JO: dtn-appl:  will discuss with SS how to progress metadata
> "       SF: would love km to go forward=20
> "       SF/JO: not sure if kutscher unicast cl is going forward
>
> SF: doc completion..
> "       Took 18months  to get RFCs.. asked EBD to shepherd bunch of =
docs
> "       Steve Crocker(?): useful to give feedback on new IRTF doc =
stream process
> "       AF: RG shepherd is responsible for pushing docs forward.. =
delay caused by dropped tokens.. difficulty is often on converging after =
review
> "       ?: talking about what happens in getting consensus on =
publishing - and where it is stated
>
> SF: docs ready for last call: ~6 docs
> "       SS: want previous hop block on list; also metadata docs if =
resolution can be achieved
> "       Scott Burleigh:  Wants compressed bundle header (CBHE) on list =
also
> "       SS: previous hop block is ready for last call
> "       AD: Prophet is very nearly ready - end of CY
> "       SF: Bundle sec end of CY 08
> "       SF: sec overview END OF YEAR
> "       LW: bundle checksum neds a bit more work
> "       Wes Eddy: sdnv essentially ready
> "       SB: compressed bundle header ready
> "       JO: UDP CL:  question about whether it would be good to be =
able to know how big bundles might be (unit of transfer)?  But doc is =
probably ready now - SF: took view that this shouldn't be in CL
>
>
> Lloyd Woods: Reliability - further points for discussion
> "       - scenario not covered by bundle checksum draft
> "       - presented slides
> "       - overview of DTN from a control loop PoV
> "       - asserts DTN not same as current low elasticity IPv6 state of =
the art - DTN needs a different approach to reliability
> "       - worked example - one bundle encrypted/integrity protected =
(term should be 'PCB'), other just reliability mechanism
> "       - compare how soon bundle arrives intact - in scenario =
exhibited insecure coperhsuite reliability one arrives first
> "       - conclusion: need to provide a combination confidentiality+ =
reliability mode to allow for fast resends
> "       Questions:
> "       SF: If this doesn't work already it is a bug in the docs
> "       LW: not clear that docs allow sequential application of =
mechanisms.. need text in docs to ensure this can happen
> "       SS: believes docs cover this
> "       LW: will think about some text and write careful notes
> "       SC: Corruption exhibited could fall into two classes:  (1) =
'mother nature' induced changes would be caught by this (2) malicious =
changes might not be.. probably only a public key based story would be  =
needed
> "       LW: believes his proposal covers both cases - need both =
'layers' to cover both cases
> "       KF: this kind of integrity check might not work with =
situations are using FEC to improve reliability
> "       SF: should chat with SS and work through docs to ensure cases =
are covered.
> "       KF: remember Fec case
> "       LW: Picture on how a convergence layer should support =
reliability.=20
> "       LW/KF: No doc tells about what bundle proto expects from CLs
> "       Wes Eddy:
> "       Hans Kruse: Want to be careful about what goes in CL and what =
goes in bundle - architecturally common reqs need to go in higher layers =
or maybe in a service proto
> "       KF: might end uo with a shim at bottom of bundle proto to =
manage=20
> "       Gory Fairhurst:  Do we have to do it in UDP CL?  IETF says you =
have to explain how you do all the things that UDP doesn't do for you
> "       KF: UDP draft has pointer to the RFC that talks about this =
story
> "       LW: reporting on reliability problems experienced in =
transferring images from satellite (as reported in Time magazine)
> "       KF et al: Origin of Orbital Internet phrase
>
> Hans Kruse: Dtnbone - test systems at OU
> "       NASA starting to use test environment as a cheaper alternative =
to real satellotes
> "       ION end points shortly available for trials
> "       Firefox plugin available to give access to ION web proxy=20
> "       ION uses a different TCP CL - uses two TCP connections - NAT =
issues.. bundle relay helps
> "       No DNS mechanims yet.. so naming issues - wiki available to =
manage naming issues
> "       May get DTN2 nodes available in testbed soon.to help with =
tests
> "       network management is being thought about
> "       needs resources to maintain internal security/integrity! (war =
story!)
> "       Mailing list available - see slide
> "       Questions
> "       Will Ivancic: Is compact routing available?
> "       HK: yes - routing a focus in near future
> "       KF: (asking AF) Would this be something that could be factored =
into Geni?
> "       AF: Are you bringing infrastructure or expertise to table?
> "       HK: both
> "       AF: so would be good in Geni.  Geni looking at resource =
allocation interfaces=20
> "       HK: that would be good as don't want to spend time on that.
> "       SF: Can anybody else consider putting up bundle agents?  How =
many exist at the moment?
> "       (count was around 10)
> "       HK: Send mail to HK to inform him of publically available =
nodes.
> "       SC: Public net would be very useful
> "       HK: Good to have a directory
> "       JO: Would be good to have something more than pings.. maybe a =
camera.. they have that in their net.. will have a 2.6.0 web server soon
> "       HK: good to have different sorts of traffic flying around
> "       AF: interesting to have nodes on different types of network as =
well as sorts of connectivity
> "       KF: PlanetLab stil has a DTN project.. also look at using =
lambda mechanisms.. also DARPA have stuf on transmitting VoIP over DTN =
(!)
> "       AD: N4C will want to connect to Geni
> "       SF/AD: might have  a 'funny' network connected during summer =
trials
> "       KF: Don't forget Massachusetts folk doing diesel net etc
> "       SF: register to dtnbone mailing list if can contribute
> "       SF: a goal would be useful
> "       KF/HK: see if can exchange a ping between 6 sites by march - =
using at least 2 different implementations and different CLs.
>
> Hans Kruse: UDP CL
> "       00 draft out now
> "       Why bundle protocol overUDP (rather than directly over IP)?; =
Does it meet pseudo-reliable assumption in RFC 5050; Do we need Ack and =
retransmission
> "       Questions:
> "       KF: Doesn't believe 5050 really requires pseudo-reliability
> "       Bob Cole:  Maybe nodes don't want to acknowledge their =
existence
> "       KF: Use UDP if don't care about acks or reliability
> "       HK: Suggest that should not feed UDP CL with segments that =
need further fragmentation; Would like to avid complicating the CL with =
further frag capabilities; UDP lite options: Suggest that should *not* =
disable checksums in LTP.. but might be useful for bundles
> "       WE: why UDP and not IP?  Getting through NATs is not really =
helpful for DTNs.  If really worried about size of packet than UDP =
header could be an issue.
> "       SB: Think about providing hints from bundle layer to CL =
(system?) about what sort of CL would be preferred.
> "       HK: shim talked about earlier might be a good solution. Bundle =
agent would have to pick between options
> "       LW: IPv6 doesn't allow turning off UDP checksum. Would have to =
use UDP lite if want to anoid reliability enforcemnet
> "       KF: wants to avoid having realiabiluty mechanisms imposed in =
it.  If bundle already has internal protection against bit errors then =
don't want to use alternatives as well
> "       GF: UDP lite is the right solution for this
> "       HK: New RFC 5450(?) tells about protecting networks from =
injudicious use of UDP.  Need to adhere to guidelines so that we don't =
get in trouble.  Need to add some text to doc guidelines.
> "       GF: RFC says must do congestion control if doing very large =
transfers.  PWE wg has a 'shut up' solution.. should investigate. =20
> "       KF/GF: Could work over DCCP instead for working over Internet? =
 RFC says we ought to use it.
> "       HK: because we don't always have control loops then DCCP might =
not be relevant.  UDP would still be needed.
> "       LW: Look at Saratoga implementation which has studied a number =
of these issues.
> "       SF: Please review draft
>
> Will Ivancic: NASA update
> "       Discussing test plan
> "       UK-DMC implementation with partial DTN implementation; Learnt =
checksums were very useful.. spacecraft added MD5 checksums.. checked =
manually on ground
> "       NASA flight readiness by 2011 plan; trying to get operations =
people involved; Building a Multi-center DTN Engineering Testbed (DEN)
> "       Hoping to have a gateway from NASA network to dtnbone
> "       Description of CCSDS  - inter-governmental standards org - has =
DTN wg working on how to adapt bundle protocol and LTP for space work =
(assuming they are deemed suitable)
>
> Avri Doria: N4C report
> "       PRoPHEt update.. more or less ready for experimental status; =
needs a bit about how to set parameters to get best out of proto in =
various scenarios
> "       will be doing simulations to see how values should be adjusted
> "       emulation network being created
> "       Simulation status - some PRoPHET 'bashing' in papers.. need to =
investigate whether this is reproducible and to determine how we can fix =
any problems=20
>
> Susan Symmington: Bundle-in-Bundle encapsulation (no slides)
> "       Reporting on recent teleconf
> "       3 use cases
> "       may want to send bundle from cache to late joining uses - need =
to encapsulate to avoid being resent to all previous recipients whe =
using multicast destination
> "       resend custody bundle to particular recipient
> "       tunnels
> "       draft suggested using custody records but not possible; =
current conclusion is that encapsulation is now an application issue; =
doesn't really affect bundle protocol; draft just needs to say how to do =
encapsulations; but may need to have new feature in bundle proto - =
'diversion'
> "       Questions:
> "       KF: Not clear that multicast case is really so. Routing tables =
may be able to suppress retransmissions - people using information =
layers on top may nit need this
> "       SS: need two docs: ID for encap that is application layer and =
ID for specifying diverting and receiving bundles
> "       SC: Suppose you view all attempts at multicasting as partial - =
then you would get the sending to an extra member for free - each =
attempt just sends to a subset of members.. conceptual view
> "       AD: Maybe tied in with need to divert bundles into alternative =
routing protos.
> "       SB: Maybe think of b-in-b as a different CL.
>
>
> Scott Burleigh: First look at Deep Impact DTN Experiment
> "       Deep Impact between tasks so available for tests
> "       Demonstrating ION and getting technology readiness 7/8 =
qualification
> "       Used CCSDS AMS (Asynchronous Message Service) over BP/LTP
> "       Concluded that fully automatic operation of a DTN over deep =
space links is feasible
> "       Software is at tech readiness level 7
> "       Questions:
> "       Malcom Eris: Have there been BW efficiency calculations on =
various protocol stack options.
> "       SB: first pass on this expt is that DTN overhead is in noise =
compared with necessary FEC
> "       ME: Tictoc wg in IETf asking if DTN has any timing =
requirements
> "       SB: Space was OK with 5-10 secs level.. but better might be =
useful
> "       KF: Other project (like aircraft) might have stricter reqs: =
encourage people to send info to tictoc mailing list (ME to send pointer =
to dtn interest)
> "       WI: How was contact plan infor sent to speaccraft for routing
> "       SB: Tried to keep it low risk so didn't send stuff to =
spacecraft but expect o do that it follow up
> "       WI:  will a dynamic routing proto be needed to cope with =
change of plan?
> "       SB:  actually do parts.. management and (more static routing)
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>  =20

------_=_NextPart_001_01C9AA0B.FCA45F20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes =
roundup</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I did some digging - here are details, and I hope the =
IETF<BR>
webmaster can take action here.<BR>
<BR>
Webmaster:<BR>
the missing minutes of the IETF 73 DTNRG meet are below<BR>
at end. You have the slides, which you have been converting<BR>
from ppt to pdf where needed.<BR>
<BR>
Even though the chairs missed your deadlines for submitting<BR>
minutes, can you put the DTNRG meet on the record and in the<BR>
IRTF section of the official proceedings at<BR>
<A =
HREF=3D"http://www.ietf.org/proceedings/08nov/index.html">http://www.ietf=
.org/proceedings/08nov/index.html</A><BR>
, please?<BR>
<BR>
Reply to Will:<BR>
It appears that several of the presentations<BR>
(mine, Will Ivancic's, Scott's and the chairs) have now been<BR>
converted to html from powerpoint by someone using a Mac,<BR>
and the links on the 'hidden' non-official agenda page at<BR>
<A =
HREF=3D"http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html">http://w=
ww.ietf.org/proceedings/08nov/agenda/DTNRG.html</A><BR>
, which is all there is, since the chairs did not send minutes<BR>
in in time, have not been updated to match.<BR>
<BR>
Look under:<BR>
<A =
HREF=3D"http://www.ietf.org/proceedings/08nov/slides/DTNRG-0/">http://www=
.ietf.org/proceedings/08nov/slides/DTNRG-0/</A><BR>
<A =
HREF=3D"http://www.ietf.org/proceedings/08nov/slides/DTNRG-1/">http://www=
.ietf.org/proceedings/08nov/slides/DTNRG-1/</A><BR>
<A =
HREF=3D"http://www.ietf.org/proceedings/08nov/slides/DTNRG-4/">http://www=
.ietf.org/proceedings/08nov/slides/DTNRG-4/</A><BR>
<A =
HREF=3D"http://www.ietf.org/proceedings/08nov/slides/DTNRG-5/">http://www=
.ietf.org/proceedings/08nov/slides/DTNRG-5/</A><BR>
<BR>
Only give the chairs pdfs to avoid this happening. If<BR>
there are no animations, you can present fullscreen<BR>
from Acrobat in much the same way, so ppt is not needed.<BR>
(A pdf copy of my own presentation is at the bottom of:<BR>
<A =
HREF=3D"http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http:/=
/personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A><BR>
I gave Stephen both ppt to present and pdf for archival. )<BR>
<BR>
It would be churlish to complain about the lack of organisation<BR>
of the chairs that led to this situation - even though it's<BR>
hardly the first time that deadlines have been missed, or<BR>
reminder emails have passed by without action. I believe<BR>
they're doing their best.<BR>
<BR>
But really, it's just a symptom of a larger problem<BR>
in how this group is directed, evidenced in protocol design<BR>
and other problems. Enthusiasm and having a lot of activity<BR>
and drafts isn't enough by itself.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Will Leland [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Sat 2009-03-21 3:50<BR>
To: Wood L Dr (Electronic Eng)<BR>
Cc: [email-masked]<BR>
Subject: Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes =
roundup<BR>
<BR>
Thanks for posting this info, Lloyd.<BR>
<BR>
A possible glitch: the following URLs all generated<BR>
an object-not-found (404) error when I tried to access them just<BR>
now:<BR>
<A =
HREF=3D"http://www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt">http:/=
/www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt</A><BR>
<A =
HREF=3D"http://www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt">http:/=
/www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt</A><BR>
<A =
HREF=3D"http://www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt">http:/=
/www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt</A><BR>
<A =
HREF=3D"http://www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt">http://=
www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt</A><BR>
-- Will<BR>
<BR>
<BR>
Lloyd Wood wrote:<BR>
&gt; This email is intended to round up the non-final IETF 73 =
Minneapolis November 2009 Delay Tolerant Networking research group =
(DTNRG) minutes and presentations to provide information in one place in =
the list archive.<BR>
&gt;<BR>
&gt; Minutes were not submitted to the IETF in time by the chairs, so =
the minutes and presentations aren't officially in the IETF 73 =
proceedings at:<BR>
&gt; <A =
HREF=3D"http://www.ietf.org/proceedings/08nov/index.html">http://www.ietf=
.org/proceedings/08nov/index.html</A><BR>
&gt; which does not link to the hidden:<BR>
&gt; <A =
HREF=3D"http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html">http://w=
ww.ietf.org/proceedings/08nov/agenda/DTNRG.html</A><BR>
&gt; where a number of presentations are stored:<BR>
&gt; 0900-0905&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Welcome &amp; agenda =
bash&nbsp;&nbsp; Chairs <A =
HREF=3D"http://www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt">http:/=
/www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt</A><BR>
&gt; 0905-0915&nbsp;&nbsp;&nbsp; DTNRG document status Chairs<BR>
&gt; 0915-1000&nbsp;&nbsp;&nbsp; Planning to finish existing documents =
All<BR>
&gt; 1000-1020&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bundle =
Checksums&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lloyd Wood <A =
HREF=3D"http://www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt">http:/=
/www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt</A><BR>
&gt; 1020-1030&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ohio Univ. testbed =
work&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hans Kruse <A =
HREF=3D"http://www3.ietf.org/proceedings/08nov/slides/DTNRG-2.pdf">http:/=
/www3.ietf.org/proceedings/08nov/slides/DTNRG-2.pdf</A><BR>
&gt; 1030-1040&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UDP CL&nbsp; Hans =
Kruse <A =
HREF=3D"http://www3.ietf.org/proceedings/08nov/slides/DTNRG-3.pdf">http:/=
/www3.ietf.org/proceedings/08nov/slides/DTNRG-3.pdf</A><BR>
&gt; 1040-1050&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NASA/CCSDS DTN =
update&nbsp;&nbsp; Will Ivancic <A =
HREF=3D"http://www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt">http://=
www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt</A><BR>
&gt; 1050-1100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N4C/PRoPHET&nbsp;&nbsp;&nbsp;&nbsp; Avri Doria <A =
HREF=3D"http://www.ietf.org/proceedings/08nov/slides/DTNRG-6.ppt">http://=
www.ietf.org/proceedings/08nov/slides/DTNRG-6.ppt</A><BR>
&gt; 1100-1115&nbsp;&nbsp;&nbsp; Bundle encapsulation discussion&nbsp; =
Susan Symmington<BR>
&gt; 1115-1129&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Deep Impact =
Experiment&nbsp; Scott Burleigh <A =
HREF=3D"http://www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt">http:/=
/www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt</A><BR>
&gt;<BR>
&gt; (Scott and Lloyd presented on two separate tests of the DTN bundle =
protocol using spacecraft.)<BR>
&gt;<BR>
&gt; The draft minutes, taken by Elwyn Davies, were posted to the list =
by the chairs:<BR>
&gt; <A =
HREF=3D"http://maillists.intel-research.net/pipermail/dtn-interest/2009-F=
ebruary/003521.html">http://maillists.intel-research.net/pipermail/dtn-in=
terest/2009-February/003521.html</A><BR>
&gt; but in word and pdf format - and only text is archived on the list =
(so, no point in sending the above powerpoints to the list). Those draft =
minutes are repeated at end below as text to at least provide a readable =
copy in the list archive. To my knowledge, there are no final minutes or =
comments on these draft minutes.<BR>
&gt;<BR>
&gt; ***<BR>
&gt;<BR>
&gt; Notes on DTNRG meeting @ IETF 73 Thursday 9-11.30<BR>
&gt;<BR>
&gt; Highlights:<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We'll do a &quot;last =
call&quot; on the following documents &quot;now,&quot; where =
&quot;now&quot; means as soon as the authors say they're ready on the =
list:<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-irtf-dtnrg-prophet<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-irtf-dtnrg-tcp-clayer<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-irtf-dtnrg-bundle-security<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-irtf-dtnrg-sec-overview<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-irtf-dtnrg-sdnv<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-irtf-dtnrg-bundle-previous-hop-block<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-irtf-dtnrg-cbhe<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A bunch of people (about =
10-12) agreed to put up bundle protocol nodes on the Internet and we'll =
use Hans Kruse's dtnbone mailing list to co-ordinate that; we set =
ourselves some goals to meet before the March meeting.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://korgano.eecs.ohiou.edu/mailman/listinfo/dtnbone">http://ko=
rgano.eecs.ohiou.edu/mailman/listinfo/dtnbone</A><BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Scott Burleigh reported =
on their experiment with a BP/LTP router running on the Deep Impact =
spacecraft and communicating 25 million km back to Earth<BR>
&gt;<BR>
&gt; Kevin Fall: Introduction<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Intros and agenda =
bashing - no changes requested<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Doc status (LTP RFCs now =
published)<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Announcement of =
standalone meeting (March 20/21 SF, hosted by Google, Logistics =
later)<BR>
&gt; Stephen Farrell: Looking at drafts status<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aaron Falk: Expressed =
wonder at number of potential RFCs<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lloyd Wood: Saratoga =
docs future:&nbsp; Saratoga base docs in Transport Area; dtnrg docs =
future are bundle over Saratoga.. what goes on depends on what goes on =
in transport area<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Susan Symmington:&nbsp; =
Asked for input on retrans block.&nbsp; Metadata drafts - would like =
them to go forward<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Joerg Ott:&nbsp; Thinks =
metadata 'ontology' system is too vague for proto developers.&nbsp;<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: Please start =
discussion on list<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ?: dtnbadisc.. has been =
implemented but not sure if author still working on it<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; JO: dtn-appl:&nbsp; will =
discuss with SS how to progress metadata<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: would love km to go =
forward<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF/JO: not sure if =
kutscher unicast cl is going forward<BR>
&gt;<BR>
&gt; SF: doc completion..<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Took 18months&nbsp; to =
get RFCs.. asked EBD to shepherd bunch of docs<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Steve Crocker(?): useful =
to give feedback on new IRTF doc stream process<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AF: RG shepherd is =
responsible for pushing docs forward.. delay caused by dropped tokens.. =
difficulty is often on converging after review<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ?: talking about what =
happens in getting consensus on publishing - and where it is stated<BR>
&gt;<BR>
&gt; SF: docs ready for last call: ~6 docs<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SS: want previous hop =
block on list; also metadata docs if resolution can be achieved<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Scott Burleigh:&nbsp; =
Wants compressed bundle header (CBHE) on list also<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SS: previous hop block =
is ready for last call<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AD: Prophet is very =
nearly ready - end of CY<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: Bundle sec end of CY =
08<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: sec overview END OF =
YEAR<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW: bundle checksum neds =
a bit more work<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wes Eddy: sdnv =
essentially ready<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SB: compressed bundle =
header ready<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; JO: UDP CL:&nbsp; =
question about whether it would be good to be able to know how big =
bundles might be (unit of transfer)?&nbsp; But doc is probably ready now =
- SF: took view that this shouldn't be in CL<BR>
&gt;<BR>
&gt;<BR>
&gt; Lloyd Woods: Reliability - further points for discussion<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - scenario not covered =
by bundle checksum draft<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - presented slides<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - overview of DTN from a =
control loop PoV<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - asserts DTN not same =
as current low elasticity IPv6 state of the art - DTN needs a different =
approach to reliability<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - worked example - one =
bundle encrypted/integrity protected (term should be 'PCB'), other just =
reliability mechanism<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - compare how soon =
bundle arrives intact - in scenario exhibited insecure coperhsuite =
reliability one arrives first<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - conclusion: need to =
provide a combination confidentiality+ reliability mode to allow for =
fast resends<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Questions:<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: If this doesn't work =
already it is a bug in the docs<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW: not clear that docs =
allow sequential application of mechanisms.. need text in docs to ensure =
this can happen<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SS: believes docs cover =
this<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW: will think about =
some text and write careful notes<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SC: Corruption exhibited =
could fall into two classes:&nbsp; (1) 'mother nature' induced changes =
would be caught by this (2) malicious changes might not be.. probably =
only a public key based story would be&nbsp; needed<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW: believes his =
proposal covers both cases - need both 'layers' to cover both cases<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: this kind of =
integrity check might not work with situations are using FEC to improve =
reliability<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: should chat with SS =
and work through docs to ensure cases are covered.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: remember Fec =
case<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW: Picture on how a =
convergence layer should support reliability.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW/KF: No doc tells =
about what bundle proto expects from CLs<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wes Eddy:<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hans Kruse: Want to be =
careful about what goes in CL and what goes in bundle - architecturally =
common reqs need to go in higher layers or maybe in a service proto<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: might end uo with a =
shim at bottom of bundle proto to manage<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gory Fairhurst:&nbsp; Do =
we have to do it in UDP CL?&nbsp; IETF says you have to explain how you =
do all the things that UDP doesn't do for you<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: UDP draft has =
pointer to the RFC that talks about this story<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW: reporting on =
reliability problems experienced in transferring images from satellite =
(as reported in Time magazine)<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF et al: Origin of =
Orbital Internet phrase<BR>
&gt;<BR>
&gt; Hans Kruse: Dtnbone - test systems at OU<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NASA starting to use =
test environment as a cheaper alternative to real satellotes<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ION end points shortly =
available for trials<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Firefox plugin available =
to give access to ION web proxy<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ION uses a different TCP =
CL - uses two TCP connections - NAT issues.. bundle relay helps<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No DNS mechanims yet.. =
so naming issues - wiki available to manage naming issues<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; May get DTN2 nodes =
available in testbed soon.to help with tests<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; network management is =
being thought about<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; needs resources to =
maintain internal security/integrity! (war story!)<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mailing list available - =
see slide<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Questions<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Will Ivancic: Is compact =
routing available?<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: yes - routing a =
focus in near future<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: (asking AF) Would =
this be something that could be factored into Geni?<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AF: Are you bringing =
infrastructure or expertise to table?<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: both<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AF: so would be good in =
Geni.&nbsp; Geni looking at resource allocation interfaces<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: that would be good =
as don't want to spend time on that.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: Can anybody else =
consider putting up bundle agents?&nbsp; How many exist at the =
moment?<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (count was around =
10)<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: Send mail to HK to =
inform him of publically available nodes.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SC: Public net would be =
very useful<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: Good to have a =
directory<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; JO: Would be good to =
have something more than pings.. maybe a camera.. they have that in =
their net.. will have a 2.6.0 web server soon<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: good to have =
different sorts of traffic flying around<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AF: interesting to have =
nodes on different types of network as well as sorts of connectivity<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: PlanetLab stil has a =
DTN project.. also look at using lambda mechanisms.. also DARPA have =
stuf on transmitting VoIP over DTN (!)<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AD: N4C will want to =
connect to Geni<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF/AD: might have&nbsp; =
a 'funny' network connected during summer trials<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: Don't forget =
Massachusetts folk doing diesel net etc<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: register to dtnbone =
mailing list if can contribute<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: a goal would be =
useful<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF/HK: see if can =
exchange a ping between 6 sites by march - using at least 2 different =
implementations and different CLs.<BR>
&gt;<BR>
&gt; Hans Kruse: UDP CL<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00 draft out now<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Why bundle protocol =
overUDP (rather than directly over IP)?; Does it meet pseudo-reliable =
assumption in RFC 5050; Do we need Ack and retransmission<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Questions:<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: Doesn't believe 5050 =
really requires pseudo-reliability<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bob Cole:&nbsp; Maybe =
nodes don't want to acknowledge their existence<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: Use UDP if don't =
care about acks or reliability<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: Suggest that should =
not feed UDP CL with segments that need further fragmentation; Would =
like to avid complicating the CL with further frag capabilities; UDP =
lite options: Suggest that should *not* disable checksums in LTP.. but =
might be useful for bundles<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WE: why UDP and not =
IP?&nbsp; Getting through NATs is not really helpful for DTNs.&nbsp; If =
really worried about size of packet than UDP header could be an =
issue.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SB: Think about =
providing hints from bundle layer to CL (system?) about what sort of CL =
would be preferred.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: shim talked about =
earlier might be a good solution. Bundle agent would have to pick =
between options<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW: IPv6 doesn't allow =
turning off UDP checksum. Would have to use UDP lite if want to anoid =
reliability enforcemnet<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: wants to avoid =
having realiabiluty mechanisms imposed in it.&nbsp; If bundle already =
has internal protection against bit errors then don't want to use =
alternatives as well<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GF: UDP lite is the =
right solution for this<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: New RFC 5450(?) =
tells about protecting networks from injudicious use of UDP.&nbsp; Need =
to adhere to guidelines so that we don't get in trouble.&nbsp; Need to =
add some text to doc guidelines.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GF: RFC says must do =
congestion control if doing very large transfers.&nbsp; PWE wg has a =
'shut up' solution.. should investigate.&nbsp;<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF/GF: Could work over =
DCCP instead for working over Internet?&nbsp; RFC says we ought to use =
it.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HK: because we don't =
always have control loops then DCCP might not be relevant.&nbsp; UDP =
would still be needed.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LW: Look at Saratoga =
implementation which has studied a number of these issues.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SF: Please review =
draft<BR>
&gt;<BR>
&gt; Will Ivancic: NASA update<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Discussing test plan<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UK-DMC implementation =
with partial DTN implementation; Learnt checksums were very useful.. =
spacecraft added MD5 checksums.. checked manually on ground<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NASA flight readiness by =
2011 plan; trying to get operations people involved; Building a =
Multi-center DTN Engineering Testbed (DEN)<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hoping to have a gateway =
from NASA network to dtnbone<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Description of =
CCSDS&nbsp; - inter-governmental standards org - has DTN wg working on =
how to adapt bundle protocol and LTP for space work (assuming they are =
deemed suitable)<BR>
&gt;<BR>
&gt; Avri Doria: N4C report<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRoPHEt update.. more or =
less ready for experimental status; needs a bit about how to set =
parameters to get best out of proto in various scenarios<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will be doing =
simulations to see how values should be adjusted<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; emulation network being =
created<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Simulation status - some =
PRoPHET 'bashing' in papers.. need to investigate whether this is =
reproducible and to determine how we can fix any problems<BR>
&gt;<BR>
&gt; Susan Symmington: Bundle-in-Bundle encapsulation (no slides)<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reporting on recent =
teleconf<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 use cases<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may want to send bundle =
from cache to late joining uses - need to encapsulate to avoid being =
resent to all previous recipients whe using multicast destination<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; resend custody bundle to =
particular recipient<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tunnels<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft suggested using =
custody records but not possible; current conclusion is that =
encapsulation is now an application issue; doesn't really affect bundle =
protocol; draft just needs to say how to do encapsulations; but may need =
to have new feature in bundle proto - 'diversion'<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Questions:<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: Not clear that =
multicast case is really so. Routing tables may be able to suppress =
retransmissions - people using information layers on top may nit need =
this<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SS: need two docs: ID =
for encap that is application layer and ID for specifying diverting and =
receiving bundles<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SC: Suppose you view all =
attempts at multicasting as partial - then you would get the sending to =
an extra member for free - each attempt just sends to a subset of =
members.. conceptual view<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AD: Maybe tied in with =
need to divert bundles into alternative routing protos.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SB: Maybe think of =
b-in-b as a different CL.<BR>
&gt;<BR>
&gt;<BR>
&gt; Scott Burleigh: First look at Deep Impact DTN Experiment<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Deep Impact between =
tasks so available for tests<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Demonstrating ION and =
getting technology readiness 7/8 qualification<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Used CCSDS AMS =
(Asynchronous Message Service) over BP/LTP<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Concluded that fully =
automatic operation of a DTN over deep space links is feasible<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Software is at tech =
readiness level 7<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Questions:<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Malcom Eris: Have there =
been BW efficiency calculations on various protocol stack options.<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SB: first pass on this =
expt is that DTN overhead is in noise compared with necessary FEC<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ME: Tictoc wg in IETf =
asking if DTN has any timing requirements<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SB: Space was OK with =
5-10 secs level.. but better might be useful<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KF: Other project (like =
aircraft) might have stricter reqs: encourage people to send info to =
tictoc mailing list (ME to send pointer to dtn interest)<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WI: How was contact plan =
infor sent to speaccraft for routing<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SB: Tried to keep it low =
risk so didn't send stuff to spacecraft but expect o do that it follow =
up<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WI:&nbsp; will a dynamic =
routing proto be needed to cope with change of plan?<BR>
&gt; &quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SB:&nbsp; actually do =
parts.. management and (more static routing)<BR>
&gt;<BR>
&gt;<BR>
&gt; _______________________________________________<BR>
&gt; dtn-interest mailing list<BR>
&gt; [email-masked]<BR>
&gt; <A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
&gt;&nbsp;&nbsp;<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9AA0B.FCA45F20--

Date: Fri, 20 Mar 2009 23:50:05 -0400
From: Will Leland <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup

Thanks for posting this info, Lloyd.

A possible glitch: the following URLs all generated
an object-not-found (404) error when I tried to access them just
now:
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt
http://www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt
http://www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt
-- Will

Lloyd Wood wrote:
> This email is intended to round up the non-final IETF 73 Minneapolis November 2009 Delay Tolerant Networking research group (DTNRG) minutes and presentations to provide information in one place in the list archive.
>
> Minutes were not submitted to the IETF in time by the chairs, so the minutes and presentations aren't officially in the IETF 73 proceedings at:
> http://www.ietf.org/proceedings/08nov/index.html
> which does not link to the hidden:
> http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
> where a number of presentations are stored:
> 0900-0905       Welcome & agenda bash   Chairs http://www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt
> 0905-0915    DTNRG document status Chairs 
> 0915-1000    Planning to finish existing documents All
> 1000-1020       Bundle Checksums        Lloyd Wood http://www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt
> 1020-1030       Ohio Univ. testbed work         Hans Kruse http://www3.ietf.org/proceedings/08nov/slides/DTNRG-2.pdf
> 1030-1040       UDP CL  Hans Kruse http://www3.ietf.org/proceedings/08nov/slides/DTNRG-3.pdf
> 1040-1050       NASA/CCSDS DTN update   Will Ivancic http://www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt
> 1050-1100       N4C/PRoPHET     Avri Doria http://www.ietf.org/proceedings/08nov/slides/DTNRG-6.ppt
> 1100-1115    Bundle encapsulation discussion  Susan Symmington 
> 1115-1129       Deep Impact Experiment  Scott Burleigh http://www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt
>
> (Scott and Lloyd presented on two separate tests of the DTN bundle protocol using spacecraft.)
>
> The draft minutes, taken by Elwyn Davies, were posted to the list by the chairs:
> http://maillists.intel-research.net/pipermail/dtn-interest/2009-February/003521.html
> but in word and pdf format - and only text is archived on the list (so, no point in sending the above powerpoints to the list). Those draft minutes are repeated at end below as text to at least provide a readable copy in the list archive. To my knowledge, there are no final minutes or comments on these draft minutes.
>
> ***
>
> Notes on DTNRG meeting @ IETF 73 Thursday 9-11.30 
>
> Highlights:
> "       We'll do a "last call" on the following documents "now," where "now" means as soon as the authors say they're ready on the list:
> "       draft-irtf-dtnrg-prophet
> "       draft-irtf-dtnrg-tcp-clayer
> "       draft-irtf-dtnrg-bundle-security
> "       draft-irtf-dtnrg-sec-overview
> "       draft-irtf-dtnrg-sdnv
> "       draft-irtf-dtnrg-bundle-previous-hop-block
> "       draft-irtf-dtnrg-cbhe
> "       A bunch of people (about 10-12) agreed to put up bundle protocol nodes on the Internet and we'll use Hans Kruse's dtnbone mailing list to co-ordinate that; we set ourselves some goals to meet before the March meeting.
> "       http://korgano.eecs.ohiou.edu/mailman/listinfo/dtnbone 
> "       Scott Burleigh reported on their experiment with a BP/LTP router running on the Deep Impact spacecraft and communicating 25 million km back to Earth
>
> Kevin Fall: Introduction
> "       Intros and agenda bashing - no changes requested
> "       Doc status (LTP RFCs now published)
> "       Announcement of standalone meeting (March 20/21 SF, hosted by Google, Logistics later)
> Stephen Farrell: Looking at drafts status
> "       Aaron Falk: Expressed wonder at number of potential RFCs
> "       Lloyd Wood: Saratoga docs future:  Saratoga base docs in Transport Area; dtnrg docs future are bundle over Saratoga.. what goes on depends on what goes on in transport area
> "       Susan Symmington:  Asked for input on retrans block.  Metadata drafts - would like them to go forward
> "       Joerg Ott:  Thinks metadata 'ontology' system is too vague for proto developers.  
> "       SF: Please start discussion on list
> "       ?: dtnbadisc.. has been implemented but not sure if author still working on it
> "       JO: dtn-appl:  will discuss with SS how to progress metadata
> "       SF: would love km to go forward 
> "       SF/JO: not sure if kutscher unicast cl is going forward
>
> SF: doc completion..
> "       Took 18months  to get RFCs.. asked EBD to shepherd bunch of docs
> "       Steve Crocker(?): useful to give feedback on new IRTF doc stream process
> "       AF: RG shepherd is responsible for pushing docs forward.. delay caused by dropped tokens.. difficulty is often on converging after review
> "       ?: talking about what happens in getting consensus on publishing - and where it is stated
>
> SF: docs ready for last call: ~6 docs
> "       SS: want previous hop block on list; also metadata docs if resolution can be achieved
> "       Scott Burleigh:  Wants compressed bundle header (CBHE) on list also
> "       SS: previous hop block is ready for last call
> "       AD: Prophet is very nearly ready - end of CY
> "       SF: Bundle sec end of CY 08
> "       SF: sec overview END OF YEAR
> "       LW: bundle checksum neds a bit more work
> "       Wes Eddy: sdnv essentially ready
> "       SB: compressed bundle header ready
> "       JO: UDP CL:  question about whether it would be good to be able to know how big bundles might be (unit of transfer)?  But doc is probably ready now - SF: took view that this shouldn't be in CL
>
>
> Lloyd Woods: Reliability - further points for discussion
> "       - scenario not covered by bundle checksum draft
> "       - presented slides
> "       - overview of DTN from a control loop PoV
> "       - asserts DTN not same as current low elasticity IPv6 state of the art - DTN needs a different approach to reliability
> "       - worked example - one bundle encrypted/integrity protected (term should be 'PCB'), other just reliability mechanism
> "       - compare how soon bundle arrives intact - in scenario exhibited insecure coperhsuite reliability one arrives first
> "       - conclusion: need to provide a combination confidentiality+ reliability mode to allow for fast resends
> "       Questions:
> "       SF: If this doesn't work already it is a bug in the docs
> "       LW: not clear that docs allow sequential application of mechanisms.. need text in docs to ensure this can happen
> "       SS: believes docs cover this
> "       LW: will think about some text and write careful notes
> "       SC: Corruption exhibited could fall into two classes:  (1) 'mother nature' induced changes would be caught by this (2) malicious changes might not be.. probably only a public key based story would be  needed
> "       LW: believes his proposal covers both cases - need both 'layers' to cover both cases
> "       KF: this kind of integrity check might not work with situations are using FEC to improve reliability
> "       SF: should chat with SS and work through docs to ensure cases are covered.
> "       KF: remember Fec case
> "       LW: Picture on how a convergence layer should support reliability. 
> "       LW/KF: No doc tells about what bundle proto expects from CLs
> "       Wes Eddy:
> "       Hans Kruse: Want to be careful about what goes in CL and what goes in bundle - architecturally common reqs need to go in higher layers or maybe in a service proto
> "       KF: might end uo with a shim at bottom of bundle proto to manage 
> "       Gory Fairhurst:  Do we have to do it in UDP CL?  IETF says you have to explain how you do all the things that UDP doesn't do for you
> "       KF: UDP draft has pointer to the RFC that talks about this story
> "       LW: reporting on reliability problems experienced in transferring images from satellite (as reported in Time magazine)
> "       KF et al: Origin of Orbital Internet phrase
>
> Hans Kruse: Dtnbone - test systems at OU
> "       NASA starting to use test environment as a cheaper alternative to real satellotes
> "       ION end points shortly available for trials
> "       Firefox plugin available to give access to ION web proxy 
> "       ION uses a different TCP CL - uses two TCP connections - NAT issues.. bundle relay helps
> "       No DNS mechanims yet.. so naming issues - wiki available to manage naming issues
> "       May get DTN2 nodes available in testbed soon.to help with tests
> "       network management is being thought about
> "       needs resources to maintain internal security/integrity! (war story!)
> "       Mailing list available - see slide
> "       Questions
> "       Will Ivancic: Is compact routing available?
> "       HK: yes - routing a focus in near future
> "       KF: (asking AF) Would this be something that could be factored into Geni?
> "       AF: Are you bringing infrastructure or expertise to table?
> "       HK: both
> "       AF: so would be good in Geni.  Geni looking at resource allocation interfaces 
> "       HK: that would be good as don't want to spend time on that.
> "       SF: Can anybody else consider putting up bundle agents?  How many exist at the moment?
> "       (count was around 10)
> "       HK: Send mail to HK to inform him of publically available nodes.
> "       SC: Public net would be very useful
> "       HK: Good to have a directory
> "       JO: Would be good to have something more than pings.. maybe a camera.. they have that in their net.. will have a 2.6.0 web server soon
> "       HK: good to have different sorts of traffic flying around
> "       AF: interesting to have nodes on different types of network as well as sorts of connectivity
> "       KF: PlanetLab stil has a DTN project.. also look at using lambda mechanisms.. also DARPA have stuf on transmitting VoIP over DTN (!)
> "       AD: N4C will want to connect to Geni
> "       SF/AD: might have  a 'funny' network connected during summer trials
> "       KF: Don't forget Massachusetts folk doing diesel net etc
> "       SF: register to dtnbone mailing list if can contribute
> "       SF: a goal would be useful
> "       KF/HK: see if can exchange a ping between 6 sites by march - using at least 2 different implementations and different CLs.
>
> Hans Kruse: UDP CL
> "       00 draft out now
> "       Why bundle protocol overUDP (rather than directly over IP)?; Does it meet pseudo-reliable assumption in RFC 5050; Do we need Ack and retransmission
> "       Questions:
> "       KF: Doesn't believe 5050 really requires pseudo-reliability
> "       Bob Cole:  Maybe nodes don't want to acknowledge their existence
> "       KF: Use UDP if don't care about acks or reliability
> "       HK: Suggest that should not feed UDP CL with segments that need further fragmentation; Would like to avid complicating the CL with further frag capabilities; UDP lite options: Suggest that should *not* disable checksums in LTP.. but might be useful for bundles
> "       WE: why UDP and not IP?  Getting through NATs is not really helpful for DTNs.  If really worried about size of packet than UDP header could be an issue.
> "       SB: Think about providing hints from bundle layer to CL (system?) about what sort of CL would be preferred.
> "       HK: shim talked about earlier might be a good solution. Bundle agent would have to pick between options
> "       LW: IPv6 doesn't allow turning off UDP checksum. Would have to use UDP lite if want to anoid reliability enforcemnet
> "       KF: wants to avoid having realiabiluty mechanisms imposed in it.  If bundle already has internal protection against bit errors then don't want to use alternatives as well
> "       GF: UDP lite is the right solution for this
> "       HK: New RFC 5450(?) tells about protecting networks from injudicious use of UDP.  Need to adhere to guidelines so that we don't get in trouble.  Need to add some text to doc guidelines.
> "       GF: RFC says must do congestion control if doing very large transfers.  PWE wg has a 'shut up' solution.. should investigate.  
> "       KF/GF: Could work over DCCP instead for working over Internet?  RFC says we ought to use it.
> "       HK: because we don't always have control loops then DCCP might not be relevant.  UDP would still be needed.
> "       LW: Look at Saratoga implementation which has studied a number of these issues.
> "       SF: Please review draft
>
> Will Ivancic: NASA update
> "       Discussing test plan
> "       UK-DMC implementation with partial DTN implementation; Learnt checksums were very useful.. spacecraft added MD5 checksums.. checked manually on ground
> "       NASA flight readiness by 2011 plan; trying to get operations people involved; Building a Multi-center DTN Engineering Testbed (DEN)
> "       Hoping to have a gateway from NASA network to dtnbone
> "       Description of CCSDS  - inter-governmental standards org - has DTN wg working on how to adapt bundle protocol and LTP for space work (assuming they are deemed suitable)
>
> Avri Doria: N4C report
> "       PRoPHEt update.. more or less ready for experimental status; needs a bit about how to set parameters to get best out of proto in various scenarios
> "       will be doing simulations to see how values should be adjusted
> "       emulation network being created
> "       Simulation status - some PRoPHET 'bashing' in papers.. need to investigate whether this is reproducible and to determine how we can fix any problems 
>
> Susan Symmington: Bundle-in-Bundle encapsulation (no slides)
> "       Reporting on recent teleconf
> "       3 use cases
> "       may want to send bundle from cache to late joining uses - need to encapsulate to avoid being resent to all previous recipients whe using multicast destination
> "       resend custody bundle to particular recipient
> "       tunnels
> "       draft suggested using custody records but not possible; current conclusion is that encapsulation is now an application issue; doesn't really affect bundle protocol; draft just needs to say how to do encapsulations; but may need to have new feature in bundle proto - 'diversion'
> "       Questions:
> "       KF: Not clear that multicast case is really so. Routing tables may be able to suppress retransmissions - people using information layers on top may nit need this
> "       SS: need two docs: ID for encap that is application layer and ID for specifying diverting and receiving bundles
> "       SC: Suppose you view all attempts at multicasting as partial - then you would get the sending to an extra member for free - each attempt just sends to a subset of members.. conceptual view
> "       AD: Maybe tied in with need to divert bundles into alternative routing protos.
> "       SB: Maybe think of b-in-b as a different CL.
>
>
> Scott Burleigh: First look at Deep Impact DTN Experiment
> "       Deep Impact between tasks so available for tests
> "       Demonstrating ION and getting technology readiness 7/8 qualification
> "       Used CCSDS AMS (Asynchronous Message Service) over BP/LTP
> "       Concluded that fully automatic operation of a DTN over deep space links is feasible
> "       Software is at tech readiness level 7
> "       Questions:
> "       Malcom Eris: Have there been BW efficiency calculations on various protocol stack options.
> "       SB: first pass on this expt is that DTN overhead is in noise compared with necessary FEC
> "       ME: Tictoc wg in IETf asking if DTN has any timing requirements
> "       SB: Space was OK with 5-10 secs level.. but better might be useful
> "       KF: Other project (like aircraft) might have stricter reqs: encourage people to send info to tictoc mailing list (ME to send pointer to dtn interest)
> "       WI: How was contact plan infor sent to speaccraft for routing
> "       SB: Tried to keep it low risk so didn't send stuff to spacecraft but expect o do that it follow up
> "       WI:  will a dynamic routing proto be needed to cope with change of plan?
> "       SB:  actually do parts.. management and (more static routing)
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

Date: Fri, 20 Mar 2009 19:25:20 +0000
To: [email-masked]
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup

This email is intended to round up the non-final IETF 73 Minneapolis November 2009 Delay Tolerant Networking research group (DTNRG) minutes and presentations to provide information in one place in the list archive.

Minutes were not submitted to the IETF in time by the chairs, so the minutes and presentations aren't officially in the IETF 73 proceedings at:
http://www.ietf.org/proceedings/08nov/index.html
which does not link to the hidden:
http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
where a number of presentations are stored:
0900-0905       Welcome & agenda bash   Chairs http://www3.ietf.org/proceedings/08nov/slides/DTNRG-0.ppt
0905-0915    DTNRG document status Chairs 
0915-1000    Planning to finish existing documents All
1000-1020       Bundle Checksums        Lloyd Wood http://www3.ietf.org/proceedings/08nov/slides/DTNRG-1.ppt
1020-1030       Ohio Univ. testbed work         Hans Kruse http://www3.ietf.org/proceedings/08nov/slides/DTNRG-2.pdf
1030-1040       UDP CL  Hans Kruse http://www3.ietf.org/proceedings/08nov/slides/DTNRG-3.pdf
1040-1050       NASA/CCSDS DTN update   Will Ivancic http://www.ietf.org/proceedings/08nov/slides/DTNRG-5.ppt
1050-1100       N4C/PRoPHET     Avri Doria http://www.ietf.org/proceedings/08nov/slides/DTNRG-6.ppt
1100-1115    Bundle encapsulation discussion  Susan Symmington 
1115-1129       Deep Impact Experiment  Scott Burleigh http://www3.ietf.org/proceedings/08nov/slides/DTNRG-4.ppt

(Scott and Lloyd presented on two separate tests of the DTN bundle protocol using spacecraft.)

The draft minutes, taken by Elwyn Davies, were posted to the list by the chairs:
http://maillists.intel-research.net/pipermail/dtn-interest/2009-February/003521.html
but in word and pdf format - and only text is archived on the list (so, no point in sending the above powerpoints to the list). Those draft minutes are repeated at end below as text to at least provide a readable copy in the list archive. To my knowledge, there are no final minutes or comments on these draft minutes.

***

Notes on DTNRG meeting @ IETF 73 Thursday 9-11.30 

Highlights:
"       We'll do a "last call" on the following documents "now," where "now" means as soon as the authors say they're ready on the list:
"       draft-irtf-dtnrg-prophet
"       draft-irtf-dtnrg-tcp-clayer
"       draft-irtf-dtnrg-bundle-security
"       draft-irtf-dtnrg-sec-overview
"       draft-irtf-dtnrg-sdnv
"       draft-irtf-dtnrg-bundle-previous-hop-block
"       draft-irtf-dtnrg-cbhe
"       A bunch of people (about 10-12) agreed to put up bundle protocol nodes on the Internet and we'll use Hans Kruse's dtnbone mailing list to co-ordinate that; we set ourselves some goals to meet before the March meeting.
"       http://korgano.eecs.ohiou.edu/mailman/listinfo/dtnbone 
"       Scott Burleigh reported on their experiment with a BP/LTP router running on the Deep Impact spacecraft and communicating 25 million km back to Earth

Kevin Fall: Introduction
"       Intros and agenda bashing - no changes requested
"       Doc status (LTP RFCs now published)
"       Announcement of standalone meeting (March 20/21 SF, hosted by Google, Logistics later)
Stephen Farrell: Looking at drafts status
"       Aaron Falk: Expressed wonder at number of potential RFCs
"       Lloyd Wood: Saratoga docs future:  Saratoga base docs in Transport Area; dtnrg docs future are bundle over Saratoga.. what goes on depends on what goes on in transport area
"       Susan Symmington:  Asked for input on retrans block.  Metadata drafts - would like them to go forward
"       Joerg Ott:  Thinks metadata 'ontology' system is too vague for proto developers.  
"       SF: Please start discussion on list
"       ?: dtnbadisc.. has been implemented but not sure if author still working on it
"       JO: dtn-appl:  will discuss with SS how to progress metadata
"       SF: would love km to go forward 
"       SF/JO: not sure if kutscher unicast cl is going forward

SF: doc completion..
"       Took 18months  to get RFCs.. asked EBD to shepherd bunch of docs
"       Steve Crocker(?): useful to give feedback on new IRTF doc stream process
"       AF: RG shepherd is responsible for pushing docs forward.. delay caused by dropped tokens.. difficulty is often on converging after review
"       ?: talking about what happens in getting consensus on publishing - and where it is stated

SF: docs ready for last call: ~6 docs
"       SS: want previous hop block on list; also metadata docs if resolution can be achieved
"       Scott Burleigh:  Wants compressed bundle header (CBHE) on list also
"       SS: previous hop block is ready for last call
"       AD: Prophet is very nearly ready - end of CY
"       SF: Bundle sec end of CY 08
"       SF: sec overview END OF YEAR
"       LW: bundle checksum neds a bit more work
"       Wes Eddy: sdnv essentially ready
"       SB: compressed bundle header ready
"       JO: UDP CL:  question about whether it would be good to be able to know how big bundles might be (unit of transfer)?  But doc is probably ready now - SF: took view that this shouldn't be in CL

Lloyd Woods: Reliability - further points for discussion
"       - scenario not covered by bundle checksum draft
"       - presented slides
"       - overview of DTN from a control loop PoV
"       - asserts DTN not same as current low elasticity IPv6 state of the art - DTN needs a different approach to reliability
"       - worked example - one bundle encrypted/integrity protected (term should be 'PCB'), other just reliability mechanism
"       - compare how soon bundle arrives intact - in scenario exhibited insecure coperhsuite reliability one arrives first
"       - conclusion: need to provide a combination confidentiality+ reliability mode to allow for fast resends
"       Questions:
"       SF: If this doesn't work already it is a bug in the docs
"       LW: not clear that docs allow sequential application of mechanisms.. need text in docs to ensure this can happen
"       SS: believes docs cover this
"       LW: will think about some text and write careful notes
"       SC: Corruption exhibited could fall into two classes:  (1) 'mother nature' induced changes would be caught by this (2) malicious changes might not be.. probably only a public key based story would be  needed
"       LW: believes his proposal covers both cases - need both 'layers' to cover both cases
"       KF: this kind of integrity check might not work with situations are using FEC to improve reliability
"       SF: should chat with SS and work through docs to ensure cases are covered.
"       KF: remember Fec case
"       LW: Picture on how a convergence layer should support reliability. 
"       LW/KF: No doc tells about what bundle proto expects from CLs
"       Wes Eddy:
"       Hans Kruse: Want to be careful about what goes in CL and what goes in bundle - architecturally common reqs need to go in higher layers or maybe in a service proto
"       KF: might end uo with a shim at bottom of bundle proto to manage 
"       Gory Fairhurst:  Do we have to do it in UDP CL?  IETF says you have to explain how you do all the things that UDP doesn't do for you
"       KF: UDP draft has pointer to the RFC that talks about this story
"       LW: reporting on reliability problems experienced in transferring images from satellite (as reported in Time magazine)
"       KF et al: Origin of Orbital Internet phrase

Hans Kruse: Dtnbone - test systems at OU
"       NASA starting to use test environment as a cheaper alternative to real satellotes
"       ION end points shortly available for trials
"       Firefox plugin available to give access to ION web proxy 
"       ION uses a different TCP CL - uses two TCP connections - NAT issues.. bundle relay helps
"       No DNS mechanims yet.. so naming issues - wiki available to manage naming issues
"       May get DTN2 nodes available in testbed soon.to help with tests
"       network management is being thought about
"       needs resources to maintain internal security/integrity! (war story!)
"       Mailing list available - see slide
"       Questions
"       Will Ivancic: Is compact routing available?
"       HK: yes - routing a focus in near future
"       KF: (asking AF) Would this be something that could be factored into Geni?
"       AF: Are you bringing infrastructure or expertise to table?
"       HK: both
"       AF: so would be good in Geni.  Geni looking at resource allocation interfaces 
"       HK: that would be good as don't want to spend time on that.
"       SF: Can anybody else consider putting up bundle agents?  How many exist at the moment?
"       (count was around 10)
"       HK: Send mail to HK to inform him of publically available nodes.
"       SC: Public net would be very useful
"       HK: Good to have a directory
"       JO: Would be good to have something more than pings.. maybe a camera.. they have that in their net.. will have a 2.6.0 web server soon
"       HK: good to have different sorts of traffic flying around
"       AF: interesting to have nodes on different types of network as well as sorts of connectivity
"       KF: PlanetLab stil has a DTN project.. also look at using lambda mechanisms.. also DARPA have stuf on transmitting VoIP over DTN (!)
"       AD: N4C will want to connect to Geni
"       SF/AD: might have  a 'funny' network connected during summer trials
"       KF: Don't forget Massachusetts folk doing diesel net etc
"       SF: register to dtnbone mailing list if can contribute
"       SF: a goal would be useful
"       KF/HK: see if can exchange a ping between 6 sites by march - using at least 2 different implementations and different CLs.

Hans Kruse: UDP CL
"       00 draft out now
"       Why bundle protocol overUDP (rather than directly over IP)?; Does it meet pseudo-reliable assumption in RFC 5050; Do we need Ack and retransmission
"       Questions:
"       KF: Doesn't believe 5050 really requires pseudo-reliability
"       Bob Cole:  Maybe nodes don't want to acknowledge their existence
"       KF: Use UDP if don't care about acks or reliability
"       HK: Suggest that should not feed UDP CL with segments that need further fragmentation; Would like to avid complicating the CL with further frag capabilities; UDP lite options: Suggest that should *not* disable checksums in LTP.. but might be useful for bundles
"       WE: why UDP and not IP?  Getting through NATs is not really helpful for DTNs.  If really worried about size of packet than UDP header could be an issue.
"       SB: Think about providing hints from bundle layer to CL (system?) about what sort of CL would be preferred.
"       HK: shim talked about earlier might be a good solution. Bundle agent would have to pick between options
"       LW: IPv6 doesn't allow turning off UDP checksum. Would have to use UDP lite if want to anoid reliability enforcemnet
"       KF: wants to avoid having realiabiluty mechanisms imposed in it.  If bundle already has internal protection against bit errors then don't want to use alternatives as well
"       GF: UDP lite is the right solution for this
"       HK: New RFC 5450(?) tells about protecting networks from injudicious use of UDP.  Need to adhere to guidelines so that we don't get in trouble.  Need to add some text to doc guidelines.
"       GF: RFC says must do congestion control if doing very large transfers.  PWE wg has a 'shut up' solution.. should investigate.  
"       KF/GF: Could work over DCCP instead for working over Internet?  RFC says we ought to use it.
"       HK: because we don't always have control loops then DCCP might not be relevant.  UDP would still be needed.
"       LW: Look at Saratoga implementation which has studied a number of these issues.
"       SF: Please review draft

Will Ivancic: NASA update
"       Discussing test plan
"       UK-DMC implementation with partial DTN implementation; Learnt checksums were very useful.. spacecraft added MD5 checksums.. checked manually on ground
"       NASA flight readiness by 2011 plan; trying to get operations people involved; Building a Multi-center DTN Engineering Testbed (DEN)
"       Hoping to have a gateway from NASA network to dtnbone
"       Description of CCSDS  - inter-governmental standards org - has DTN wg working on how to adapt bundle protocol and LTP for space work (assuming they are deemed suitable)

Avri Doria: N4C report
"       PRoPHEt update.. more or less ready for experimental status; needs a bit about how to set parameters to get best out of proto in various scenarios
"       will be doing simulations to see how values should be adjusted
"       emulation network being created
"       Simulation status - some PRoPHET 'bashing' in papers.. need to investigate whether this is reproducible and to determine how we can fix any problems 

Susan Symmington: Bundle-in-Bundle encapsulation (no slides)
"       Reporting on recent teleconf
"       3 use cases
"       may want to send bundle from cache to late joining uses - need to encapsulate to avoid being resent to all previous recipients whe using multicast destination
"       resend custody bundle to particular recipient
"       tunnels
"       draft suggested using custody records but not possible; current conclusion is that encapsulation is now an application issue; doesn't really affect bundle protocol; draft just needs to say how to do encapsulations; but may need to have new feature in bundle proto - 'diversion'
"       Questions:
"       KF: Not clear that multicast case is really so. Routing tables may be able to suppress retransmissions - people using information layers on top may nit need this
"       SS: need two docs: ID for encap that is application layer and ID for specifying diverting and receiving bundles
"       SC: Suppose you view all attempts at multicasting as partial - then you would get the sending to an extra member for free - each attempt just sends to a subset of members.. conceptual view
"       AD: Maybe tied in with need to divert bundles into alternative routing protos.
"       SB: Maybe think of b-in-b as a different CL.

Scott Burleigh: First look at Deep Impact DTN Experiment
"       Deep Impact between tasks so available for tests
"       Demonstrating ION and getting technology readiness 7/8 qualification
"       Used CCSDS AMS (Asynchronous Message Service) over BP/LTP
"       Concluded that fully automatic operation of a DTN over deep space links is feasible
"       Software is at tech readiness level 7
"       Questions:
"       Malcom Eris: Have there been BW efficiency calculations on various protocol stack options.
"       SB: first pass on this expt is that DTN overhead is in noise compared with necessary FEC
"       ME: Tictoc wg in IETf asking if DTN has any timing requirements
"       SB: Space was OK with 5-10 secs level.. but better might be useful
"       KF: Other project (like aircraft) might have stricter reqs: encourage people to send info to tictoc mailing list (ME to send pointer to dtn interest)
"       WI: How was contact plan infor sent to speaccraft for routing
"       SB: Tried to keep it low risk so didn't send stuff to spacecraft but expect o do that it follow up
"       WI:  will a dynamic routing proto be needed to cope with change of plan?
"       SB:  actually do parts.. management and (more static routing)

From: Peter Lovell <[email-masked]>
To: Susan <[email-masked]>, Stephen Farrell <[email-masked]>, Peter Lovell <[email-masked]>, Howard Weiss <[email-masked]>
Date: Thu, 19 Mar 2009 22:41:45 -0700
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] more BSP comments and a question about ESB

Hi Susan,

On Fri, Mar 20, 2009, Symington, Susan F. <[email-masked]> wrote:

>Stephen, Howie, and Peter,
>
>I tried to do a really thorough read-through of the Bundle Security
>Protocol on the plane and, as a result, I have some edits marked on my
>hard-copy that I would like to give to Peter instead of listing all of
>them here, since most are editorial.  However, I do have a few issues/
>comments that I want to point out on the list. Before launching into my
>comments, I want to reiterate once again what a good job Peter has done
>in specifying all the intricacies related to these blocks.
>
>1)In the most recent Bundle Security protocol a new security block
>(Extension Security Block-ESB) was defined as a way to encrypt and
>provide integrity for extension blocks in bundles (like the metadata
>security block, the previous hop block, the retransmission block). As
>written now, the draft says that failure to decrypt an ESB means that
>the bundle must be discarded. Stephen asks if we really want it to be
>this way and my response is no, I don't think we want it to be this way.
>
>If a node is the security-destination for an ESB but the content of the
>ESB can't be decrypted properly, then I think what we want is to require
>that at least one ESB of each type (e.g. metadata) for which the node is
>a security destination be able to decrypt properly and if one does, all
>is well.  In that case it doesn't matter if there are other ESBs of that
>type (eg metadata) that don't decrypt properly.  This is the same way
>that we treat receipt of a bundle with multiple BABs.
>
>There is a field in the ESB that can be used to indicate the type of
>extension block being protected. Unfortunately, keeping this field in
>the clear is a small security risk (since it shows in plaintext a field
>that is encrypted in the bundle).  If it is not kept in the clear,
>however, then there is no way to determine if more than one of these
>bundles must be decrypted.  For example, if both a previous hop block
>and a metadata block are protected, there is no way to tell this from
>the case in which two metadata blocks are protected (unless this field
>is used). I think we need language that requires that this field be used
>to identify blocks of the same type so that a node knows whether or not
>it is okay if a given ESB doesn't decrypt properly.  If the field
>doesn't exist, the assumption is that it is the only block of its type
>and so must decrypt if the node is a security destination for it.  If
>the field does exist and it exists in more than one block for which the
>node is a security destination, then only one of the ESBs of that type
>has to decrypt.  If you have a better way to approach this I'm open to
>it; I just think we need to address this ambiguity somehow.

I think that the can't-be-processed mechanism is inappropriate for
security blocks. It was originally intended to deal with extensions that
weren't known, rather than ones that are well-known but for which we
don't have the keys.

There is also no definition anywhere to say what "processed" means. I
remember one spirited discussion that suggested that an intermediate
node that didn't implement BSP and therefore didn't understand the
security blocks should apply these flags and discard the bundle if the
flag was set.

There's a problem with the notion that it's OK if you can decrypt at
least one. That scheme works with BAB because it has a single purpose,
and there are standard scenarios for multiple instances. But ESB can
encrypt several blocks of the same kind or of different kinds, and they
might or might not have some relation to one another (not in the BSP
"correlated blocks" sense, which is for security correlations). So we
really have no good way to formulate a discard rule and therefore
formulating one would be bad.

I think we resolve the ambiguity by saying we don't delete the bundle.

>2) In a related issue, the BAB, PIB, and PCB sections all state that for
>these blocks, the block processing control flags value can be set to
>whatever values are required by local policy. One of the block
>processing control flags is "Delete bundle if block can't be processed"
>and another of the flags is "Discard block if it can't be processed" .
>In the case in which, for example, two BABs are in a bundle, only one of
>which can be processed because the receiving node does not have the
>right key to process the other one, we don't want the bundle to be
>deleted. Likewise, if two different metadata blocks are encrypted in the
>bundle and the node has the key to decrypt one but not the other, this
>should be okay. However, if either of the above flags is set then what
>should the node do?  Should the node honor what the flag is telling it
>to do (delete/discard) or what the BSP text is telling it to do
>(validate the bundle)?  We need to add text that clarifies the expected
>behavior under these conditions. Right now it is ambiguous.

same as above ... clarify by say we don't

>3) In the BAB section (page 13), we say that the BAB SHOULD NOT contain
>a security-destination. I think we should change this to MAY NOT. My
>rationale for this proposed change is that SHOULD NOT contradicts what
>we later say in the security considerations section: "When asymmetric
>BAB ciphersuites are used, the security destination field SHOULD
>therefore be included in the BAB." I think we also need to add some text
>somewhere that says that if the sec-dest is present in the BAB but it
>does not match the EID of the receiving node, the BAB MUST fail to
>authenticate the bundle.

This actually presents an interesting scenario. Consider our standard A-
B-C-D node setup, and specifically node B that doesn't implement BSP. If
it receives a bundle with BAB it will forward that BAB on to C, not
knowing any better. And the bundle will fail to verify at C. C probably
doesn't require BABs since B doesn't provide them and the spec is
delightfully mum about this particular case.

OTOH, if B implements BSP but no ciphersuites then it would know to
strip the BAB before forwarding to C and life would be good.

>4) Is the term "payload-related security blocks" well-defined?  I don't
>think so (or perhaps I missed it). Right now the only such block we have
>is the PIB, right?  Do you mean, by this term, blocks that get encrypted
>by a ciphersuite that also encrypts the payload?  This needs to be defined.

It's payload, PIB and PCB. I'll add a definition.

>5) The ESB section (2.5) doesn't use the same template as the sections
>for the other blocks, but it should.  For example, it fails to mention
>the block processing control flags, the ciphersuite ID, the correlator
>field, etc.

Hhmmm. I thought all the pieces had been covered, as I cloned the text.
I'll fix it.

>6) Do we need a "key ID" item in the list of possible security parameters?

No. That goes into the "key information" item.

>Like I said, I have other small edits on my hard copy that I can give you.

Hard-copy wold be good.

Thanks.....Peter

From: "Symington, Susan F." <[email-masked]>
To: Stephen Farrell <[email-masked]>, Peter Lovell <[email-masked]>, Howard Weiss <[email-masked]>
Date: Fri, 20 Mar 2009 00:30:27 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn interest <[email-masked]>
Subject: [dtn-interest] more BSP comments and a question about ESB

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC022BC3F440IMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stephen, Howie, and Peter,

I tried to do a really thorough read-through of the Bundle Security Protoco=
l on the plane and, as a result, I have some edits marked on my hard-copy t=
hat I would like to give to Peter instead of listing all of them here, sinc=
e most are editorial.  However, I do have a few issues/comments that I want=
 to point out on the list. Before launching into my comments, I want to rei=
terate once again what a good job Peter has done in specifying all the intr=
icacies related to these blocks.

1)In the most recent Bundle Security protocol a new security block (Extensi=
on Security Block-ESB) was defined as a way to encrypt and provide integrit=
y for extension blocks in bundles (like the metadata security block, the pr=
evious hop block, the retransmission block). As written now, the draft says=
 that failure to decrypt an ESB means that the bundle must be discarded. St=
ephen asks if we really want it to be this way and my response is no, I don=
't think we want it to be this way.

If a node is the security-destination for an ESB but the content of the ESB=
 can't be decrypted properly, then I think what we want is to require that =
at least one ESB of each type (e.g. metadata) for which the node is a secur=
ity destination be able to decrypt properly and if one does, all is well.  =
In that case it doesn't matter if there are other ESBs of that type (eg met=
adata) that don't decrypt properly.  This is the same way that we treat rec=
eipt of a bundle with multiple BABs.

There is a field in the ESB that can be used to indicate the type of extens=
ion block being protected. Unfortunately, keeping this field in the clear i=
s a small security risk (since it shows in plaintext a field that is encryp=
ted in the bundle).  If it is not kept in the clear, however, then there is=
 no way to determine if more than one of these bundles must be decrypted.  =
For example, if both a previous hop block and a metadata block are protecte=
d, there is no way to tell this from the case in which two metadata blocks =
are protected (unless this field is used). I think we need language that re=
quires that this field be used to identify blocks of the same type so that =
a node knows whether or not it is okay if a given ESB doesn't decrypt prope=
rly.  If the field doesn't exist, the assumption is that it is the only blo=
ck of its type and so must decrypt if the node is a security destination fo=
r it.  If the field does exist and it exists in more than one block for whi=
ch the node is a security destination, then only one of the ESBs of that ty=
pe has to decrypt.  If you have a better way to approach this I'm open to i=
t; I just think we need to address this ambiguity somehow.

2) In a related issue, the BAB, PIB, and PCB sections all state that for th=
ese blocks, the block processing control flags value can be set to whatever=
 values are required by local policy. One of the block processing control f=
lags is "Delete bundle if block can't be processed" and another of the flag=
s is "Discard block if it can't be processed" . In the case in which, for e=
xample, two BABs are in a bundle, only one of which can be processed becaus=
e the receiving node does not have the right key to process the other one, =
we don't want the bundle to be deleted. Likewise, if two different metadata=
 blocks are encrypted in the bundle and the node has the key to decrypt one=
 but not the other, this should be okay. However, if either of the above fl=
ags is set then what should the node do?  Should the node honor what the fl=
ag is telling it to do (delete/discard) or what the BSP text is telling it =
to do (validate the bundle)?  We need to add text that clarifies the expect=
ed behavior under these conditions. Right now it is ambiguous.

3) In the BAB section (page 13), we say that the BAB SHOULD NOT contain a s=
ecurity-destination. I think we should change this to MAY NOT. My rationale=
 for this proposed change is that SHOULD NOT contradicts what we later say =
in the security considerations section: "When asymmetric BAB ciphersuites a=
re used, the security destination field SHOULD therefore be included in the=
 BAB." I think we also need to add some text somewhere that says that if th=
e sec-dest is present in the BAB but it does not match the EID of the recei=
ving node, the BAB MUST fail to authenticate the bundle.

4) Is the term "payload-related security blocks" well-defined?  I don't thi=
nk so (or perhaps I missed it). Right now the only such block we have is th=
e PIB, right?  Do you mean, by this term, blocks that get encrypted by a ci=
phersuite that also encrypts the payload?  This needs to be defined.

5) The ESB section (2.5) doesn't use the same template as the sections for =
the other blocks, but it should.  For example, it fails to mention the bloc=
k processing control flags, the ciphersuite ID, the correlator field, etc.

6) Do we need a "key ID" item in the list of possible security parameters?

Like I said, I have other small edits on my hard copy that I can give you.

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

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC022BC3F440IMCMBX2MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2=3D=
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"http://sc=
hemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.micro=
soft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/=
xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:u=
dc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org=
/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/=
2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"=
http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.micro=
soft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-in=
stance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udc=
xf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http:/=
/schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.micr=
osoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft=
.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/o=
ffice/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package=
/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats.org/ma=
rkup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/200=
4/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/re=
lationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" xm=
lns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types" xml=
ns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messages" x=
mlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" x=
mlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Publis=
hedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" x=
mlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:86198211;
	mso-list-type:hybrid;
	mso-list-template-ids:1243378998 67698705 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:792944498;
	mso-list-type:hybrid;
	mso-list-template-ids:745076396 67698703 67698713 67698715 67698703 676987=
13 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:933131277;
	mso-list-type:hybrid;
	mso-list-template-ids:849769520 67698705 67698713 67698715 67698703 676987=
13 67698715 67698703 67698713 67698715;}
@list l2:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3
	{mso-list-id:1211113274;
	mso-list-type:hybrid;
	mso-list-template-ids:1475794240 67698705 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l3:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4
	{mso-list-id:1318803572;
	mso-list-type:hybrid;
	mso-list-template-ids:1911440184 67698705 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l4:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l5
	{mso-list-id:1942638140;
	mso-list-type:hybrid;
	mso-list-template-ids:536012228 67698705 67698713 67698715 67698703 676987=
13 67698715 67698703 67698713 67698715;}
@list l5:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Stephen, Howie, and Peter,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I tried to do a really thorough read-through of the Bu=
ndle Security
Protocol on the plane and, as a result, I have some edits marked on my
hard-copy that I would like to give to Peter instead of listing all of them
here, since most are editorial.&nbsp; However, I do have a few issues/comme=
nts
that I want to point out on the list. Before launching into my comments, I =
want
to reiterate once again what a good job Peter has done in specifying all th=
e
intricacies related to these blocks. <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>1)In the most recent Bundle Security protocol a new se=
curity
block (Extension Security Block&#8212;ESB) was defined as a way to encrypt =
and
provide integrity for extension blocks in bundles (like the metadata securi=
ty block,
the previous hop block, the retransmission block). As written now, the draf=
t
says that failure to decrypt an ESB means that the bundle must be discarded=
.
Stephen asks if we really want it to be this way and my response is no, I
don&#8217;t think we want it to be this way.&nbsp; <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>If a node is the security-destination for an ESB but t=
he
content of the ESB can&#8217;t be decrypted properly, then I think what we =
want
is to require that at least one ESB of each type (e.g. metadata) for which =
the
node is a security destination be able to decrypt properly and if one does,=
 all
is well.&nbsp; In that case it doesn&#8217;t matter if there are other ESBs=
 of
that type (eg metadata) that don&#8217;t decrypt properly.&nbsp; This is th=
e
same way that we treat receipt of a bundle with multiple BABs.<o:p></o:p></=
p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>There is a field in the ESB that can be used to indica=
te the
type of extension block being protected. Unfortunately, keeping this field =
in
the clear is a small security risk (since it shows in plaintext a field tha=
t is
encrypted in the bundle).&nbsp; If it is not kept in the clear, however, th=
en
there is no way to determine if more than one of these bundles must be
decrypted.&nbsp; For example, if both a previous hop block and a metadata b=
lock
are protected, there is no way to tell this from the case in which two meta=
data
blocks are protected (unless this field is used). I think we need language =
that
requires that this field be used to identify blocks of the same type so tha=
t a
node knows whether or not it is okay if a given ESB doesn&#8217;t decrypt
properly.&nbsp; If the field doesn&#8217;t exist, the assumption is that it=
 is
the only block of its type and so must decrypt if the node is a security
destination for it.&nbsp; If the field does exist and it exists in more tha=
n
one block for which the node is a security destination, then only one of th=
e
ESBs of that type has to decrypt.&nbsp; If you have a better way to approac=
h
this I&#8217;m open to it; I just think we need to address this ambiguity s=
omehow.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>2) In a related issue, the BAB, PIB, and PCB sections =
all
state that for these blocks, the block processing control flags value can b=
e
set to whatever values are required by local policy. One of the block
processing control flags is &#8220;<span style=3D'font-family:"Courier New"=
'>Delete
bundle if block can't be processed&#8221; and another of the flags is &#822=
0;Discard
block if it can't be processed&#8221;</span> . In the case in which, for
example, two BABs are in a bundle, only one of which can be processed becau=
se
the receiving node does not have the right key to process the other one, we=
 don&#8217;t
want the bundle to be deleted. Likewise, if two different metadata blocks a=
re
encrypted in the bundle and the node has the key to decrypt one but not the
other, this should be okay. However, if either of the above flags is set th=
en
what should the node do?&nbsp; Should the node honor what the flag is telli=
ng
it to do (delete/discard) or what the BSP text is telling it to do (validat=
e
the bundle)?&nbsp; We need to add text that clarifies the expected behavior=
 under
these conditions. Right now it is ambiguous.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>3) In the BAB section (page 13), we say that the BAB S=
HOULD
NOT contain a security-destination. I think we should change this to MAY NO=
T.
My rationale for this proposed change is that SHOULD NOT contradicts what w=
e
later say in the security considerations section: &#8220;When asymmetric BA=
B
ciphersuites are used, the security destination field SHOULD therefore be
included in the BAB.&#8221; I think we also need to add some text somewhere=
 that
says that if the sec-dest is present in the BAB but it does not match the E=
ID
of the receiving node, the BAB MUST fail to authenticate the bundle.<o:p></=
o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>4) Is the term &#8220;payload-related security blocks&=
#8221;
well-defined?&nbsp; I don&#8217;t think so (or perhaps I missed it). Right =
now
the only such block we have is the PIB, right?&nbsp; Do you mean, by this t=
erm,
blocks that get encrypted by a ciphersuite that also encrypts the
payload?&nbsp; This needs to be defined.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>5) The ESB section (2.5) doesn&#8217;t use the same te=
mplate
as the sections for the other blocks, but it should.&nbsp; For example, it
fails to mention the block processing control flags, the ciphersuite ID, th=
e
correlator field, etc.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>6) Do we need a &#8220;key ID&#8221; item in the list =
of
possible security parameters?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Like I said, I have other small edits on my hard copy =
that I
can give you.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-susan<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
**</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>Susan
Symington</span><span style=3D'font-size:12.0pt;font-family:"Times New Roma=
n","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>The
MITRE Corporation</span><span style=3D'font-size:12.0pt;font-family:"Times =
New Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>[email-masked]</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7209
(voice)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman"=
,"serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7142
(fax)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman","=
serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
***</span><o:p></o:p></p>

</div>

</body>

</html>

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC022BC3F440IMCMBX2MITREO_--

Content-class: urn:content-classes:message
Date: Fri, 20 Mar 2009 02:41:32 -0000
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A905.610BE1D6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Henry,

(you might want to try blank lines before your reply paragraphs.
Saw your 'not communicating line', and almost missed them.)

> Generic CRC's do not provide protection against intentional =20
> modification of the data.  I think I'm just repeating myself.

We know that (and have been discussing this on the list the
past couple of years. You might want to check the archives.)

That is a feature of CRCs, not a bug. CRCs protect against
unintentional errors only.

>> Custody transfer is not useful or meaningful without the
>> custodian performing some sort of reliability check on the
>> bundle - and if the custodian does not know the secret
>> key needed to decipher a secure payload, the integrity of
>> a bundle can't be checked. A reliability check enables
>> errors to be detected, and can make custody transfer truly
>> reliable.
>
> I agree, but what's your "threat model"?  If you're proposing a CRC =20
> instead of a cryptographic hash (with appropriate and appropriately =20
< managed keys), then you're assuming no *intentional* modification of =20
> the data.  I suspect there are some scenarios where that's not a good  =

> assumption.

That's why both an outer CRC and an inner hash become needed.
Read the "bundle of problems" paper. The "threat" that CRCs
"defend" against is unintentional errors. See also Jonathan
Stone's papers, referenced in our paper.

> Our "bundle of problems" paper outlines why a reliability
> check is needed around any secure integrity cipher.
>
> =
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#b=
undle-problems
> A worked example is given in the paper.
>
> Security can't be used alone, because it doesn't offer the
> ability for all forwarding nodes to check reliability and
> do error rejection when needed.
>
> Reliability can't be used alone, because if you want security,
> reliability doesn't give it.
>
> There is a place for both.

http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum
has further details.

There's more to good protocol architecture and design
than only considering security.

L.

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

------_=_NextPart_001_01C9A905.610BE1D6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] last call comments on Bundle checksum =
-04</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Henry,<BR>
<BR>
(you might want to try blank lines before your reply paragraphs.<BR>
Saw your 'not communicating line', and almost missed them.)<BR>
<BR>
&gt; Generic CRC's do not provide protection against =
intentional&nbsp;<BR>
&gt; modification of the data.&nbsp; I think I'm just repeating =
myself.<BR>
<BR>
We know that (and have been discussing this on the list the<BR>
past couple of years. You might want to check the archives.)<BR>
<BR>
That is a feature of CRCs, not a bug. CRCs protect against<BR>
unintentional errors only.<BR>
<BR>
<BR>
&gt;&gt; Custody transfer is not useful or meaningful without the<BR>
&gt;&gt; custodian performing some sort of reliability check on the<BR>
&gt;&gt; bundle - and if the custodian does not know the secret<BR>
&gt;&gt; key needed to decipher a secure payload, the integrity of<BR>
&gt;&gt; a bundle can't be checked. A reliability check enables<BR>
&gt;&gt; errors to be detected, and can make custody transfer truly<BR>
&gt;&gt; reliable.<BR>
&gt;<BR>
&gt; I agree, but what's your &quot;threat model&quot;?&nbsp; If you're =
proposing a CRC&nbsp;<BR>
&gt; instead of a cryptographic hash (with appropriate and =
appropriately&nbsp;<BR>
&lt; managed keys), then you're assuming no *intentional* modification =
of&nbsp;<BR>
&gt; the data.&nbsp; I suspect there are some scenarios where that's not =
a good&nbsp;<BR>
&gt; assumption.<BR>
<BR>
That's why both an outer CRC and an inner hash become needed.<BR>
Read the &quot;bundle of problems&quot; paper. The &quot;threat&quot; =
that CRCs<BR>
&quot;defend&quot; against is unintentional errors. See also =
Jonathan<BR>
Stone's papers, referenced in our paper.<BR>
<BR>
&gt; Our &quot;bundle of problems&quot; paper outlines why a =
reliability<BR>
&gt; check is needed around any secure integrity cipher.<BR>
&gt;<BR>
&gt; <A =
HREF=3D"http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/inde=
x.html#bundle-problems">http://personal.ee.surrey.ac.uk/Personal/L.Wood/p=
ublications/index.html#bundle-problems</A><BR>
&gt; A worked example is given in the paper.<BR>
&gt;<BR>
&gt; Security can't be used alone, because it doesn't offer the<BR>
&gt; ability for all forwarding nodes to check reliability and<BR>
&gt; do error rejection when needed.<BR>
&gt;<BR>
&gt; Reliability can't be used alone, because if you want security,<BR>
&gt; reliability doesn't give it.<BR>
&gt;<BR>
&gt; There is a place for both.<BR>
<BR>
<A =
HREF=3D"http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum">http=
://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum</A><BR>
has further details.<BR>
<BR>
There's more to good protocol architecture and design<BR>
than only considering security.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9A905.610BE1D6--

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 19 Mar 2009 21:35:39 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

--_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6E6NDJSSCC01ndcn_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The downside to always including the checksum like that is that
if you intend to do one per-block, so that you can do something
like reliable headers with unreliable payloads, and there are a
lot of blocks chained (security block, metadata block, retrans
block, etc.), then you're putting even more bits onto the wire
than the BP itself already was.

I guess you could always include a checksum in the primary
bundle block, and that only, if you also did something like add
a "checksum block-coverage mask" SDNV to the primary bundle
block to indicate which blocks are covered and not covered, but
that'd have to stay in-sync in-transit if blocks are pasted in,
peeled off, or reordered within a bundle.

________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, March 19, 2009 10:19 PM
To: Eddy, Wesley M. (GRC-RCN0)[Verizon]
Cc: [email-masked]
Subject: RE: [dtn-interest] last call comments on Bundle checksum -04

relying on a complete parsing failure to infer that the bit
has flipped is not ideal. "sure not to match the real one" is
a probability, in fact.

Usual approach is to have a checksum field all the time, but
set its content to zero if there is no checksum to be used.
(With UDP, 1's complement and 11111111 =3D 000000000 is a workaround)

Corruption in the checksum field itself can then warn of errors.

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

-----Original Message-----
From: Eddy, Wesley M. (GRC-RCN0)[Verizon] [mailto:[email-masked]]
Sent: Fri 2009-03-20 0:43
To: Wood L Dr (Electronic Eng); [email-masked]
Cc: [email-masked]
Subject: RE: [dtn-interest] last call comments on Bundle checksum -04

Actually it *does* work, even if that bit gets corrupted.  With some
very low probability it just sacrifices the ability to send errored content
in the case where you don't care about errors and the "checksum
present" bit happens to get flipped to on.

If the bit starts as on, then there's a checksum present following the
rest of the block's fields.  When the bit flips to off, subsequent
processing is going to fail due to those extra bytes not being parseable
or a length field being wrong, and you lose a bundle that the app had
asked to be lost if errored (correct behavior).

If the bit starts as off, then there's no checksum present.  When it
flips to on, then the bundle agent receiving it will interpret whatever
follows the block as a checksum, sure not to match the real one (that
isn't present), and processing fails, so the bundle is discarded.  You
lose some data that the app said it didn't care about bit-errors in;
probably okay, given that the odds of this bit being flipped are
hopefully low in comparison to payload bits being flipped.

________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, March 19, 2009 6:48 PM
To: [email-masked]; Eddy, Wesley M. (GRC-RCN0)[Verizon]
Cc: [email-masked]
Subject: RE: [dtn-interest] last call comments on Bundle checksum -04

....

(Wes's suggestion of having a bit to indicate if a checksum
is used doesn't _quite_ work - what if that bit is corrupted?)

--_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6E6NDJSSCC01ndcn_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta content=3D"MSHTML 6.00.6001.18203" name=3D"GENERATOR">
<style title=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body ocsi=3D"x">
<div dir=3D"ltr"><font face=3D"Tahoma" color=3D"#000000" size=3D"2">The dow=
nside to always including the checksum like that is that</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">if you intend to do one p=
er-block, so that you can do something</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">like reliable headers wit=
h unreliable payloads, and there are a</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">lot of blocks chained (se=
curity block, metadata block, retrans</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">block, etc.), then you're=
&nbsp;putting even more bits onto the wire</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">than </font><font face=3D=
"tahoma" size=3D"2">the
</font><font face=3D"tahoma" size=3D"2">BP itself already was.</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">I guess you could always =
include a&nbsp;checksum in the primary</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"><font face=3D"tahoma">bun=
dle block, and that only,
</font>if you also did </font><font face=3D"tahoma" size=3D"2">something li=
ke add</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">a &quot;checksum block-co=
verage mask&quot; </font>
<font face=3D"tahoma" size=3D"2">SDNV to the primary bundle</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">block to indicate which b=
locks are covered and not covered, but</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">that'd have to stay in-sy=
nc in-transit if blocks are pasted in,</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">peeled off, or reordered =
within a bundle.</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div id=3D"divRpF172653" style=3D"DIRECTION: ltr">
<hr tabindex=3D"-1">
<font face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked] [L.Wood@s=
urrey.ac.uk]<br>
<b>Sent:</b> Thursday, March 19, 2009 10:19 PM<br>
<b>To:</b> Eddy, Wesley M. (GRC-RCN0)[Verizon]<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> RE: [dtn-interest] last call comments on Bundle checksum -0=
4<br>
</font><br>
</div>
<div></div>
<div>
<p><font size=3D"2">relying on a complete parsing failure to infer that the=
 bit<br>
has flipped is not ideal. &quot;sure not to match the real one&quot; is<br>
a probability, in fact.<br>
<br>
Usual approach is to have a checksum field all the time, but<br>
set its content to zero if there is no checksum to be used.<br>
(With UDP, 1's complement and 11111111 =3D 000000000 is a workaround)<br>
<br>
Corruption in the checksum field itself can then warn of errors.<br>
<br>
&lt;<a href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/" target=3D"_blan=
k">http://www.ee.surrey.ac.uk/Personal/L.Wood/</a>&gt;&lt;[email-masked].=
uk&gt;<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Eddy, Wesley M. (GRC-RCN0)[Verizon] [<a href=3D"mailto:wesley.m.eddy@=
nasa.gov">mailto:[email-masked]</a>]<br>
Sent: Fri 2009-03-20 0:43<br>
To: Wood L Dr (Electronic Eng); [email-masked]<br>
Cc: [email-masked]<br>
Subject: RE: [dtn-interest] last call comments on Bundle checksum -04<br>
<br>
Actually it *does* work, even if that bit gets corrupted.&nbsp; With some<b=
r>
very low probability it just sacrifices the ability to send errored content=
<br>
in the case where you don't care about errors and the &quot;checksum<br>
present&quot; bit happens to get flipped to on.<br>
<br>
If the bit starts as on, then there's a checksum present following the<br>
rest of the block's fields.&nbsp; When the bit flips to off, subsequent<br>
processing is going to fail due to those extra bytes not being parseable<br=
>
or a length field being wrong, and you lose a bundle that the app had<br>
asked to be lost if errored (correct behavior).<br>
<br>
If the bit starts as off, then there's no checksum present.&nbsp; When it<b=
r>
flips to on, then the bundle agent receiving it will interpret whatever<br>
follows the block as a checksum, sure not to match the real one (that<br>
isn't present), and processing fails, so the bundle is discarded.&nbsp; You=
<br>
lose some data that the app said it didn't care about bit-errors in;<br>
probably okay, given that the odds of this bit being flipped are<br>
hopefully low in comparison to payload bits being flipped.<br>
<br>
<br>
________________________________<br>
From: [email-masked] [[email-masked]]<br>
Sent: Thursday, March 19, 2009 6:48 PM<br>
To: [email-masked]; Eddy, Wesley M. (GRC-RCN0)[Verizon]<br>
Cc: [email-masked]<br>
Subject: RE: [dtn-interest] last call comments on Bundle checksum -04<br>
<br>
<br>
....<br>
<br>
(Wes's suggestion of having a bit to indicate if a checksum<br>
is used doesn't _quite_ work - what if that bit is corrupted?)<br>
<br>
<br>
</font></p>
</div>
</body>
</html>

--_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6E6NDJSSCC01ndcn_--

Content-class: urn:content-classes:message
Date: Fri, 20 Mar 2009 02:19:14 -0000
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A902.43CFBB6B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

relying on a complete parsing failure to infer that the bit
has flipped is not ideal. "sure not to match the real one" is
a probability, in fact.

Usual approach is to have a checksum field all the time, but
set its content to zero if there is no checksum to be used.
(With UDP, 1's complement and 11111111 =3D 000000000 is a workaround)

Corruption in the checksum field itself can then warn of errors.

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

-----Original Message-----
From: Eddy, Wesley M. (GRC-RCN0)[Verizon] =
[mailto:[email-masked]]
Sent: Fri 2009-03-20 0:43
To: Wood L Dr (Electronic Eng); [email-masked]
Cc: [email-masked]
Subject: RE: [dtn-interest] last call comments on Bundle checksum -04
=20
Actually it *does* work, even if that bit gets corrupted.  With some
very low probability it just sacrifices the ability to send errored =
content
in the case where you don't care about errors and the "checksum
present" bit happens to get flipped to on.

If the bit starts as on, then there's a checksum present following the
rest of the block's fields.  When the bit flips to off, subsequent
processing is going to fail due to those extra bytes not being parseable
or a length field being wrong, and you lose a bundle that the app had
asked to be lost if errored (correct behavior).

If the bit starts as off, then there's no checksum present.  When it
flips to on, then the bundle agent receiving it will interpret whatever
follows the block as a checksum, sure not to match the real one (that
isn't present), and processing fails, so the bundle is discarded.  You
lose some data that the app said it didn't care about bit-errors in;
probably okay, given that the odds of this bit being flipped are
hopefully low in comparison to payload bits being flipped.

________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, March 19, 2009 6:48 PM
To: [email-masked]; Eddy, Wesley M. (GRC-RCN0)[Verizon]
Cc: [email-masked]
Subject: RE: [dtn-interest] last call comments on Bundle checksum -04

....

(Wes's suggestion of having a bit to indicate if a checksum
is used doesn't _quite_ work - what if that bit is corrupted?)

------_=_NextPart_001_01C9A902.43CFBB6B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] last call comments on Bundle checksum =
-04</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>relying on a complete parsing failure to infer that =
the bit<BR>
has flipped is not ideal. &quot;sure not to match the real one&quot; =
is<BR>
a probability, in fact.<BR>
<BR>
Usual approach is to have a checksum field all the time, but<BR>
set its content to zero if there is no checksum to be used.<BR>
(With UDP, 1's complement and 11111111 =3D 000000000 is a =
workaround)<BR>
<BR>
Corruption in the checksum field itself can then warn of errors.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Eddy, Wesley M. (GRC-RCN0)[Verizon] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=
<BR>
Sent: Fri 2009-03-20 0:43<BR>
To: Wood L Dr (Electronic Eng); [email-masked]<BR>
Cc: [email-masked]<BR>
Subject: RE: [dtn-interest] last call comments on Bundle checksum =
-04<BR>
<BR>
Actually it *does* work, even if that bit gets corrupted.&nbsp; With =
some<BR>
very low probability it just sacrifices the ability to send errored =
content<BR>
in the case where you don't care about errors and the &quot;checksum<BR>
present&quot; bit happens to get flipped to on.<BR>
<BR>
If the bit starts as on, then there's a checksum present following =
the<BR>
rest of the block's fields.&nbsp; When the bit flips to off, =
subsequent<BR>
processing is going to fail due to those extra bytes not being =
parseable<BR>
or a length field being wrong, and you lose a bundle that the app =
had<BR>
asked to be lost if errored (correct behavior).<BR>
<BR>
If the bit starts as off, then there's no checksum present.&nbsp; When =
it<BR>
flips to on, then the bundle agent receiving it will interpret =
whatever<BR>
follows the block as a checksum, sure not to match the real one =
(that<BR>
isn't present), and processing fails, so the bundle is discarded.&nbsp; =
You<BR>
lose some data that the app said it didn't care about bit-errors in;<BR>
probably okay, given that the odds of this bit being flipped are<BR>
hopefully low in comparison to payload bits being flipped.<BR>
<BR>
<BR>
________________________________<BR>
From: [email-masked] [[email-masked]]<BR>
Sent: Thursday, March 19, 2009 6:48 PM<BR>
To: [email-masked]; Eddy, Wesley M. (GRC-RCN0)[Verizon]<BR>
Cc: [email-masked]<BR>
Subject: RE: [dtn-interest] last call comments on Bundle checksum =
-04<BR>
<BR>
<BR>
....<BR>
<BR>
(Wes's suggestion of having a bit to indicate if a checksum<BR>
is used doesn't _quite_ work - what if that bit is corrupted?)<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9A902.43CFBB6B--

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 19 Mar 2009 19:43:50 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

--_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6E4NDJSSCC01ndcn_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Actually it *does* work, even if that bit gets corrupted.  With some
very low probability it just sacrifices the ability to send errored content
in the case where you don't care about errors and the "checksum
present" bit happens to get flipped to on.

If the bit starts as on, then there's a checksum present following the
rest of the block's fields.  When the bit flips to off, subsequent
processing is going to fail due to those extra bytes not being parseable
or a length field being wrong, and you lose a bundle that the app had
asked to be lost if errored (correct behavior).

If the bit starts as off, then there's no checksum present.  When it
flips to on, then the bundle agent receiving it will interpret whatever
follows the block as a checksum, sure not to match the real one (that
isn't present), and processing fails, so the bundle is discarded.  You
lose some data that the app said it didn't care about bit-errors in;
probably okay, given that the odds of this bit being flipped are
hopefully low in comparison to payload bits being flipped.

________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, March 19, 2009 6:48 PM
To: [email-masked]; Eddy, Wesley M. (GRC-RCN0)[Verizon]
Cc: [email-masked]
Subject: RE: [dtn-interest] last call comments on Bundle checksum -04

....

(Wes's suggestion of having a bit to indicate if a checksum
is used doesn't _quite_ work - what if that bit is corrupted?)

--_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6E4NDJSSCC01ndcn_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta content=3D"MSHTML 6.00.6001.18203" name=3D"GENERATOR">
<style title=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body ocsi=3D"x">
<div dir=3D"ltr"><font face=3D"Tahoma" color=3D"#000000" size=3D"2">Actuall=
y it *does* work, even if that bit gets corrupted.&nbsp; With some</font></=
div>
<div dir=3D"ltr"><font size=3D"2"><font face=3D"tahoma">very low probabilit=
y it</font><font face=3D"Tahoma" color=3D"#000000">&nbsp;just sacrifices
</font></font><font face=3D"Tahoma" color=3D"#000000" size=3D"2">the abilit=
y to send errored content</font></div>
<div dir=3D"ltr"><font face=3D"Tahoma" color=3D"#000000" size=3D"2">in the =
case where you&nbsp;don't care about errors and
</font><font face=3D"Tahoma" color=3D"#000000" size=3D"2"><font face=3D"tah=
oma">the &quot;checksum</font></font></div>
<div dir=3D"ltr"><font face=3D"Tahoma" color=3D"#000000" size=3D"2"><font f=
ace=3D"tahoma">present&quot; bit happens to get flipped to on</font>.</font=
></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">If the bit starts as on, =
then there's a checksum present following the</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">rest of the block's field=
s.&nbsp; When the bit flips to off, subsequent</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">processing is going to fa=
il due to those extra bytes not being parseable</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"><font face=3D"tahoma">or =
a length field being wrong</font>,
</font><font face=3D"tahoma" size=3D"2"><font face=3D"tahoma">and you lose =
a bundle that the app had</font></font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"><font face=3D"tahoma">ask=
ed to be </font>
</font><font face=3D"tahoma" size=3D"2"><font face=3D"tahoma">lost if error=
ed (correct behavior)</font>.</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">If the bit starts as off,=
 then there's no checksum present.&nbsp; When it</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">flips to on, then the bun=
dle agent receiving it will interpret whatever</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">follows the block as a ch=
ecksum, sure not to match the real one (that</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">isn't present), and proce=
ssing fails, so the bundle is discarded.&nbsp; You</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">lose some data that the a=
pp said it didn't care about bit-errors in;</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">probably okay, given that=
 the odds of this bit being flipped are</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2">hopefully low in comparis=
on to payload bits being flipped.</font></div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div dir=3D"ltr"><font face=3D"tahoma" size=3D"2"></font>&nbsp;</div>
<div id=3D"divRpF589785" style=3D"DIRECTION: ltr">
<hr tabindex=3D"-1">
<font face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked] [L.Wood@s=
urrey.ac.uk]<br>
<b>Sent:</b> Thursday, March 19, 2009 6:48 PM<br>
<b>To:</b> [email-masked]; Eddy, Wesley M. (GRC-RCN0)[Verizon]<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> RE: [dtn-interest] last call comments on Bundle checksum -0=
4<br>
</font><br>
</div>
<div></div>
<div>
<p><font size=3D"2">....</font></p>
<p><font size=3D"2"><font face=3D"times new roman"></font><br>
(Wes's suggestion of having a bit to indicate if a checksum<br>
is used doesn't _quite_ work - what if that bit is corrupted?)<br>
</p>
</font></div>
</body>
</html>

--_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6E4NDJSSCC01ndcn_--

From: "Henry B. Hotz" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 19 Mar 2009 17:28:19 -0700
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

Umm.  Not sure if we're communicating.

On Mar 19, 2009, at 3:48 PM, [email-masked] wrote:

> Henry,
>
> Yes, that's the whole point of using something like CRC32.
>
Generic CRC's do not provide protection against intentional  
modification of the data.  I think I'm just repeating myself.
> Custody transfer is not useful or meaningful without the
> custodian performing some sort of reliability check on the
> bundle - and if the custodian does not know the secret
> key needed to decipher a secure payload, the integrity of
> a bundle can't be checked. A reliability check enables
> errors to be detected, and can make custody transfer truly
> reliable.
I agree, but what's your "threat model"?  If you're proposing a CRC  
instead of a cryptographic hash (with appropriate and appropriately  
managed keys), then you're assuming no *intentional* modification of  
the data.  I suspect there are some scenarios where that's not a good  
assumption.
> Our "bundle of problems" paper outlines why a reliability
> check is needed around any secure integrity cipher.
>
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#bundle-problems
> A worked example is given in the paper.
>
> Security can't be used alone, because it doesn't offer the
> ability for all forwarding nodes to check reliability and
> do error rejection when needed.
>
> Reliability can't be used alone, because if you want security,
> reliability doesn't give it.
>
> There is a place for both.
>
> (Wes's suggestion of having a bit to indicate if a checksum
> is used doesn't _quite_ work - what if that bit is corrupted?)
>
> L.
>
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
> -----Original Message-----
> From: [email-masked] on behalf of  
> Henry B. Hotz
> Sent: Thu 2009-03-19 21:05
> To: Eddy, Wesley M. (GRC-RCN0)[Verizon]
> Cc: DTN
> Subject: Re: [dtn-interest] last call comments on Bundle checksum -04
>
> CRC is designed to protect against accidental corruption.  It's not
> useful for secure integrity.
>
> On Mar 19, 2009, at 9:15 AM, Eddy, Wesley M. (GRC-RCN0)[Verizon]  
> wrote:
>
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On
> >> Behalf Of Elwyn Davies
> >> Sent: Thursday, March 19, 2009 10:42 AM
> >> To: DTN
> >> Subject: [dtn-interest] last call comments on Bundle checksum -04
> >>
> >> Overall it seems to me that this specification is a useful
> >> piece of work
> >> in pointing out the failings of the existing mechanisms but
> >> treating the
> >> BP and the BSP as cast in concrete and building a flawed edifice  
> that
> >> needs to be universally deployed before it is useful is a waste of
> >> resources.  Better to go for BP Mk2 with maybe a better BSP.
> >> Strikes me
> >> that maybe this is a symptom of the well known problemof trying to
> >> retrofit security/reliability. By all means experiment with how to
> >> get
> >> it right  but don't treat it  as a standard.
> >
> >
> > This is exactly what I'd like to do.  I've always felt that within
> > the "canonical bundle block format" we should define one of the
> > block processing control flags to indicate whether that block
> > requires reliability, and then if the bit is set, append some
> > lightweight checksum (eg CRC32) to the block.  If the bit wasn't
> > set, the checksum wouldn't be present.  You could do something
> > similar in the primary bundle block's bundle processing control
> > flags using 2 bits - one for a checksum covering the whole bundle
> > and all attached blocks, and one for a checksum just covering the
> > primary bundle block).  This would give you the flexibility to
> > allow delivery of errored content, but still cover the EIDs and
> > primary bundle block with a checksum.  It would also allow
> > other individual blocks that may require reliable reception to
> > receive it.
>
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> [email-masked], or [email-masked]
>
>

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 19 Mar 2009 22:48:45 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A8E4.DC23AA9B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Henry,

Yes, that's the whole point of using something like CRC32.

Custody transfer is not useful or meaningful without the
custodian performing some sort of reliability check on the
bundle - and if the custodian does not know the secret
key needed to decipher a secure payload, the integrity of
a bundle can't be checked. A reliability check enables
errors to be detected, and can make custody transfer truly
reliable.

Our "bundle of problems" paper outlines why a reliability
check is needed around any secure integrity cipher.

http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#b=
undle-problems
A worked example is given in the paper.

Security can't be used alone, because it doesn't offer the
ability for all forwarding nodes to check reliability and
do error rejection when needed.

Reliability can't be used alone, because if you want security,
reliability doesn't give it.

There is a place for both.

(Wes's suggestion of having a bit to indicate if a checksum
is used doesn't _quite_ work - what if that bit is corrupted?)

L.

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

-----Original Message-----
From: [email-masked] on behalf of =
Henry B. Hotz
Sent: Thu 2009-03-19 21:05
To: Eddy, Wesley M. (GRC-RCN0)[Verizon]
Cc: DTN
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04
=20
CRC is designed to protect against accidental corruption.  It's not =20
useful for secure integrity.

On Mar 19, 2009, at 9:15 AM, Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:

>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On
>> Behalf Of Elwyn Davies
>> Sent: Thursday, March 19, 2009 10:42 AM
>> To: DTN
>> Subject: [dtn-interest] last call comments on Bundle checksum -04
>>
>> Overall it seems to me that this specification is a useful
>> piece of work
>> in pointing out the failings of the existing mechanisms but
>> treating the
>> BP and the BSP as cast in concrete and building a flawed edifice that
>> needs to be universally deployed before it is useful is a waste of
>> resources.  Better to go for BP Mk2 with maybe a better BSP.
>> Strikes me
>> that maybe this is a symptom of the well known problemof trying to
>> retrofit security/reliability. By all means experiment with how to =20
>> get
>> it right  but don't treat it  as a standard.
>
>
> This is exactly what I'd like to do.  I've always felt that within
> the "canonical bundle block format" we should define one of the
> block processing control flags to indicate whether that block
> requires reliability, and then if the bit is set, append some
> lightweight checksum (eg CRC32) to the block.  If the bit wasn't
> set, the checksum wouldn't be present.  You could do something
> similar in the primary bundle block's bundle processing control
> flags using 2 bits - one for a checksum covering the whole bundle
> and all attached blocks, and one for a checksum just covering the
> primary bundle block).  This would give you the flexibility to
> allow delivery of errored content, but still cover the EIDs and
> primary bundle block with a checksum.  It would also allow
> other individual blocks that may require reliable reception to
> receive it.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

------_=_NextPart_001_01C9A8E4.DC23AA9B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] last call comments on Bundle checksum =
-04</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Henry,<BR>
<BR>
Yes, that's the whole point of using something like CRC32.<BR>
<BR>
Custody transfer is not useful or meaningful without the<BR>
custodian performing some sort of reliability check on the<BR>
bundle - and if the custodian does not know the secret<BR>
key needed to decipher a secure payload, the integrity of<BR>
a bundle can't be checked. A reliability check enables<BR>
errors to be detected, and can make custody transfer truly<BR>
reliable.<BR>
<BR>
Our &quot;bundle of problems&quot; paper outlines why a reliability<BR>
check is needed around any secure integrity cipher.<BR>
<BR>
<A =
HREF=3D"http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/inde=
x.html#bundle-problems">http://personal.ee.surrey.ac.uk/Personal/L.Wood/p=
ublications/index.html#bundle-problems</A><BR>
A worked example is given in the paper.<BR>
<BR>
Security can't be used alone, because it doesn't offer the<BR>
ability for all forwarding nodes to check reliability and<BR>
do error rejection when needed.<BR>
<BR>
Reliability can't be used alone, because if you want security,<BR>
reliability doesn't give it.<BR>
<BR>
There is a place for both.<BR>
<BR>
(Wes's suggestion of having a bit to indicate if a checksum<BR>
is used doesn't _quite_ work - what if that bit is corrupted?)<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Henry B. Hotz<BR>
Sent: Thu 2009-03-19 21:05<BR>
To: Eddy, Wesley M. (GRC-RCN0)[Verizon]<BR>
Cc: DTN<BR>
Subject: Re: [dtn-interest] last call comments on Bundle checksum =
-04<BR>
<BR>
CRC is designed to protect against accidental corruption.&nbsp; It's =
not&nbsp;<BR>
useful for secure integrity.<BR>
<BR>
On Mar 19, 2009, at 9:15 AM, Eddy, Wesley M. (GRC-RCN0)[Verizon] =
wrote:<BR>
<BR>
&gt;&gt; -----Original Message-----<BR>
&gt;&gt; From: [email-masked]<BR>
&gt;&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:=
[email-masked]</A>] On<BR>
&gt;&gt; Behalf Of Elwyn Davies<BR>
&gt;&gt; Sent: Thursday, March 19, 2009 10:42 AM<BR>
&gt;&gt; To: DTN<BR>
&gt;&gt; Subject: [dtn-interest] last call comments on Bundle checksum =
-04<BR>
&gt;&gt;<BR>
&gt;&gt; Overall it seems to me that this specification is a useful<BR>
&gt;&gt; piece of work<BR>
&gt;&gt; in pointing out the failings of the existing mechanisms but<BR>
&gt;&gt; treating the<BR>
&gt;&gt; BP and the BSP as cast in concrete and building a flawed =
edifice that<BR>
&gt;&gt; needs to be universally deployed before it is useful is a waste =
of<BR>
&gt;&gt; resources.&nbsp; Better to go for BP Mk2 with maybe a better =
BSP.<BR>
&gt;&gt; Strikes me<BR>
&gt;&gt; that maybe this is a symptom of the well known problemof trying =
to<BR>
&gt;&gt; retrofit security/reliability. By all means experiment with how =
to&nbsp;<BR>
&gt;&gt; get<BR>
&gt;&gt; it right&nbsp; but don't treat it&nbsp; as a standard.<BR>
&gt;<BR>
&gt;<BR>
&gt; This is exactly what I'd like to do.&nbsp; I've always felt that =
within<BR>
&gt; the &quot;canonical bundle block format&quot; we should define one =
of the<BR>
&gt; block processing control flags to indicate whether that block<BR>
&gt; requires reliability, and then if the bit is set, append some<BR>
&gt; lightweight checksum (eg CRC32) to the block.&nbsp; If the bit =
wasn't<BR>
&gt; set, the checksum wouldn't be present.&nbsp; You could do =
something<BR>
&gt; similar in the primary bundle block's bundle processing control<BR>
&gt; flags using 2 bits - one for a checksum covering the whole =
bundle<BR>
&gt; and all attached blocks, and one for a checksum just covering =
the<BR>
&gt; primary bundle block).&nbsp; This would give you the flexibility =
to<BR>
&gt; allow delivery of errored content, but still cover the EIDs and<BR>
&gt; primary bundle block with a checksum.&nbsp; It would also allow<BR>
&gt; other individual blocks that may require reliable reception to<BR>
&gt; receive it.<BR>
<BR>
------------------------------------------------------<BR>
The opinions expressed in this message are mine,<BR>
not those of Caltech, JPL, NASA, or the US Government.<BR>
[email-masked], or [email-masked]<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9A8E4.DC23AA9B--

From: "Henry B. Hotz" <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Date: Thu, 19 Mar 2009 14:05:14 -0700
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

CRC is designed to protect against accidental corruption.  It's not  
useful for secure integrity.

On Mar 19, 2009, at 9:15 AM, Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:

>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On
>> Behalf Of Elwyn Davies
>> Sent: Thursday, March 19, 2009 10:42 AM
>> To: DTN
>> Subject: [dtn-interest] last call comments on Bundle checksum -04
>>
>> Overall it seems to me that this specification is a useful
>> piece of work
>> in pointing out the failings of the existing mechanisms but
>> treating the
>> BP and the BSP as cast in concrete and building a flawed edifice that
>> needs to be universally deployed before it is useful is a waste of
>> resources.  Better to go for BP Mk2 with maybe a better BSP.
>> Strikes me
>> that maybe this is a symptom of the well known problemof trying to
>> retrofit security/reliability. By all means experiment with how to  
>> get
>> it right  but don't treat it  as a standard.
>
>
> This is exactly what I'd like to do.  I've always felt that within
> the "canonical bundle block format" we should define one of the
> block processing control flags to indicate whether that block
> requires reliability, and then if the bit is set, append some
> lightweight checksum (eg CRC32) to the block.  If the bit wasn't
> set, the checksum wouldn't be present.  You could do something
> similar in the primary bundle block's bundle processing control
> flags using 2 bits - one for a checksum covering the whole bundle
> and all attached blocks, and one for a checksum just covering the
> primary bundle block).  This would give you the flexibility to
> allow delivery of errored content, but still cover the EIDs and
> primary bundle block with a checksum.  It would also allow
> other individual blocks that may require reliable reception to
> receive it.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

From: Kevin Fall <[email-masked]>
To: DTN interest <[email-masked]>
Date: Thu, 19 Mar 2009 10:39:38 -0700
Subject: [dtn-interest] Fwd: Thursday dial-in?

--Apple-Mail-4--668342387
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Dial-in information for those who wish to dial in to the DTNRG meeting  
at Google:

>
>
>
> US Tollfree 1 866 457 4646
> Participant passcode:  64455291
>
> I think the plan is to dial in after the morning break around 10:45 am
> PDT/1:45 pm EDT.
>

--Apple-Mail-4--668342387
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dial-in information for those who wish to dial in to the DTNRG meeting at Google:<br><div><br><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><br><br>US Tollfree 1 866 457 4646<br>Participant passcode: &nbsp;64455291<br><br>I think the plan is to dial in after the morning break around 10:45 am<br>PDT/1:45 pm EDT.<br><br></div></blockquote></div></body></html>
--Apple-Mail-4--668342387--

Content-class: urn:content-classes:message
Date: Thu, 19 Mar 2009 17:11:08 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A8B5.B23BED39
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Elwyn,

without some form of reliability check (when required), custody
transfer is, simply, broken, since it can't be sure that the new
custody node has a good copy of the bundle. Adding the check to
custody transfer is needed to make custody transfer work safely.
That addresses your 'resending loop' problem. A node shouldn't
be a custodian unless it is sure it has a good copy of the bundle
to forward. It might be possible to get away with not implementing
reliability support on nodes that are never going to be
custodians - but on custodians it is necessary.

But yes, this is trying to retrofit reliability to a protocol
designed in ignorance of the concept, and it's unsatisfactory
for the reasons you point out. Redesigning the BP and BSP would
be imo preferable.

L.

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

Elwyn Davies said:
>
>Overall it seems to me that this specification is a useful=20
>piece of work=20
>in pointing out the failings of the existing mechanisms but=20
>treating the=20
>BP and the BSP as cast in concrete and building a flawed edifice that=20
>needs to be universally deployed before it is useful is a waste of=20
>resources.  Better to go for BP Mk2 with maybe a better BSP. =20
>Strikes me=20
>that maybe this is a symptom of the well known problemof trying to=20
>retrofit security/reliability. By all means experiment with how to get=20
>it right  but don't treat it  as a standard.

This is exactly what I'd like to do.  I've always felt that within
the "canonical bundle block format" we should define one of the
block processing control flags to indicate whether that block
requires reliability, and then if the bit is set, append some
lightweight checksum (eg CRC32) to the block.  If the bit wasn't
set, the checksum wouldn't be present.  You could do something
similar in the primary bundle block's bundle processing control
flags using 2 bits - one for a checksum covering the whole bundle
and all attached blocks, and one for a checksum just covering the
primary bundle block).  This would give you the flexibility to
allow delivery of errored content, but still cover the EIDs and
primary bundle block with a checksum.  It would also allow
other individual blocks that may require reliable reception to
receive it.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------
=20
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------_=_NextPart_001_01C9A8B5.B23BED39
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] last call comments on Bundle checksum =
-04</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Elwyn,<BR>
<BR>
without some form of reliability check (when required), custody<BR>
transfer is, simply, broken, since it can't be sure that the new<BR>
custody node has a good copy of the bundle. Adding the check to<BR>
custody transfer is needed to make custody transfer work safely.<BR>
That addresses your 'resending loop' problem. A node shouldn't<BR>
be a custodian unless it is sure it has a good copy of the bundle<BR>
to forward. It might be possible to get away with not implementing<BR>
reliability support on nodes that are never going to be<BR>
custodians - but on custodians it is necessary.<BR>
<BR>
But yes, this is trying to retrofit reliability to a protocol<BR>
designed in ignorance of the concept, and it's unsatisfactory<BR>
for the reasons you point out. Redesigning the BP and BSP would<BR>
be imo preferable.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
Elwyn Davies said:<BR>
&gt;<BR>
&gt;Overall it seems to me that this specification is a useful<BR>
&gt;piece of work<BR>
&gt;in pointing out the failings of the existing mechanisms but<BR>
&gt;treating the<BR>
&gt;BP and the BSP as cast in concrete and building a flawed edifice =
that<BR>
&gt;needs to be universally deployed before it is useful is a waste =
of<BR>
&gt;resources.&nbsp; Better to go for BP Mk2 with maybe a better =
BSP.&nbsp;<BR>
&gt;Strikes me<BR>
&gt;that maybe this is a symptom of the well known problemof trying =
to<BR>
&gt;retrofit security/reliability. By all means experiment with how to =
get<BR>
&gt;it right&nbsp; but don't treat it&nbsp; as a standard.<BR>
<BR>
<BR>
This is exactly what I'd like to do.&nbsp; I've always felt that =
within<BR>
the &quot;canonical bundle block format&quot; we should define one of =
the<BR>
block processing control flags to indicate whether that block<BR>
requires reliability, and then if the bit is set, append some<BR>
lightweight checksum (eg CRC32) to the block.&nbsp; If the bit =
wasn't<BR>
set, the checksum wouldn't be present.&nbsp; You could do something<BR>
similar in the primary bundle block's bundle processing control<BR>
flags using 2 bits - one for a checksum covering the whole bundle<BR>
and all attached blocks, and one for a checksum just covering the<BR>
primary bundle block).&nbsp; This would give you the flexibility to<BR>
allow delivery of errored content, but still cover the EIDs and<BR>
primary bundle block with a checksum.&nbsp; It would also allow<BR>
other individual blocks that may require reliable reception to<BR>
receive it.<BR>
<BR>
---------------------------<BR>
Wes Eddy<BR>
Network &amp; Systems Architect<BR>
Verizon FNS / NASA GRC<BR>
Office: (216) 433-6682<BR>
---------------------------<BR>
<BR>
_______________________________________________<BR>
dtn-interest mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9A8B5.B23BED39--

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Elwyn Davies <[email-masked]>, DTN <[email-masked]>
Date: Thu, 19 Mar 2009 11:15:34 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] last call comments on Bundle checksum -04

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Elwyn Davies
>Sent: Thursday, March 19, 2009 10:42 AM
>To: DTN
>Subject: [dtn-interest] last call comments on Bundle checksum -04
>
>Overall it seems to me that this specification is a useful 
>piece of work 
>in pointing out the failings of the existing mechanisms but 
>treating the 
>BP and the BSP as cast in concrete and building a flawed edifice that 
>needs to be universally deployed before it is useful is a waste of 
>resources.  Better to go for BP Mk2 with maybe a better BSP.  
>Strikes me 
>that maybe this is a symptom of the well known problemof trying to 
>retrofit security/reliability. By all means experiment with how to get 
>it right  but don't treat it  as a standard.

This is exactly what I'd like to do.  I've always felt that within
the "canonical bundle block format" we should define one of the
block processing control flags to indicate whether that block
requires reliability, and then if the bit is set, append some
lightweight checksum (eg CRC32) to the block.  If the bit wasn't
set, the checksum wouldn't be present.  You could do something
similar in the primary bundle block's bundle processing control
flags using 2 bits - one for a checksum covering the whole bundle
and all attached blocks, and one for a checksum just covering the
primary bundle block).  This would give you the flexibility to
allow delivery of errored content, but still cover the EIDs and
primary bundle block with a checksum.  It would also allow
other individual blocks that may require reliable reception to
receive it.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

Date: Thu, 19 Mar 2009 20:22:25 +0530
From: Prithwish Basu <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Wes,<br>
<br>
All good questions. Sorry for not responding earlier since I had some
trouble accessing email from India last night (and thank heavens for
the inherent disruption tolerance of the old email systems)!<br>
<br>
You are right that pub/sub mechanisms in the
Application layer can be used to yield the functionality that the
descriptive naming component in BBN's SPINDLE aims to accomplish. I
also agree with you that the optimal location in the stack for such
features
is an open question, and at best deployment dependent. We choose to
embed this in the DTN network layer for the following reasons:<br>
<ul>
  <li>Since in the DTN architecture, names are the denotational
entities that are exposed to routing, "routing to a name" can be seen
as a core network
layer service which DTN applications sitting up top can benefit from.
This name can be flat or hierarchical, unicast or multicast/anycast
(descriptive queries as name falls in this class). Since there are only
names in the DTN arch (and no addresses as in IP), we feel that routing
to all kinds of names should be treated uniformly -- in the network
layer of DTN.&nbsp; If name schemes are too restrictive in DTN then a lot of
generality will be lost. I agree with you that this needs to be figured
out while balancing the tradeoffs between costs, flexibility, security
etc. but I think a deeper understanding of the problem is needed to
know whether
the costs of this uniform treatment are any more prohibitive than just
supporting routing to seemingly basic (i.e. non-descriptive) names.<br>
  </li>
  <li>In a DTN, descriptive name resolution (who is X?) and routing
(how to reach X?) problems typically need to be integrated unlike in
the Internet where resolution happens once in the app layer of the
source node. For example one may choose send a bundle along a seemingly
suboptimal route since that route contains an authoritative resolver
rather than querying a resolver in the opposite direction and then
routing the bundle to the destination along an optimal path. If one
desires such a tight level of integration between resolution and
routing, there is a case for the name management service to reside in
the network layer alongside routing.<br>
  </li>
  <li>Name database dissemination and management over DTN
are some common services which a unified naming architecture at the
network layer can benefit from. If each application were following its
own naming scheme and associated name management algorithms, there may
be significant redundancy. Moreover this is more hurtful under
disruption where the connection opportunities are rare, unlike in the
strongly connected Internet where applications usually have ample
bandwidth to run chatty app-layer protocols.</li>
  <li>Since node/app/service mobility is a first class concern in DTNs,
mobility (and associated topology) management needs to be a core
service at the network layer. Typically this will entail managing and
updating the bindings between a higher level EID and a lower level EID
as nodes and services move. Any such update scheme can be augmented
with support for descriptive names, instead of each application doing
its own job.<br>
  </li>
</ul>
An APP sending to a descriptive name uses a descriptive EID in the
bundle destination field (just like other apps use a regular
"non-descriptive" EID) while keeping the other fields similar to those
in regular bundles, so we can leverage all the standard BP and
underlying CLA services (as you point out).<br>
<br>
-Prithwish<br>
<br>
Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: Rajesh Krishnan [<a class="moz-txt-link-freetext"
 href="mailto:[email-masked]">mailto:[email-masked]</a>] 
Sent: Tuesday, March 17, 2009 2:02 PM

Wes:

It may be useful to think of late binding as a generalization.  There
are mobility management (in a topological sense), name to address
resolution, alias resolution, as well as other aspects  such as
maintenance of related dynamic multi-attribute naming data bases to
late binding.

Mobile IP routes to the IP address of a care-of destination instead
the address of the actual destination; there is readdressing,  but no
name resolution at every step.  This procedure does not account for
routing on multi-attributed names (there is no further name resolution
post the source), or CLA parameters in heterogeneous networks.

The SPINDLE architecture makes use of care-of resolvers that resemble
the foreign agent in mobile IP, but there is more to consider beyond
mobility management alone.

Prithwish  may have additional insights on this topic since I recall
we went through the same thought process to determine how is late
binding not just mobility management, routing, alias resolution etc.
    </pre>
  </blockquote>
  <pre wrap=""><!---->

I think I understand and agree; the ability for EIDs to "name" things
that aren't just interfaces or sets of interfaces is a strong feature
beyond normal IP-based networking.

But ... if we have pub/sub applications running over a network layer
that includes mobility management (whether Mobile IP, a MANET, etc.),
I think that would yield a similar set of properties to SPINDLE?  It's
certainly a different architecture, but is it functionally equivalent?
Pub/sub systems often support store-and-forward as an option for
messages, so the main difference I see between them and DTN is that
they're usually not as flexible about the "convergence layer adapter"
protocols they're wed to.

So, in my mind there's a good question about placement of features in
layers and whether content-based features belong low-down or higher-up.
We can see there are benefits in placing them low, but what are the
costs?  The question is complicated by the fact that DTN BP can be
either high or low in the stack depending on your deployment case :).

---------------------------
Wes Eddy
Network &amp; Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

_______________________________________________
dtn-interest mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext"
 href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a>

  </pre>
</blockquote>
</body>
</html>

From: "Burleigh, Scott C" <[email-masked]>
To: Andrew Sullivan <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 19 Mar 2009 07:48:25 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

Andrew, thanks again; I will add a sentence alerting the implementer to the possibility of a non-CBHE CLA receiving a compressed bundle.  As to the 2119 issue, I'm happy to revise in whatever way is required by the standards; anybody else want to weigh in on this?

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Andrew Sullivan
> Sent: Thursday, March 19, 2009 12:24 AM
> To: [email-masked]
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> On Tue, Mar 17, 2009 at 10:08:33PM -0700, Burleigh, Scott C wrote:
> >
> > The boilerplate is all coming from xml2rfc, and if xml2rfc is no
> > longer implementing 2119 then I agree that there shouldn't be any
> > references to 2119 in the document.
> 
> Ah, I see.  xml2frc doesn't capitalize your MUSTs and SHOULDs and such
> like, AFAIK, so the issue is just that xml2rfc inserts this without
> checking whether the 2119-words are used anywhere, I guess.  I sort of
> feel like some of the musts and shoulds and such ought to be
> 2119-word versions instead, but I don't feel so strongly about this
> that I think it's worth insisting.  If you want some suggestions,
> though, let me know (I guess off list?) and I can happily send them.
> 
> > I think it is indeed possible (anomalous, but still possible) for a
> > CBHE-unaware CLA to receive -- and simply pass upward -- a
> > CBHE-compressed bundle.  This would not be good, but I don't think
> > any bundle agents would be at risk of damage: when the bundle is
> > parsed, the zero in dictionary length should be clue to the
> > receiving bundle agent that the bundle is corrupt and should simply
> > be discarded.  I figure that receiving node will start to look like
> > a black hole and upstream nodes will start routing around it, which
> > is the behavior we would want.  There would be some data loss for a
> > while, which custodial retransmission should be able to compensate
> > for, and then the network should be okay again.
> 
> Ok, this is pretty much what I was sort of worried about.  I think
> you're probably right, but it would be nice to have a sentence saying
> that there is this possibility, but the zero dictionary length should
> protect the network.
> 
> Thanks for the careful responses!
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: Andrew Sullivan <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 19 Mar 2009 07:42:28 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

Thanks, Andrew, I agree and will add language along these lines to the spec.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Andrew Sullivan
> Sent: Thursday, March 19, 2009 12:17 AM
> To: [email-masked]
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> On Tue, Mar 17, 2009 at 09:52:56PM -0700, Burleigh, Scott C wrote:
> 
> > example) individual national space agencies might want to assign
> > node numbers to their own spacecraft; I'm inclined to just leave it
> > undetermined at this point.
> 
> Given that this targets experimental use, I can support that
> approach.  Just for the record (but I guess obviously), if it were to
> be later considered for the standards track, it would need an
> IANA-or-something registry.  For sure, though, if there's not to be a
> careful specification of some mechanism to guarantee uniqueness, it's
> pretty important the document make that clear.  Then potential
> experimenters in this field can understand that they had better make
> sure to co-ordinate with others.

Date: Thu, 19 Mar 2009 14:41:50 +0000
From: Elwyn Davies <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] last call comments on Bundle checksum -04

Hi.

Generally, I was unhappy with this document.  It is very repetitive and 
long winded about the problems that it is attempting to solve and how it 
is making a rather badly fitting (The author's own view) attempt to 
provide a solution within the bounds of what the BSP offers.   The 
actual solution offered could be covered in a far shorter and tighter 
document.   e.g.

s1.1, last para: 'An unsatisfying way to redress this lack of 
robustness,,,':  I'lll read on but do we really want to propose 
something that is unsatisfying?  This needs justification.

There are a lot of other problems as others have hightlighted, but one 
additional point that makes the solution somewhat dubious to me is:

s4:  This section highlights that partial deployment of this mechanism 
is not useful.  It is only useful if every potential custody owner on 
the path taken by the bundle implements the checks.  If the bundle is 
already damaged when it is taken into ciustody by a node that does not 
check the integrity, and then sent on to a node that does check the 
integrity, all that will result is a local retransmission loop that will 
be repeatedly exercised until the bundle expires.  The cost in resources 
on the hop or hops between these nodes might well be greater than 
allowing the damaged bundle to travel on to its destination or just 
dropping the bundle!

Overall it seems to me that this specification is a useful piece of work 
in pointing out the failings of the existing mechanisms but treating the 
BP and the BSP as cast in concrete and building a flawed edifice that 
needs to be universally deployed before it is useful is a waste of 
resources.  Better to go for BP Mk2 with maybe a better BSP.  Strikes me 
that maybe this is a symptom of the well known problemof trying to 
retrofit security/reliability. By all means experiment with how to get 
it right  but don't treat it  as a standard.

/Elwyn

From: Kevin Fall <[email-masked]>
To: DTN interest <[email-masked]>
Date: Thu, 19 Mar 2009 00:37:11 -0700
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-checksum

--Apple-Mail-2--704489759
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

> From: Kevin Fall
> Date: March 19, 2009 12:34:45 AM PDT
> To: DTN interest <[email-masked]>
> Cc: Stephen Farrell <[email-masked]>
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg- 
> bundle-checksum
>
> I also have a number of comments on this draft which I believe we  
> can cover on thursday.
> At a high level, the authors appear to wish to explain both the  
> approach and its (comparatively
> lengthy) rationale.  I believe the rationale belongs elsewhere,  
> possibly in an informational
> document that discusses reliability, integrity and the BP.  I  
> believe this will help promote getting
> the technical details through the process.
>
> A couple of other things brought up by this draft:
>
> should a bundle somehow indicate an app's {non}desire for error free  
> bundles
> need any corresponding API have the ability to specify this?
> that there should possibly be a configuration flag in bundle agents  
> indicating whether bundles failing integrity checks are dropped
> (and/or whether the integrity check is applied at all-- note that we  
> may be running in a high performance network as well).
>
> - K
>
>
> On Mar 16, 2009, at Mar 167:50 AMPDT, Stephen Farrell wrote:
>
>>
>> My comments on the first part (up to the end of section 3, I ran
>> out of time since there was so much that needed comment) are
>> attached. This is not ready IMO, I'd guess a couple more
>> revs are needed before it'd be done.
>>
>> Stephen.
>>
>>
>>
>> SF comments on draft-irtf-dtnrg-checksum
>>
>> 20090312
>>
>> General
>>
>> #0 There are many editorial changes required. There are numerous  
>> erroneous,
>> imprecise or misleading statements that should be removed (examples  
>> below).
>> There are also many sections of text that appear to be discussing  
>> "DTN history
>> before checksums." While such text might be interesting for some it  
>> doesn't IMO
>> belong in an experimental RFC unless it is beneficial for  
>> implementers (again,
>> examples below). Basically what should be a useful specification is  
>> sometimes
>> almost a rant which is inappropriate. (In addition to my opinion on  
>> this, the
>> IRSG review specifically aims to ensure that the content is as  
>> suitable as
>> journal content, so this kind of change will be needed later anyway  
>> its not
>> just me being a pain)
>>
>> #1 I think a lot of the motivation stuff could be removed and that  
>> that'd
>> improve the document. Simpler/shorter is better.
>>
>> #2 The BSP has the concept of end-to-end-ishness where e.g. the  
>> security source
>> might not be the actual source. That's mainly to cater for less  
>> capable nodes
>> at the edges, and is probably not needed here, but worth asking  
>> anyway. Are
>> there any cases where it'd make sense to add a checksum in the  
>> middle of a path
>> or to strip one in the middle of a path?
>>
>> #3 A lot of the discussion about integrity only applies for  
>> accidental
>> integrity violations. There should be a statement up front saying  
>> that this
>> draft doesn't consider deliberate integrity violations and that  
>> those are
>> address by other ciphersuites, e.g. in the BSP spec.
>>
>> #4 I'm totally unclear as to why there need to be three  
>> ciphersuites.  Is
>> there a real justification for anything other than min and max here?
>>
>> #5 origin authentication is not non-repudiation (if such exists as  
>> a network
>> service) as any security primer would tell you
>>
>> #6 MD5 is not a checksum algorithm, it is a digest alg. which is a  
>> different
>> beast (second pre-image resistance etc.)
>>
>> #7 You're probably better off removing the downref to my expired  
>> key mgmt draft
>> (draft-farrell-dtnrg-km) since someone starting over on that might  
>> not base on
>> that draft, which'd leave the eventual RFC with a bad pointer.
>>
>> #8 If you want to make the claim that using the PIB is problematic  
>> for some
>> reason, you need to justify that. Just saying "not designed  
>> for." (which is
>> ungrammatic as used) is not sufficient.
>>
>> #9 (sigh) The use of the term private key seems to indicate a lack of
>> familiarity with crypto mechanisms. Public keys are used to verify  
>> signatures.
>> "3rd party intermediate nodes that do not possess that private  
>> key..." is a
>> crypto-101 error.
>>
>> #10 The RSA/SHA256 ciphersuite is criticised for some odd reason.  
>> That adds
>> nothing and should be deleted. (The sentence includes the terms  
>> "excessive" and
>> "disadvantageous.") If you are arguing that keyed ciphersuites are  
>> not what you
>> need then such points are superflous and would only serve to  
>> confuse a reader.
>>
>> #11 What is a "NULL key pair"? As far as I'm aware this is the  
>> first time
>> anyone's suggested using a known key for RSA ever. (No one else has  
>> becuase
>> it'd be silly, a known symmetric key is similar strength and far  
>> easier.) I
>> don't believe anyone has ever suggested re-using an existing  
>> ciphersuite with a
>> known key, all previous cases invent a new ciphersuite. There is  
>> really no
>> point in discussing obviously silly design choices that could have  
>> been made by
>> someone not skilled in the art.  (Actually, just deleting that  
>> entire paragraph
>> is best.)
>>
>> #12 BAB-HMAC discussion. I'm not sure if its a good idea to opine  
>> here on
>> changes that "could" be made to the BP, but if that remains, it  
>> should at least
>> say "a future version of the BP." Noting that the BP doesn't  
>> mandate the BSP is
>> fine, but the future looking stuff might confuse a reader, so I'd  
>> leave it out.
>> Saying that some "path" seems to be desirable is also needlessly  
>> confusing,
>> this document should just specify and explain the new ciphersuites  
>> and not be
>> as argumentative.
>>
>> #13 Mention of your "previous proposal" adds nothing and exposes an  
>> apparent
>> minsunderstanding on the author's part of compliance. This spec can  
>> and should
>> define new PIB ciphersuites. There is no reason why conforming  
>> implementations
>> should also have to implement other ciphersuites as well.  (And again
>> "heavyweight" is purely pejorative so remove that.)
>>
>> #14 The "insecure ciphersuites might give a false impression of  
>> security"
>> argument seems to me to be bogus. Have there ever been any cases  
>> where IPsec or
>> TLS equivalents were accidentally used? This could be a security  
>> cconsideration
>> to point out to coders that they shouldn't confuse administrators  
>> in user
>> interfaces, but is not a real issue in terms of the bits on the  
>> wire..  (I do
>> like the idea of naming these ciphersuites INSECURE or something,  
>> but that
>> doesn't mean there's a real issue here.)
>>
>> #15 "SHOULD subjective ensure" is very odd.
>>
>> #16 I don't follow why logging output is significant enough for a  
>> MUST NOT?
>>
>> #17 The requirement that any future similar ciphersuite be called  
>> "INSECURE" is
>> broken. Just say that these ciphersuites are called that and you're  
>> done. Also
>> PIBs using these are not indistinguishable from those with secure  
>> ciphersuites
>> - that's the whole point of the ciphersuite types. You're confusing  
>> the name of
>> the ciphersuites (that might appear in GUIs) with the bits on the  
>> wire where
>> no such confusion arises.
>>
>> #18 You seem to contradict yourself when you say that things MUST  
>> be called
>> INSECURE_* but then say that PIB-HMAC with NULL keys is ok. I think  
>> one or the
>> other is ok, but not both. I think that PIB-HMAC if its useful (and  
>> it could
>> be) ought be in a different document (probably BSP) and the NULL  
>> key version
>> should be here as its own ciphersuite. (Or just omitted, I'm not  
>> sure who wants
>> PIB-HMAC-WITH-NULL?)
>>
>> #19 Talking about what BP implementations MUST support is missing  
>> the point.
>> This spec should talk about what implementations doing this spec  
>> MUST support
>> and not others.
>>
>> #20 Mutable c14n is defined in the BSP and not in appendix A.1 The  
>> PIB wire
>> format is defined in the BSP and not in appendix A.2. As-is, both  
>> inaccurate
>> statements would mislead implementers.
>>
>> #21 Using a zero KeyID as the indicator of a NULL ciphersuite is a  
>> bad
>> choice IMO. (It should be a separate ciphersuite as explained  
>> above.) The
>> problem is that there are times when shared secrets are used without
>> KeyIDs (which is bad practice, but happens). A zero KeyID is too easy
>> for a coder to mistake as a missing KeyID so its better to either  
>> have
>> the same semantic or none.
>>
>> #22 end of p12, I don't get what "the later two EIDs" means? Needs  
>> some
>> clarification I guess. (Maybe just a type s/EID/SDNV/?)
>>
>> #23 What makes you think an 80-bit MAC is less good at error  
>> detection
>> than a (known weak) 128 bit digest? Such statements are better  
>> deleted
>> (or else justified with references).
>>
>> #24 "Although the BSP was intended..." again the authors appear  
>> confused
>> about compliance - this document does not UPDATE 5050 (not sure what
>> that'd mean for an experimental RFC anyway) so discussion of things
>> that are "needed" by BP implementations is off base. This is even
>> clearer in the next paragraph where the spec tries to impose  
>> requirements
>> on 5050 implementations doing custody stuff.
>>
>> #25 "...private keys shared only..." Private keys are never shared in
>> any DTN ciphersuite. Another crypto-101 error.
>>
>> #26 You have a SHOULD on dropping when checks fail. What about  
>> fragmentation?
>>
>> #27 "...end-to-end private key" crypto-101 Entire paragraphs needs  
>> fixing.
>>
>> ------------
>>
>> Editorial changes in the early pages. (I stopped separatng them
>> after a while since there are so many.)
>>
>> Abstract:
>>
>> #1 the BP does not include a checksum, yet it *is* possible to do  
>> verification,
>> if the BSP is used. The statement is misleading.
>>
>> #2 "Without assurance...cannot" is wrong. "may not" would be correct.
>>
>> #3 sometimes errored bundle forwarding is desired, suggest  
>> replacing "instead
>> of..." with "where it may have been better to..."`
>>
>> #4 "address the situation" implies that this is correcting a  
>> serious unexpected
>> fault which is disputed
>>
>> #5 "Formerly called" adds no value
>>
>> #6 "Regardless of" clause adds no value
>>
>> #7 "Divorcing" clause seems odd - I think you mean to say there's  
>> no need for
>> keys but I don't see any papers being served.
>>
>> #8 "necessary detail" why would you include unnecessary detail?  
>> delete
>> necessary
>>
>> #9 Overall an abstrct like the following would be much better:
>>
>> The Delay-Tolerant Networking Bundle Protocol includes a custody  
>> transfer
>> mechanism to provide acknowledgements of receipt for particular  
>> bundles.  The
>> bundle protocol does not define a checksum that allows verification  
>> of
>> error-free forwarding at any hop on the path. This document defines  
>> new
>> "keyless" data integrity ciphersuites for use with the Bundle  
>> Security
>> Protocol's Payload Integrity Block that can be used to increase  
>> reliability in
>> many situations.
>>
>> Section 1:
>>
>> #0 this entire section could be deleted, or almost all
>>
>> #1 2nd para: "does not take bundle inegrity into account" is  
>> misleading; the BP
>> asssumes that CLs do that which is different.
>>
>> #2 something that's not always sufficient is not always  
>> insufficient to talking
>> about "the insufficiency" is a mistatement
>>
>> #3 s/painstakingly// it adds nothing but pique
>>
>> #4 delivering errored content does not require that "all underlying  
>> layers pass
>> through and accept errors", only perhaps that the layers in use  
>> when the error
>> occurs support that, and with bugs, memory or file system errors  
>> not even that
>>
>> #5 the claim that the "ability to provide a check" is primary to  
>> "overall
>> strength" needs a reference or should be deleted
>>
>> #6 last para of p7:s/much more important/potentially much more  
>> important/
>>
>> #7 same para as #6, everything from "the bundle protocol..does  
>> neither..." down
>> to"...Internet traffic." should be deleted. Its only purpose seems  
>> to be to try
>> make the bundle protocol look bad?
>>
>> #8 last para: delete the paragraph I guess it just vituperative,  
>> hard to
>> understand how it ever got added
>>
>> section 2:
>>
>> #1 there are currently 4 block types in BSP but I don't think  
>> there's any need
>> to discuss that, just say we're re-using PIB. There is no reason to  
>> discuss
>> BAB, PCB or, now ESB at all.
>>
>> #2 delete the sentence that says "truly suitable" - actually an  
>> entire page or
>> so can best be deleted here, incl. the "what's a MAC" part.
>>
>> #3 The "in fact, several popular" sentence gets it wrong, some  
>> digest algs are
>> used for MACs
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--Apple-Mail-2--704489759
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">Kevin Fall&nbsp;</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"5" color=3D"#000000" style=3D"font: 18.0px =
Helvetica; color: #000000"><b>Date: </b></font><font face=3D"Helvetica" =
size=3D"5" style=3D"font: 18.0px Helvetica">March 19, 2009 12:34:45 AM =
PDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica">DTN interest &lt;<a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a>></font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>Cc: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica">Stephen Farrell &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></=
font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica"><b>Re: [dtn-interest] RG "last call" on =
draft-irtf-dtnrg-bundle-checksum</b></font></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div> </div><div>I also have a number of =
comments on this draft which I believe we can cover on thursday.<br>At a =
high level, the authors appear to wish to explain both the approach and =
its (comparatively<br>lengthy) rationale. &nbsp;I believe the rationale =
belongs elsewhere, possibly in an informational<br>document that =
discusses reliability, integrity and the BP. &nbsp;I believe this will =
help promote getting<br>the technical details through the =
process.<br><br>A couple of other things brought up by this =
draft:<br><br>should a bundle somehow indicate an app's {non}desire for =
error free bundles<br>need any corresponding API have the ability to =
specify this?<br>that there should possibly be a configuration flag in =
bundle agents indicating whether bundles failing integrity checks are =
dropped<br>(and/or whether the integrity check is applied at all-- note =
that we may be running in a high performance network as well).<br><br>- =
K<br><br><br>On Mar 16, 2009, at Mar 167:50 AMPDT, Stephen Farrell =
wrote:<br><br><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">My comments on the first part (up to the end of section 3, =
I ran<br></blockquote><blockquote type=3D"cite">out of time since there =
was so much that needed comment) are<br></blockquote><blockquote =
type=3D"cite">attached. This is not ready IMO, I'd guess a couple =
more<br></blockquote><blockquote type=3D"cite">revs are needed before =
it'd be done.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Stephen.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">SF comments on =
draft-irtf-dtnrg-checksum<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">20090312<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">General<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#0 There are =
many editorial changes required. There are numerous =
erroneous,<br></blockquote><blockquote type=3D"cite">imprecise or =
misleading statements that should be removed (examples =
below).<br></blockquote><blockquote type=3D"cite">There are also many =
sections of text that appear to be discussing "DTN =
history<br></blockquote><blockquote type=3D"cite">before checksums." =
While such text might be interesting for some it doesn't =
IMO<br></blockquote><blockquote type=3D"cite">belong in an experimental =
RFC unless it is beneficial for implementers =
(again,<br></blockquote><blockquote type=3D"cite">examples below). =
Basically what should be a useful specification is =
sometimes<br></blockquote><blockquote type=3D"cite">almost a rant which =
is inappropriate. (In addition to my opinion on this, =
the<br></blockquote><blockquote type=3D"cite">IRSG review specifically =
aims to ensure that the content is as suitable =
as<br></blockquote><blockquote type=3D"cite">journal content, so this =
kind of change will be needed later anyway its =
not<br></blockquote><blockquote type=3D"cite">just me being a =
pain)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#1 I think a =
lot of the motivation stuff could be removed and that =
that'd<br></blockquote><blockquote type=3D"cite">improve the document. =
Simpler/shorter is better.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#2 The BSP has =
the concept of end-to-end-ishness where e.g. the security =
source<br></blockquote><blockquote type=3D"cite">might not be the actual =
source. That's mainly to cater for less capable =
nodes<br></blockquote><blockquote type=3D"cite">at the edges, and is =
probably not needed here, but worth asking anyway. =
Are<br></blockquote><blockquote type=3D"cite">there any cases where it'd =
make sense to add a checksum in the middle of a =
path<br></blockquote><blockquote type=3D"cite">or to strip one in the =
middle of a path?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#3 A lot of the =
discussion about integrity only applies for =
accidental<br></blockquote><blockquote type=3D"cite">integrity =
violations. There should be a statement up front saying that =
this<br></blockquote><blockquote type=3D"cite">draft doesn't consider =
deliberate integrity violations and that those =
are<br></blockquote><blockquote type=3D"cite">address by other =
ciphersuites, e.g. in the BSP spec.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#4 I'm totally =
unclear as to why there need to be three ciphersuites. =
&nbsp;Is<br></blockquote><blockquote type=3D"cite">there a real =
justification for anything other than min and max =
here?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#5 origin =
authentication is not non-repudiation (if such exists as a =
network<br></blockquote><blockquote type=3D"cite">service) as any =
security primer would tell you<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#6 MD5 is not a =
checksum algorithm, it is a digest alg. which is a =
different<br></blockquote><blockquote type=3D"cite">beast (second =
pre-image resistance etc.)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#7 You're =
probably better off removing the downref to my expired key mgmt =
draft<br></blockquote><blockquote type=3D"cite">(draft-farrell-dtnrg-km) =
since someone starting over on that might not base =
on<br></blockquote><blockquote type=3D"cite">that draft, which'd leave =
the eventual RFC with a bad pointer.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#8 If you want =
to make the claim that using the PIB is problematic for =
some<br></blockquote><blockquote type=3D"cite">reason, you need to =
justify that. Just saying "not designed for." (which =
is<br></blockquote><blockquote type=3D"cite">ungrammatic as used) is not =
sufficient.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#9 (sigh) The =
use of the term private key seems to indicate a lack =
of<br></blockquote><blockquote type=3D"cite">familiarity with crypto =
mechanisms. Public keys are used to verify =
signatures.<br></blockquote><blockquote type=3D"cite">"3rd party =
intermediate nodes that do not possess that private key..." is =
a<br></blockquote><blockquote type=3D"cite">crypto-101 =
error.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#10 The =
RSA/SHA256 ciphersuite is criticised for some odd reason. That =
adds<br></blockquote><blockquote type=3D"cite">nothing and should be =
deleted. (The sentence includes the terms "excessive" =
and<br></blockquote><blockquote type=3D"cite">"disadvantageous.") If you =
are arguing that keyed ciphersuites are not what =
you<br></blockquote><blockquote type=3D"cite">need then such points are =
superflous and would only serve to confuse a =
reader.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#11 What is a =
"NULL key pair"? As far as I'm aware this is the first =
time<br></blockquote><blockquote type=3D"cite">anyone's suggested using =
a known key for RSA ever. (No one else has =
becuase<br></blockquote><blockquote type=3D"cite">it'd be silly, a known =
symmetric key is similar strength and far easier.) =
I<br></blockquote><blockquote type=3D"cite">don't believe anyone has =
ever suggested re-using an existing ciphersuite with =
a<br></blockquote><blockquote type=3D"cite">known key, all previous =
cases invent a new ciphersuite. There is really =
no<br></blockquote><blockquote type=3D"cite">point in discussing =
obviously silly design choices that could have been made =
by<br></blockquote><blockquote type=3D"cite">someone not skilled in the =
art. &nbsp;(Actually, just deleting that entire =
paragraph<br></blockquote><blockquote type=3D"cite">is =
best.)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#12 BAB-HMAC =
discussion. I'm not sure if its a good idea to opine here =
on<br></blockquote><blockquote type=3D"cite">changes that "could" be =
made to the BP, but if that remains, it should at =
least<br></blockquote><blockquote type=3D"cite">say "a future version of =
the BP." Noting that the BP doesn't mandate the BSP =
is<br></blockquote><blockquote type=3D"cite">fine, but the future =
looking stuff might confuse a reader, so I'd leave it =
out.<br></blockquote><blockquote type=3D"cite">Saying that some "path" =
seems to be desirable is also needlessly =
confusing,<br></blockquote><blockquote type=3D"cite">this document =
should just specify and explain the new ciphersuites and not =
be<br></blockquote><blockquote type=3D"cite">as =
argumentative.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#13 Mention of =
your "previous proposal" adds nothing and exposes an =
apparent<br></blockquote><blockquote type=3D"cite">minsunderstanding on =
the author's part of compliance. This spec can and =
should<br></blockquote><blockquote type=3D"cite">define new PIB =
ciphersuites. There is no reason why conforming =
implementations<br></blockquote><blockquote type=3D"cite">should also =
have to implement other ciphersuites as well. &nbsp;(And =
again<br></blockquote><blockquote type=3D"cite">"heavyweight" is purely =
pejorative so remove that.)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#14 The =
"insecure ciphersuites might give a false impression of =
security"<br></blockquote><blockquote type=3D"cite">argument seems to me =
to be bogus. Have there ever been any cases where IPsec =
or<br></blockquote><blockquote type=3D"cite">TLS equivalents were =
accidentally used? This could be a security =
cconsideration<br></blockquote><blockquote type=3D"cite">to point out to =
coders that they shouldn't confuse administrators in =
user<br></blockquote><blockquote type=3D"cite">interfaces, but is not a =
real issue in terms of the bits on the wire.. &nbsp;(I =
do<br></blockquote><blockquote type=3D"cite">like the idea of naming =
these ciphersuites INSECURE or something, but =
that<br></blockquote><blockquote type=3D"cite">doesn't mean there's a =
real issue here.)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#15 "SHOULD =
subjective ensure" is very odd.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#16 I don't =
follow why logging output is significant enough for a MUST =
NOT?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#17 The =
requirement that any future similar ciphersuite be called "INSECURE" =
is<br></blockquote><blockquote type=3D"cite">broken. Just say that these =
ciphersuites are called that and you're done. =
Also<br></blockquote><blockquote type=3D"cite">PIBs using these are not =
indistinguishable from those with secure =
ciphersuites<br></blockquote><blockquote type=3D"cite">- that's the =
whole point of the ciphersuite types. You're confusing the name =
of<br></blockquote><blockquote type=3D"cite">the ciphersuites (that =
might appear in GUIs) with the bits on the wire =
where<br></blockquote><blockquote type=3D"cite">no such confusion =
arises.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#18 You seem to =
contradict yourself when you say that things MUST be =
called<br></blockquote><blockquote type=3D"cite">INSECURE_* but then say =
that PIB-HMAC with NULL keys is ok. I think one or =
the<br></blockquote><blockquote type=3D"cite">other is ok, but not both. =
I think that PIB-HMAC if its useful (and it =
could<br></blockquote><blockquote type=3D"cite">be) ought be in a =
different document (probably BSP) and the NULL key =
version<br></blockquote><blockquote type=3D"cite">should be here as its =
own ciphersuite. (Or just omitted, I'm not sure who =
wants<br></blockquote><blockquote =
type=3D"cite">PIB-HMAC-WITH-NULL?)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#19 Talking =
about what BP implementations MUST support is missing the =
point.<br></blockquote><blockquote type=3D"cite">This spec should talk =
about what implementations doing this spec MUST =
support<br></blockquote><blockquote type=3D"cite">and not =
others.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#20 Mutable =
c14n is defined in the BSP and not in appendix A.1 The PIB =
wire<br></blockquote><blockquote type=3D"cite">format is defined in the =
BSP and not in appendix A.2. As-is, both =
inaccurate<br></blockquote><blockquote type=3D"cite">statements would =
mislead implementers.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#21 Using a =
zero KeyID as the indicator of a NULL ciphersuite is a =
bad<br></blockquote><blockquote type=3D"cite">choice IMO. (It should be =
a separate ciphersuite as explained above.) =
The<br></blockquote><blockquote type=3D"cite">problem is that there are =
times when shared secrets are used without<br></blockquote><blockquote =
type=3D"cite">KeyIDs (which is bad practice, but happens). A zero KeyID =
is too easy<br></blockquote><blockquote type=3D"cite">for a coder to =
mistake as a missing KeyID so its better to either =
have<br></blockquote><blockquote type=3D"cite">the same semantic or =
none.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#22 end of p12, =
I don't get what "the later two EIDs" means? Needs =
some<br></blockquote><blockquote type=3D"cite">clarification I guess. =
(Maybe just a type s/EID/SDNV/?)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#23 What makes =
you think an 80-bit MAC is less good at error =
detection<br></blockquote><blockquote type=3D"cite">than a (known weak) =
128 bit digest? Such statements are better =
deleted<br></blockquote><blockquote type=3D"cite">(or else justified =
with references).<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#24 "Although =
the BSP was intended..." again the authors appear =
confused<br></blockquote><blockquote type=3D"cite">about compliance - =
this document does not UPDATE 5050 (not sure =
what<br></blockquote><blockquote type=3D"cite">that'd mean for an =
experimental RFC anyway) so discussion of =
things<br></blockquote><blockquote type=3D"cite">that are "needed" by BP =
implementations is off base. This is even<br></blockquote><blockquote =
type=3D"cite">clearer in the next paragraph where the spec tries to =
impose requirements<br></blockquote><blockquote type=3D"cite">on 5050 =
implementations doing custody stuff.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#25 "...private =
keys shared only..." Private keys are never shared =
in<br></blockquote><blockquote type=3D"cite">any DTN ciphersuite. =
Another crypto-101 error.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#26 You have a =
SHOULD on dropping when checks fail. What about =
fragmentation?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#27 =
"...end-to-end private key" crypto-101 Entire paragraphs needs =
fixing.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">------------<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Editorial =
changes in the early pages. (I stopped separatng =
them<br></blockquote><blockquote type=3D"cite">after a while since there =
are so many.)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Abstract:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#1 the BP does =
not include a checksum, yet it *is* possible to do =
verification,<br></blockquote><blockquote type=3D"cite">if the BSP is =
used. The statement is misleading.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#2 "Without =
assurance...cannot" is wrong. "may not" would be =
correct.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#3 sometimes =
errored bundle forwarding is desired, suggest replacing =
"instead<br></blockquote><blockquote type=3D"cite">of..." with "where it =
may have been better to..."`<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#4 "address the =
situation" implies that this is correcting a serious =
unexpected<br></blockquote><blockquote type=3D"cite">fault which is =
disputed<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#5 "Formerly =
called" adds no value<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#6 "Regardless =
of" clause adds no value<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#7 "Divorcing" =
clause seems odd - I think you mean to say there's no need =
for<br></blockquote><blockquote type=3D"cite">keys but I don't see any =
papers being served.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#8 "necessary =
detail" why would you include unnecessary detail? =
delete<br></blockquote><blockquote =
type=3D"cite">necessary<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#9 Overall an =
abstrct like the following would be much =
better:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">The =
Delay-Tolerant Networking Bundle Protocol includes a custody =
transfer<br></blockquote><blockquote type=3D"cite">mechanism to provide =
acknowledgements of receipt for particular bundles. =
&nbsp;The<br></blockquote><blockquote type=3D"cite">bundle protocol does =
not define a checksum that allows verification =
of<br></blockquote><blockquote type=3D"cite">error-free forwarding at =
any hop on the path. This document defines =
new<br></blockquote><blockquote type=3D"cite">"keyless" data integrity =
ciphersuites for use with the Bundle =
Security<br></blockquote><blockquote type=3D"cite">Protocol's Payload =
Integrity Block that can be used to increase reliability =
in<br></blockquote><blockquote type=3D"cite">many =
situations.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Section =
1:<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">#0 this entire section could be deleted, or almost =
all<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote=
 type=3D"cite">#1 2nd para: "does not take bundle inegrity into account" =
is misleading; the BP<br></blockquote><blockquote type=3D"cite">asssumes =
that CLs do that which is different.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#2 something =
that's not always sufficient is not always insufficient to =
talking<br></blockquote><blockquote type=3D"cite">about "the =
insufficiency" is a mistatement<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#3 =
s/painstakingly// it adds nothing but pique<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#4 delivering =
errored content does not require that "all underlying layers =
pass<br></blockquote><blockquote type=3D"cite">through and accept =
errors", only perhaps that the layers in use when the =
error<br></blockquote><blockquote type=3D"cite">occurs support that, and =
with bugs, memory or file system errors not even =
that<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#5 the claim =
that the "ability to provide a check" is primary to =
"overall<br></blockquote><blockquote type=3D"cite">strength" needs a =
reference or should be deleted<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#6 last para of =
p7:s/much more important/potentially much more =
important/<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#7 same para as =
#6, everything from "the bundle protocol..does neither..." =
down<br></blockquote><blockquote type=3D"cite">to"...Internet traffic." =
should be deleted. Its only purpose seems to be to =
try<br></blockquote><blockquote type=3D"cite">make the bundle protocol =
look bad?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#8 last para: =
delete the paragraph I guess it just vituperative, hard =
to<br></blockquote><blockquote type=3D"cite">understand how it ever got =
added<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">section =
2:<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">#1 there are currently 4 block types in BSP but I don't =
think there's any need<br></blockquote><blockquote type=3D"cite">to =
discuss that, just say we're re-using PIB. There is no reason to =
discuss<br></blockquote><blockquote type=3D"cite">BAB, PCB or, now ESB =
at all.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#2 delete the =
sentence that says "truly suitable" - actually an entire page =
or<br></blockquote><blockquote type=3D"cite">so can best be deleted =
here, incl. the "what's a MAC" part.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#3 The "in =
fact, several popular" sentence gets it wrong, some digest algs =
are<br></blockquote><blockquote type=3D"cite">used for =
MACs<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><br></div></blockquote></div><br></body></html>=

--Apple-Mail-2--704489759--

From: Kevin Fall <[email-masked]>
To: DTN interest <[email-masked]>
Date: Thu, 19 Mar 2009 00:34:45 -0700
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-checksum

I also have a number of comments on this draft which I believe we can  
cover on thursday.
At a high level, the authors appear to wish to explain both the  
approach and its (comparatively
lengthy) rationale.  I believe the rationale belongs elsewhere,  
possibly in an informational
document that discusses reliability, integrity and the BP.  I believe  
this will help promote getting
the technical details through the process.

A couple of other things brought up by this draft:

should a bundle somehow indicate an app's {non}desire for error free  
bundles
need any corresponding API have the ability to specify this?
that there should possibly be a configuration flag in bundle agents  
indicating whether bundles failing integrity checks are dropped
(and/or whether the integrity check is applied at all-- note that we  
may be running in a high performance network as well).

- K

On Mar 16, 2009, at Mar 167:50 AMPDT, Stephen Farrell wrote:

>
> My comments on the first part (up to the end of section 3, I ran
> out of time since there was so much that needed comment) are
> attached. This is not ready IMO, I'd guess a couple more
> revs are needed before it'd be done.
>
> Stephen.
>
>
>
> SF comments on draft-irtf-dtnrg-checksum
>
> 20090312
>
> General
>
> #0 There are many editorial changes required. There are numerous  
> erroneous,
> imprecise or misleading statements that should be removed (examples  
> below).
> There are also many sections of text that appear to be discussing  
> "DTN history
> before checksums." While such text might be interesting for some it  
> doesn't IMO
> belong in an experimental RFC unless it is beneficial for  
> implementers (again,
> examples below). Basically what should be a useful specification is  
> sometimes
> almost a rant which is inappropriate. (In addition to my opinion on  
> this, the
> IRSG review specifically aims to ensure that the content is as  
> suitable as
> journal content, so this kind of change will be needed later anyway  
> its not
> just me being a pain)
>
> #1 I think a lot of the motivation stuff could be removed and that  
> that'd
> improve the document. Simpler/shorter is better.
>
> #2 The BSP has the concept of end-to-end-ishness where e.g. the  
> security source
> might not be the actual source. That's mainly to cater for less  
> capable nodes
> at the edges, and is probably not needed here, but worth asking  
> anyway. Are
> there any cases where it'd make sense to add a checksum in the  
> middle of a path
> or to strip one in the middle of a path?
>
> #3 A lot of the discussion about integrity only applies for accidental
> integrity violations. There should be a statement up front saying  
> that this
> draft doesn't consider deliberate integrity violations and that  
> those are
> address by other ciphersuites, e.g. in the BSP spec.
>
> #4 I'm totally unclear as to why there need to be three  
> ciphersuites.  Is
> there a real justification for anything other than min and max here?
>
> #5 origin authentication is not non-repudiation (if such exists as a  
> network
> service) as any security primer would tell you
>
> #6 MD5 is not a checksum algorithm, it is a digest alg. which is a  
> different
> beast (second pre-image resistance etc.)
>
> #7 You're probably better off removing the downref to my expired key  
> mgmt draft
> (draft-farrell-dtnrg-km) since someone starting over on that might  
> not base on
> that draft, which'd leave the eventual RFC with a bad pointer.
>
> #8 If you want to make the claim that using the PIB is problematic  
> for some
> reason, you need to justify that. Just saying "not designed  
> for." (which is
> ungrammatic as used) is not sufficient.
>
> #9 (sigh) The use of the term private key seems to indicate a lack of
> familiarity with crypto mechanisms. Public keys are used to verify  
> signatures.
> "3rd party intermediate nodes that do not possess that private  
> key..." is a
> crypto-101 error.
>
> #10 The RSA/SHA256 ciphersuite is criticised for some odd reason.  
> That adds
> nothing and should be deleted. (The sentence includes the terms  
> "excessive" and
> "disadvantageous.") If you are arguing that keyed ciphersuites are  
> not what you
> need then such points are superflous and would only serve to confuse  
> a reader.
>
> #11 What is a "NULL key pair"? As far as I'm aware this is the first  
> time
> anyone's suggested using a known key for RSA ever. (No one else has  
> becuase
> it'd be silly, a known symmetric key is similar strength and far  
> easier.) I
> don't believe anyone has ever suggested re-using an existing  
> ciphersuite with a
> known key, all previous cases invent a new ciphersuite. There is  
> really no
> point in discussing obviously silly design choices that could have  
> been made by
> someone not skilled in the art.  (Actually, just deleting that  
> entire paragraph
> is best.)
>
> #12 BAB-HMAC discussion. I'm not sure if its a good idea to opine  
> here on
> changes that "could" be made to the BP, but if that remains, it  
> should at least
> say "a future version of the BP." Noting that the BP doesn't mandate  
> the BSP is
> fine, but the future looking stuff might confuse a reader, so I'd  
> leave it out.
> Saying that some "path" seems to be desirable is also needlessly  
> confusing,
> this document should just specify and explain the new ciphersuites  
> and not be
> as argumentative.
>
> #13 Mention of your "previous proposal" adds nothing and exposes an  
> apparent
> minsunderstanding on the author's part of compliance. This spec can  
> and should
> define new PIB ciphersuites. There is no reason why conforming  
> implementations
> should also have to implement other ciphersuites as well.  (And again
> "heavyweight" is purely pejorative so remove that.)
>
> #14 The "insecure ciphersuites might give a false impression of  
> security"
> argument seems to me to be bogus. Have there ever been any cases  
> where IPsec or
> TLS equivalents were accidentally used? This could be a security  
> cconsideration
> to point out to coders that they shouldn't confuse administrators in  
> user
> interfaces, but is not a real issue in terms of the bits on the  
> wire..  (I do
> like the idea of naming these ciphersuites INSECURE or something,  
> but that
> doesn't mean there's a real issue here.)
>
> #15 "SHOULD subjective ensure" is very odd.
>
> #16 I don't follow why logging output is significant enough for a  
> MUST NOT?
>
> #17 The requirement that any future similar ciphersuite be called  
> "INSECURE" is
> broken. Just say that these ciphersuites are called that and you're  
> done. Also
> PIBs using these are not indistinguishable from those with secure  
> ciphersuites
> - that's the whole point of the ciphersuite types. You're confusing  
> the name of
> the ciphersuites (that might appear in GUIs) with the bits on the  
> wire where
> no such confusion arises.
>
> #18 You seem to contradict yourself when you say that things MUST be  
> called
> INSECURE_* but then say that PIB-HMAC with NULL keys is ok. I think  
> one or the
> other is ok, but not both. I think that PIB-HMAC if its useful (and  
> it could
> be) ought be in a different document (probably BSP) and the NULL key  
> version
> should be here as its own ciphersuite. (Or just omitted, I'm not  
> sure who wants
> PIB-HMAC-WITH-NULL?)
>
> #19 Talking about what BP implementations MUST support is missing  
> the point.
> This spec should talk about what implementations doing this spec  
> MUST support
> and not others.
>
> #20 Mutable c14n is defined in the BSP and not in appendix A.1 The  
> PIB wire
> format is defined in the BSP and not in appendix A.2. As-is, both  
> inaccurate
> statements would mislead implementers.
>
> #21 Using a zero KeyID as the indicator of a NULL ciphersuite is a bad
> choice IMO. (It should be a separate ciphersuite as explained  
> above.) The
> problem is that there are times when shared secrets are used without
> KeyIDs (which is bad practice, but happens). A zero KeyID is too easy
> for a coder to mistake as a missing KeyID so its better to either have
> the same semantic or none.
>
> #22 end of p12, I don't get what "the later two EIDs" means? Needs  
> some
> clarification I guess. (Maybe just a type s/EID/SDNV/?)
>
> #23 What makes you think an 80-bit MAC is less good at error detection
> than a (known weak) 128 bit digest? Such statements are better deleted
> (or else justified with references).
>
> #24 "Although the BSP was intended..." again the authors appear  
> confused
> about compliance - this document does not UPDATE 5050 (not sure what
> that'd mean for an experimental RFC anyway) so discussion of things
> that are "needed" by BP implementations is off base. This is even
> clearer in the next paragraph where the spec tries to impose  
> requirements
> on 5050 implementations doing custody stuff.
>
> #25 "...private keys shared only..." Private keys are never shared in
> any DTN ciphersuite. Another crypto-101 error.
>
> #26 You have a SHOULD on dropping when checks fail. What about  
> fragmentation?
>
> #27 "...end-to-end private key" crypto-101 Entire paragraphs needs  
> fixing.
>
> ------------
>
> Editorial changes in the early pages. (I stopped separatng them
> after a while since there are so many.)
>
> Abstract:
>
> #1 the BP does not include a checksum, yet it *is* possible to do  
> verification,
> if the BSP is used. The statement is misleading.
>
> #2 "Without assurance...cannot" is wrong. "may not" would be correct.
>
> #3 sometimes errored bundle forwarding is desired, suggest replacing  
> "instead
> of..." with "where it may have been better to..."`
>
> #4 "address the situation" implies that this is correcting a serious  
> unexpected
> fault which is disputed
>
> #5 "Formerly called" adds no value
>
> #6 "Regardless of" clause adds no value
>
> #7 "Divorcing" clause seems odd - I think you mean to say there's no  
> need for
> keys but I don't see any papers being served.
>
> #8 "necessary detail" why would you include unnecessary detail? delete
> necessary
>
> #9 Overall an abstrct like the following would be much better:
>
> The Delay-Tolerant Networking Bundle Protocol includes a custody  
> transfer
> mechanism to provide acknowledgements of receipt for particular  
> bundles.  The
> bundle protocol does not define a checksum that allows verification of
> error-free forwarding at any hop on the path. This document defines  
> new
> "keyless" data integrity ciphersuites for use with the Bundle Security
> Protocol's Payload Integrity Block that can be used to increase  
> reliability in
> many situations.
>
> Section 1:
>
> #0 this entire section could be deleted, or almost all
>
> #1 2nd para: "does not take bundle inegrity into account" is  
> misleading; the BP
> asssumes that CLs do that which is different.
>
> #2 something that's not always sufficient is not always insufficient  
> to talking
> about "the insufficiency" is a mistatement
>
> #3 s/painstakingly// it adds nothing but pique
>
> #4 delivering errored content does not require that "all underlying  
> layers pass
> through and accept errors", only perhaps that the layers in use when  
> the error
> occurs support that, and with bugs, memory or file system errors not  
> even that
>
> #5 the claim that the "ability to provide a check" is primary to  
> "overall
> strength" needs a reference or should be deleted
>
> #6 last para of p7:s/much more important/potentially much more  
> important/
>
> #7 same para as #6, everything from "the bundle protocol..does  
> neither..." down
> to"...Internet traffic." should be deleted. Its only purpose seems  
> to be to try
> make the bundle protocol look bad?
>
> #8 last para: delete the paragraph I guess it just vituperative,  
> hard to
> understand how it ever got added
>
> section 2:
>
> #1 there are currently 4 block types in BSP but I don't think  
> there's any need
> to discuss that, just say we're re-using PIB. There is no reason to  
> discuss
> BAB, PCB or, now ESB at all.
>
> #2 delete the sentence that says "truly suitable" - actually an  
> entire page or
> so can best be deleted here, incl. the "what's a MAC" part.
>
> #3 The "in fact, several popular" sentence gets it wrong, some  
> digest algs are
> used for MACs
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 19 Mar 2009 03:23:53 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

On Tue, Mar 17, 2009 at 10:08:33PM -0700, Burleigh, Scott C wrote:
> 
> The boilerplate is all coming from xml2rfc, and if xml2rfc is no
> longer implementing 2119 then I agree that there shouldn't be any
> references to 2119 in the document.

Ah, I see.  xml2frc doesn't capitalize your MUSTs and SHOULDs and such
like, AFAIK, so the issue is just that xml2rfc inserts this without
checking whether the 2119-words are used anywhere, I guess.  I sort of
feel like some of the musts and shoulds and such ought to be
2119-word versions instead, but I don't feel so strongly about this
that I think it's worth insisting.  If you want some suggestions,
though, let me know (I guess off list?) and I can happily send them.
 
> I think it is indeed possible (anomalous, but still possible) for a
> CBHE-unaware CLA to receive -- and simply pass upward -- a
> CBHE-compressed bundle.  This would not be good, but I don't think
> any bundle agents would be at risk of damage: when the bundle is
> parsed, the zero in dictionary length should be clue to the
> receiving bundle agent that the bundle is corrupt and should simply
> be discarded.  I figure that receiving node will start to look like
> a black hole and upstream nodes will start routing around it, which
> is the behavior we would want.  There would be some data loss for a
> while, which custodial retransmission should be able to compensate
> for, and then the network should be okay again.

Ok, this is pretty much what I was sort of worried about.  I think
you're probably right, but it would be nice to have a sentence saying
that there is this possibility, but the zero dictionary length should
protect the network.

Thanks for the careful responses!

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Date: Thu, 19 Mar 2009 03:17:05 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

On Tue, Mar 17, 2009 at 09:52:56PM -0700, Burleigh, Scott C wrote:

> example) individual national space agencies might want to assign
> node numbers to their own spacecraft; I'm inclined to just leave it
> undetermined at this point.

Given that this targets experimental use, I can support that
approach.  Just for the record (but I guess obviously), if it were to
be later considered for the standards track, it would need an
IANA-or-something registry.  For sure, though, if there's not to be a
careful specification of some mechanism to guarantee uniqueness, it's
pretty important the document make that clear.  Then potential
experimenters in this field can understand that they had better make
sure to co-ordinate with others.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Content-class: urn:content-classes:message
Date: Wed, 18 Mar 2009 19:30:43 -0400
From: "John Setzer" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest]  "last call" comments on the latest BSP

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A821.93BA6AEA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I just started working with the Bundle Security Protocol this month, and
I had an exceptionally hard time understanding your RFC because it is
rather complicated as other members of the group have already pointed
out.  If the DTNRG is going to be redrafting this specification this
weekend in Mountain View anyway, I'd like my comments to be taken into
consideration so the next person that reads the BSP draft for the first
time doesn't have to reread it as many times as I had to.  I hope my
input helps.

=20

1.  It would be really nice if you added some diagrams showing the
interleaving of various bundles in a semi-complicated example that
demonstrated common what-ifs that a trivial example wouldn't wouldn't
show.  It may be better to split this large example up into pieces and
put the pieces with the corresponding parts of the RFC.

An example, with comments clarifying confusing points:

A. A bundle node wants to encrypt the following message:

|--Primary Block -----|

|--Extension Block A--|

|--Extension Block B--|

|--Payload Block------|

=20

B. First it encrypts extension block A and the payload with correlated
PCBs.  Note that extension block A is replaced by a PCB and the payload
is not.  PCB_A and PCB_Payload have the same correlator value. PCB's
security result=3Dencrypt(ExtBlockA).  PCB_Payload's security
result=3Dauthentication tag from encrypting the payload.

|--Primary Block------|

|--PCB_A--------------|

|--Extension Block B--|

|--PCB_Payload--------|

|--Encrypted Payload--|

=20

C. Next, extension block B is protected with an ESB.

|--Primary Block------|

|--PCB_A--------------|

|--ESB_B--------------|

|--PCB_Payload--------|

|--Encrypted Payload--|

=20

D. Finally PIBs and a BAB are added.  Both PIBs have the same
correlator.  Both BABs have the same correlator. =20

|--Primary Block------|

|--BAB with params----|

|--PIB with params----|

|--PCB_A--------------|

|--ESB_B--------------|

|--PCB_Payload--------|

|--Encrypted Payload--|

|--PIB with result----|

|--BAB with result----|

=20

E. Bundle Node 1(BN1) forwards the packet from part D to Bundle Node 2
(BN2).  BN2 removes BN1's BABs, adds its own BABs, and forwards the
packet to BN3.

|--Primary Block------|

|--BAB_BN2------------|

|--PIB_BN1------------|

|--PCB_A--------------|

|--ESB_B--------------|

|--PCB_Payload--------|

|--Encrypted Payload--|

|--PIB_BN1------------|

|--BAB_BN2------------|

=20

2. The RFC's examples mention using two correlated BABs, two correlated
PIBs, and 1 to N correlated PCBs; however it never explicitly forbids
using 1 to N BABs or PIBs.  The way the group uses BABs and PIBs, the 1
to N case doesn't really make sense anyway, but I suppose you could use
the 1 to N case to pick and choose which blocks you wanted to
authenticate.  If it is the groups intention to only use 1 or 2 BABs or
PCBs and never to use the 1 to N case, I think you should explicitly
forbid blocks 3 to N for BABs and PIBs.  In such a case, I think you
should change your "first instance" and "second instance" nomenclature
to "leading instance" and "trailing instance" so that this point is even
clearer.

=20

3. In the following statement I think you should change
"super-encrypt.*" to "encrypt.*".  After reading this I spent a long
time trying to decided if you had redefined "super-encrypt" to mean
encrypt several things together or if I had missed something, which I
may still be missing.  It is my understanding that super-encrypt means
to encrypt the same cleartext several times in a row.

=20

   "It is RECOMMENDED to apply a Payload

   Confidentiality ciphersuite to non-payload blocks only if these

   should be super-encrypted with the payload.  If super-encryption of

   the block is not desired then protection of the block should be done

   using the Extension Security Block mechanism rather than PCB."

=20

4. "block-specific IV item" is kind of ambiguous.  It should be changed
to something like "PCB instance-specific IV item".

=20

=20

=20

/**********************************************/

 * I also have some general commentary on the general=20

 * structure of BSP.

 **********************************************/

=20

1. In regard to the following, I think it would be good to separate the
ciphersuite from the decision of which blocks to encrypt.  I think this
is analogous to the discussion on the mailing list about separating the
protocol rules and the mandatory ciphersuites.  If you are the
programmer implementing this you don't want to change your bundle
parsing code just because you changed ciphersuites.  You really want
those two things to be two independent policies.  Personally, I would be
in favor of saying the PCB could only encrypt the payload and no other
blocks if it weren't for the fact this would add many bits to a bundle.

=20

   "PCB ciphersuites MUST specify which blocks are to be encrypted.  The

   specification MAY be flexible and be dependent upon block type,

   security policy, various data values and other inputs but it MUST be

   deterministic.  The determination of whether a block is to be

   encrypted or not MUST NOT be ambiguous."

=20

=20

2. I don't think you need or want a second BAB or PIB to trail the
payload.  The RFC says, "This allows even very memory-constrained nodes
to be able to process the bundle and verify the BAB."  I don't think
this saves memory, and I think you are using this second block to mark
the end of the authenticated region instead.  Do you really think you
are saving a significant amount of memory since you are going to have to
save an extra copy of the first six fields of a BAB and all of the extra
programming logic to accommodate parsing an extra block?  Besides space
isn't the most precious resource.  Bits sent across the physical layer,
battery life, and programmer time are more precious.  Even if they
aren't right now, Moore's Law will make that the case next year.  You
should add a "bytes authenticated count" to the "ciphersuite params" and
add the security result to the first BAB. This reduces the number of
bits the physical layer has to transmit by removing an entire block.

=20

-John Setzer, Trident Systems

------_=_NextPart_001_01C9A821.93BA6AEA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>I just =
started
working with the Bundle Security Protocol this month, and I had an
exceptionally hard time understanding your RFC because it is rather =
complicated
as other members of the group have already pointed out.&nbsp; If the =
DTNRG is
going to be redrafting this specification this weekend in Mountain View =
anyway,
I'd like my comments to be taken into consideration so the next person =
that
reads the BSP draft for the first time doesn't have to reread it as many =
times
as I had to.&nbsp; I hope my input helps.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>1.&nbsp; =
It would be
really nice if you added some diagrams showing the interleaving of =
various
bundles in a semi-complicated example that demonstrated common what-ifs =
that a
trivial example wouldn't wouldn't show.&nbsp; It may be better to split =
this
large example up into pieces and put the pieces with the corresponding =
parts of
the RFC.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>An =
example, with
comments clarifying confusing points:<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>A. A =
bundle node
wants to encrypt the following message:<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Primary Block
-----|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Extension Block
A--|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Extension Block
B--|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Payload
Block------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>B. First =
it encrypts
extension block A and the payload with correlated PCBs.&nbsp; Note that =
extension
block A is replaced by a PCB and the payload is not.&nbsp; PCB_A and
PCB_Payload have the same correlator value. PCB's security
result=3Dencrypt(ExtBlockA).&nbsp; PCB_Payload's security =
result=3Dauthentication
tag from encrypting the payload.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Primary
Block------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PCB_A--------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Extension Block
B--|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PCB_Payload--------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Encrypted
Payload--|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>C. Next, =
extension
block B is protected with an ESB.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Primary Block------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PCB_A--------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--ESB_B--------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PCB_Payload--------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Encrypted
Payload--|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>D. =
Finally PIBs and
a BAB are added.&nbsp; Both PIBs have the same correlator.&nbsp; Both =
BABs have
the same correlator.&nbsp; <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Primary
Block------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>|--BAB =
with
params----|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>|--PIB =
with
params----|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PCB_A--------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--ESB_B--------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PCB_Payload--------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Encrypted
Payload--|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>|--PIB =
with
result----|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>|--BAB =
with
result----|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>E. Bundle =
Node
1(BN1) forwards the packet from part D to Bundle Node 2 (BN2).&nbsp; BN2
removes BN1's BABs, adds its own BABs, and forwards the packet to =
BN3.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Primary
Block------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--BAB_BN2------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PIB_BN1------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PCB_A--------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--ESB_B--------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PCB_Payload--------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--Encrypted
Payload--|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--PIB_BN1------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>|--BAB_BN2------------|<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>2. The =
RFC's
examples mention using two correlated BABs, two correlated PIBs, and 1 =
to N
correlated PCBs; however it never explicitly forbids using 1 to N BABs =
or
PIBs.&nbsp; The way the group uses BABs and PIBs, the 1 to N case =
doesn't
really make sense anyway, but I suppose you could use the 1 to N case to =
pick
and choose which blocks you wanted to authenticate.&nbsp; If it is the =
groups
intention to only use 1 or 2 BABs or PCBs and never to use the 1 to N =
case, I think
you should explicitly forbid blocks 3 to N for BABs and PIBs.&nbsp; In =
such a
case, I think you should change your &quot;first instance&quot; and
&quot;second instance&quot; nomenclature to &quot;leading instance&quot; =
and
&quot;trailing instance&quot; so that this point is even =
clearer.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>3. In the =
following
statement I think you should change &quot;super-encrypt.*&quot; to
&quot;encrypt.*&quot;.&nbsp; After reading this I spent a long time =
trying to
decided if you had redefined &quot;super-encrypt&quot; to mean encrypt =
several
things together or if I had missed something, which I may still be
missing.&nbsp; It is my understanding that super-encrypt means to =
encrypt the
same cleartext several times in a row.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;
&quot;It is RECOMMENDED to apply a Payload<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;
Confidentiality ciphersuite to non-payload blocks only if =
these<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp; should
be super-encrypted with the payload.&nbsp; If super-encryption =
of<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp; the
block is not desired then protection of the block should be =
done<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp; using
the Extension Security Block mechanism rather than =
PCB.&quot;<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>4.
&quot;block-specific IV item&quot; is kind of ambiguous.&nbsp; It should =
be changed
to something like &quot;PCB instance-specific IV =
item&quot;.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>/**********************************************/<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>&nbsp;* I =
also have
some general commentary on the general <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>&nbsp;* =
structure of
BSP.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;**********************************************/<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>1. In =
regard to the
following, I think it would be good to separate the ciphersuite from the
decision of which blocks to encrypt.&nbsp; I think this is analogous to =
the
discussion on the mailing list about separating the protocol rules and =
the mandatory
ciphersuites.&nbsp; If you are the programmer implementing this you =
don't want
to change your bundle parsing code just because you changed =
ciphersuites.&nbsp;
You really want those two things to be two independent policies.&nbsp;
Personally, I would be in favor of saying the PCB could only encrypt the
payload and no other blocks if it weren't for the fact this would add =
many bits
to a bundle.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;
&quot;PCB ciphersuites MUST specify which blocks are to be =
encrypted.&nbsp; The<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;
specification MAY be flexible and be dependent upon block =
type,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;
security policy, various data values and other inputs but it MUST =
be<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;
deterministic.&nbsp; The determination of whether a block is to =
be<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;
encrypted or not MUST NOT be ambiguous.&quot;<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>2. I =
don't think you
need or want a second BAB or PIB to trail the payload.&nbsp; The RFC =
says,
&quot;This allows even very memory-constrained nodes to be able to =
process the
bundle and verify the BAB.&quot;&nbsp; I don't think this saves memory, =
and I
think you are using this second block to mark the end of the =
authenticated
region instead.&nbsp; Do you really think you are saving a significant =
amount
of memory since you are going to have to save an extra copy of the first =
six
fields of a BAB and all of the extra programming logic to accommodate =
parsing
an extra block?&nbsp; Besides space isn't the most precious =
resource.&nbsp;
Bits sent across the physical layer, battery life, and programmer time =
are more
precious.&nbsp; Even if they aren't right now, Moore's Law will make =
that the
case next year.&nbsp; You should add a &quot;bytes authenticated =
count&quot; to
the &quot;ciphersuite params&quot; and add the security result to the =
first
BAB. This reduces the number of bits the physical layer has to transmit =
by
removing an entire block.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>-John =
Setzer,
Trident Systems<o:p></o:p></span></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9A821.93BA6AEA--

Date: Wed, 18 Mar 2009 12:27:51 -0400
From: Rajesh Krishnan <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples

Wes:

I will let Prithwish answer questions on SPINDLE naming specifics.

My thought is that naming should be available as a standard,
efficient, extensible "network" service to all applications uniformly.
When I say efficient, I mean that lightweight approaches for space and
underwater applications must be well supported.  When I say
extensible, I mean application communities should be able to define
and extend namespaces that can interoperate.  Namespaces can be driven
by the underlying technologies too -- "send to node with IPv4 address
xx.xx.xx.xx" does not necessarily mean use IPv4 to deliver (with DTN
late binding).

Mobility management is inescapable reality for routing and naming in
any mobile network; late binding is needed, however, even in DTNs with
other dynamic name attributes (e.g., names based on variable role
assignments).  I imagine that some applications would benefit from
location and role based naming.

Namespace management (dissemination of naming attributes/values and
resolution capabilities) could be done through a publish-subscribe
mechanism; much work is needed on efficient and reliable dissemination
mechanisms to support name databases.  That said, it is useful to
start standardizing syntax and encapsulations.

Folks interested in this topic may want to take a look at work in the
HANDLE project (www.handle.net) and Transient Network Architecture
(TNA) by Jerez et al at CNRI which builds on Handle.

Best Regards,
Rajesh

On Tue, Mar 17, 2009 at 2:36 PM, Eddy, Wesley M. (GRC-RCN0)[Verizon]
<[email-masked]> wrote:
>>-----Original Message-----
>>From: Rajesh Krishnan [mailto:[email-masked]]
>>Sent: Tuesday, March 17, 2009 2:02 PM
>>
>>Wes:
>>
>>It may be useful to think of late binding as a generalization. �There
>>are mobility management (in a topological sense), name to address
>>resolution, alias resolution, as well as other aspects �such as
>>maintenance of related dynamic multi-attribute naming data bases to
>>late binding.
>>
>>Mobile IP routes to the IP address of a care-of destination instead
>>the address of the actual destination; there is readdressing, �but no
>>name resolution at every step. �This procedure does not account for
>>routing on multi-attributed names (there is no further name resolution
>>post the source), or CLA parameters in heterogeneous networks.
>>
>>The SPINDLE architecture makes use of care-of resolvers that resemble
>>the foreign agent in mobile IP, but there is more to consider beyond
>>mobility management alone.
>>
>>Prithwish �may have additional insights on this topic since I recall
>>we went through the same thought process to determine how is late
>>binding not just mobility management, routing, alias resolution etc.
>
>
> I think I understand and agree; the ability for EIDs to "name" things
> that aren't just interfaces or sets of interfaces is a strong feature
> beyond normal IP-based networking.
>
> But ... if we have pub/sub applications running over a network layer
> that includes mobility management (whether Mobile IP, a MANET, etc.),
> I think that would yield a similar set of properties to SPINDLE? �It's
> certainly a different architecture, but is it functionally equivalent?
> Pub/sub systems often support store-and-forward as an option for
> messages, so the main difference I see between them and DTN is that
> they're usually not as flexible about the "convergence layer adapter"
> protocols they're wed to.
>
> So, in my mind there's a good question about placement of features in
> layers and whether content-based features belong low-down or higher-up.
> We can see there are benefits in placing them low, but what are the
> costs? �The question is complicated by the fact that DTN BP can be
> either high or low in the stack depending on your deployment case :).
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
>

From: "Burleigh, Scott C" <[email-masked]>
To: DTN interest <[email-masked]>
Date: Tue, 17 Mar 2009 22:21:01 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Naming and Addressing

--_000_FD514C8A5155C64C9B145B48D674EF544985B4191DALTPHYEMBEVSP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Maybe these statements aren't necessarily inconsistent, Will.  One way to k=
now about the authorship of the payload of a bundle is to look at the sourc=
e entity ID, and in fact for the fairly simple configurations I'd expect in=
 space networking that will most likely be the best way.  But the possibili=
ty of anonymous authorship of a bundle is explicitly recognized in the BP s=
pec (see pages 14 and 20, for example), so this would not always work.  In =
that event you've got to have an alternative mechanism - payload inspection=
, hints from the convergence-layer adapter, something - or else you've got =
to decide that verifying the identity of the source node of the bundle is s=
o important to you that you're willing to ditch the bundle if you can't do =
it.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Ivancic, William D. (G=
RC-RHN0)
Sent: Tuesday, March 17, 2009 9:30 PM
To: Kevin Fall; DTN interest
Subject: Re: [dtn-interest] Naming and Addressing

 Scott >>> In ION we address this by drawing a firm distinction between DTN=
 endpoints and underlying convergence-layer protocol "ducts", with a manage=
d mapping between the two.  The former are necessarily URIs, but the latter=
 are not.

Kevin > I think in most cases you don't care about the identity of a node. =
I care about the identity of the bundle source node.  If I am receiving a P=
ayload Confidentiality Block or Bundle Authentication Block, I need to matc=
h the identity to the proper crypto key/certificate.  This may be an indire=
ct identification if the source node can provide me the proper key ID and I=
 have that key/certificate, than I may feel pretty comfortable that I trust=
 the source node.

Kevin > You care about the authorship of data.

Authorship of the Data in side the bundle or the Bundle or authorship of th=
e bundle itself?

I see the data inside the bundle as not visible to the DTN network.  Who cr=
eated the bundle and  requesting use of  my resources is of interest to my =
bundle forwarding agent.  I may be willing to pass bundles created by Scott=
 or coming from other people who are associated in some way with Scott - Sc=
ott's friends.  However, I may not want to pass Kevin's bundles or bundles =
from people who associate with Kevin.  So, how do I determine who is associ=
ated with Scott and who is associated with Kevin in a way the scales?

Hmmm - I'm at Google the next three days, maybe I should post this problem =
on the wall in the morning and see if there is an answer later in the day! =
 :-)

/will

--_000_FD514C8A5155C64C9B145B48D674EF544985B4191DALTPHYEMBEVSP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2=3D=
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"http://sc=
hemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.micro=
soft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/=
xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:u=
dc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org=
/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/=
2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"=
http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.micro=
soft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-in=
stance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udc=
xf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http:/=
/schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.micr=
osoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft=
.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/o=
ffice/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package=
/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats.org/ma=
rkup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/200=
4/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/re=
lationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" xm=
lns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types" xml=
ns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messages" x=
mlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" x=
mlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Publis=
hedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" x=
mlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple style=3D'WORD-WRAP: break-wor=
d;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Maybe these statements aren&#8217;t necessarily inconsistent=
,
Will.&nbsp; One way to know about the authorship of the payload of a bundle=
 is
to look at the source entity ID, and in fact for the fairly simple configur=
ations
I&#8217;d expect in space networking that will most likely be the best
way.&nbsp; But the possibility of anonymous authorship of a bundle is expli=
citly
recognized in the BP spec (see pages 14 and 20, for example), so this would=
 not
always work.&nbsp; In that event you&#8217;ve got to have an alternative
mechanism &#8211; payload inspection, hints from the convergence-layer adap=
ter,
something &#8211; or else you&#8217;ve got to decide that verifying the ide=
ntity
of the source node of the bundle is so important to you that you&#8217;re
willing to ditch the bundle if you can&#8217;t do it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Scott<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Ivancic,
William D. (GRC-RHN0)<br>
<b>Sent:</b> Tuesday, March 17, 2009 9:30 PM<br>
<b>To:</b> Kevin Fall; DTN interest<br>
<b>Subject:</b> Re: [dtn-interest] Naming and Addressing<o:p></o:p></span><=
/p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue=
'>&nbsp;Scott&nbsp;&gt;&gt;&gt;&nbsp;</span>In
ION we address this by drawing a firm distinction between DTN endpoints and
underlying convergence-layer protocol &quot;ducts&quot;, with a managed map=
ping
between the two. &nbsp;The former are necessarily URIs, but the latter are =
not.<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue=
'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal>Kevin &gt;&nbsp;I think in most cases you don't care a=
bout
the identity of a node. <span style=3D'font-size:10.0pt;font-family:"Arial"=
,"sans-serif";
color:blue'>I care about the identity of the&nbsp;bundle source node.&nbsp;
If&nbsp;I am receiving&nbsp;a Payload Confidentiality Block or&nbsp;Bundle
Authentication Block, I need to match the&nbsp;identity to the proper crypt=
o
key/certificate.&nbsp; This may be an indirect identification if the source
node can provide me the proper key&nbsp;ID and I have that key/certificate,
than I may&nbsp;feel&nbsp;pretty comfortable that&nbsp;I trust the source
node.&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'color:black'>Kevin &gt;&nbsp;You care a=
bout the
authorship of data.</span><span style=3D'font-size:10.0pt;font-family:"Aria=
l","sans-serif";
color:blue'><br>
<br>
Authorship of the Data in&nbsp;side the bundle or the Bundle or authorship =
of
the bundle itself?&nbsp;&nbsp;&nbsp; </span><o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:blue'>I see the data inside the bundle as not visible to the DTN
network.&nbsp; Who&nbsp;created the bundle and&nbsp; requesting use of&nbsp=
; my
resources is&nbsp;of interest to my bundle forwarding agent.&nbsp; I&nbsp;m=
ay
be willing to pass bundles created by Scott or coming from other
people&nbsp;who are associated in some way with Scott -
Scott's&nbsp;friends.&nbsp; However, I may not want to pass Kevin's bundles=
 or
bundles from people who associate with Kevin.&nbsp; So, how do I determine =
who
is associated with Scott and who is associated with Kevin in a way the scal=
es?</span><o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:blue'>Hmmm - I'm at Google the next three days, maybe I should post t=
his
problem on the wall in the morning and see if there is an answer later in t=
he
day!&nbsp; :-)</span><o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:blue'>/will</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_FD514C8A5155C64C9B145B48D674EF544985B4191DALTPHYEMBEVSP_--

From: "Burleigh, Scott C" <[email-masked]>
To: Andrew Sullivan <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2009 22:08:33 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, March 13, 2009 10:56 AM
> To: [email-masked]
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> On Thu, Mar 05, 2009 at 06:54:03PM +0000, Stephen Farrell wrote:
> >
> > This message starts the "last call" on the Compressed
> > Bundle Header Encoding draft. [1]
> 
> Dear colleagues,
> 
> I have read draft-irtf-dtnrg-cbhe-01.  I have some minor comments.
> 
> I note that the draft includes the RFC 2119 language specification,
> but that it doesn't actually use the 2119 forms.  There are some
> places in the draft where I think the 2119 language could be used, but
> if it isn't to be, the boilerplate might as well be dropped.

The boilerplate is all coming from xml2rfc, and if xml2rfc is no longer implementing 2119 then I agree that there shouldn't be any references to 2119 in the document.

> In §3, the draft notes that CBHE is opaque to bundle processing but
> affects interoperation of convergence layer adaptation
> implementations.  I think I have convinced myself it's safe because of
> the rules in §2.1, but is there any risk that a CBHE-unaware
> convergence layer adaptation implementation will see CBHE stuff due to
> endpoint form (a)?  I haven't been able to figure out how it would be
> possible, but I thought I'd ask just in case.

I think it is indeed possible (anomalous, but still possible) for a CBHE-unaware CLA to receive -- and simply pass upward -- a CBHE-compressed bundle.  This would not be good, but I don't think any bundle agents would be at risk of damage: when the bundle is parsed, the zero in dictionary length should be clue to the receiving bundle agent that the bundle is corrupt and should simply be discarded.  I figure that receiving node will start to look like a black hole and upstream nodes will start routing around it, which is the behavior we would want.  There would be some data loss for a while, which custodial retransmission should be able to compensate for, and then the network should be okay again.

> I think this draft is ready to be published as an experimental RFC,
> even without either of the above two points addressed.

Thanks, Andrew.

Scott

From: Kevin Fall <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 17 Mar 2009 21:57:16 -0700
Cc: DTN interest <[email-masked]>
Subject: Re: [dtn-interest] Naming and Addressing

--Apple-Mail-21--800484357
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Mar 17, 2009, at Mar 179:29 PMPDT, Ivancic, William D. (GRC-RHN0)  
wrote:

>
>  Scott >>> In ION we address this by drawing a firm distinction  
> between DTN endpoints and underlying convergence-layer protocol  
> "ducts", with a managed mapping between the two.  The former are  
> necessarily URIs, but the latter are not.
>
> Kevin > I think in most cases you don't care about the identity of a  
> node. I care about the identity of the bundle source node.  If I am  
> receiving a Payload Confidentiality Block or Bundle Authentication  
> Block, I need to match the identity to the proper crypto key/ 
> certificate.  This may be an indirect identification if the source  
> node can provide me the proper key ID and I have that key/ 
> certificate, than I may feel pretty comfortable that I trust the  
> source node.

I should have been more clear.  This is sort of a 'high-level  
philosophy' bit on my part.  I agree that with the currently-specified  
security protocols you wind up caring about this.  But at some level,  
I think we shouldn't be caring about the identity of a node in most  
cases {there are a few exceptions, as there are cases where you care  
to identify a specific node or interface for some purposes}.  For  
example, do you care which post office you get your mail from?  You  
care that the item you received was authored by the appropriate  
entity; you care that the data has integrity.  You may care that it is  
private, and you may care that it gets delivered with some degree of  
timeliness.

>
> Kevin > You care about the authorship of data.
>
> Authorship of the Data in side the bundle or the Bundle or  
> authorship of the bundle itself?
>
> I see the data inside the bundle as not visible to the DTN network.

In the future I don't.  I see the future firewalls of the world to  
care very much about the data inside messages, as well as author, and  
not much about where messages come from or are going to.

> Who created the bundle and  requesting use of  my resources is of  
> interest to my bundle forwarding agent.  I may be willing to pass  
> bundles created by Scott or coming from other people who are  
> associated in some way with Scott - Scott's friends.

yes, correct.  But you may or not care about the particular node that  
gave it to you or what the next hop is.

> However, I may not want to pass Kevin's bundles or bundles from  
> people who associate with Kevin.  So, how do I determine who is  
> associated with Scott and who is associated with Kevin in a way the  
> scales?

Great question.  Its about the type of policies you want mapped on to  
the type of keying and key distribution you are willing to set up.   
And yes, scalability and effectiveness of this is a big issue that is  
not solved {as far as I know}.
>
> Hmmm - I'm at Google the next three days, maybe I should post this  
> problem on the wall in the morning and see if there is an answer  
> later in the day!  :-)
>
> /will

that'd sure be handy...

- K

--Apple-Mail-21--800484357
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Mar 17, 2009, =
at Mar 179:29 PMPDT, Ivancic, William D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"> <div =
style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font> <div dir=3D"ltr" align=3D"left"><br><span =
class=3D"187210104-18032009"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2">&nbsp;Scott&nbsp;>>>&nbsp;</font></span>In ION we address =
this by drawing a firm distinction between DTN endpoints and underlying =
convergence-layer protocol "ducts", with a managed mapping between the =
two. &nbsp;The former are necessarily URIs, but the latter are =
not.<br><span class=3D"187210104-18032009"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2">&nbsp;</font></span></div> <div dir=3D"ltr" =
align=3D"left"><span class=3D"187210104-18032009">Kevin >&nbsp;</span>I =
think in most cases you don't care about the identity of a node. <span =
class=3D"187210104-18032009"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2">I care about the identity of the&nbsp;bundle source =
node.&nbsp; If&nbsp;I am receiving&nbsp;a Payload Confidentiality Block =
or&nbsp;Bundle Authentication Block, I need to match the&nbsp;identity =
to the proper crypto key/certificate.&nbsp; This may be an indirect =
identification if the source node can provide me the proper key&nbsp;ID =
and I have that key/certificate, than I may&nbsp;feel&nbsp;pretty =
comfortable that&nbsp;I trust the source =
node.&nbsp;</font></span></div></div></blockquote><div><br></div>I =
should have been more clear. &nbsp;This is sort of a 'high-level =
philosophy' bit on my part. &nbsp;I agree that with the =
currently-specified security protocols you wind up caring about this. =
&nbsp;But at some level, I think we shouldn't be caring about the =
identity of a node in most cases {there are a few exceptions, as there =
are cases where you care to identify a specific node or interface for =
some purposes}. &nbsp;For example, do you care which post office you get =
your mail from? &nbsp;You care that the item you received was authored =
by the appropriate entity; you care that the data has integrity. =
&nbsp;You may care that it is private, and you may care that it gets =
delivered with some degree of timeliness.</div><div><br><blockquote =
type=3D"cite"><div style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space"> <div dir=3D"ltr" =
align=3D"left"><span class=3D"187210104-18032009"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"><font face=3D"Times New Roman" =
color=3D"#000000" size=3D"3"></font></font></span>&nbsp;</div> <div =
dir=3D"ltr" align=3D"left"><span class=3D"187210104-18032009"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"><font face=3D"Times New =
Roman" color=3D"#000000" size=3D"3">Kevin >&nbsp;You care about the =
authorship of data.</font><br><br></font></span><span =
class=3D"187210104-18032009"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2">Authorship of the Data in&nbsp;side the bundle or the Bundle =
or authorship of the bundle itself?&nbsp;&nbsp;&nbsp; =
</font></span></div> <div dir=3D"ltr" align=3D"left"><span =
class=3D"187210104-18032009"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font></span>&nbsp;</div> <div dir=3D"ltr" =
align=3D"left"><span class=3D"187210104-18032009"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2">I see the data inside the bundle as not =
visible to the DTN network. =
</font></span></div></div></blockquote><div><br></div><div>In the future =
I don't. &nbsp;I see the future firewalls of the world to care very much =
about the data inside messages, as well as author, and not much about =
where messages come from or are going to.</div><br><blockquote =
type=3D"cite"><div style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space"><div dir=3D"ltr" =
align=3D"left"><span class=3D"187210104-18032009"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2">Who&nbsp;created the bundle and&nbsp; =
requesting use of&nbsp; my resources is&nbsp;of interest to my bundle =
forwarding agent.&nbsp; I&nbsp;may be willing to pass bundles created by =
Scott or coming from other people&nbsp;who are associated in some way =
with Scott - Scott's&nbsp;friends. =
</font></span></div></div></blockquote><div><br></div><div>yes, correct. =
&nbsp;But you may or not care about the particular node that gave it to =
you or what the next hop is.</div><br><blockquote type=3D"cite"><div =
style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space"><div dir=3D"ltr" =
align=3D"left"><span class=3D"187210104-18032009"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2">However, I may not want to pass Kevin's =
bundles or bundles from people who associate with Kevin.&nbsp; So, how =
do I determine who is associated with Scott and who is associated with =
Kevin in a way the =
scales?</font></span></div></div></blockquote><div><br></div>Great =
question. &nbsp;Its about the type of policies you want mapped on to the =
type of keying and key distribution you are willing to set up. &nbsp;And =
yes, scalability and effectiveness of this is a big issue that is not =
solved {as far as I know}.<br><blockquote type=3D"cite"><div =
style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space"> <div dir=3D"ltr" =
align=3D"left"><span class=3D"187210104-18032009"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div> <div dir=3D"ltr" =
align=3D"left"><span class=3D"187210104-18032009"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2">Hmmm - I'm at Google the next three days, =
maybe I should post this problem on the wall in the morning and see if =
there is an answer later in the day!&nbsp; :-)</font></span></div> <div =
dir=3D"ltr" align=3D"left"><span class=3D"187210104-18032009"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div> =
<div dir=3D"ltr" align=3D"left"><span class=3D"187210104-18032009"><font =
face=3D"Arial" color=3D"#0000ff" =
size=3D"2">/will</font></span></div></div></blockquote></div><div><br></di=
v><div>that'd sure be handy...</div><div><br></div><div>- =
K</div><br></body></html>=

--Apple-Mail-21--800484357--

From: "Burleigh, Scott C" <[email-masked]>
To: Andrew Sullivan <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2009 21:52:56 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, March 13, 2009 11:05 AM
> To: [email-masked]
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> On Tue, Mar 10, 2009 at 05:03:51PM -0700, Burleigh, Scott C wrote:
> 
> > If some other DTN user community wanted to adopt CBHE for its
> > private purposes, cool, it could certainly be its own node number
> > allocation authority even without registering a CBHE-like spec based
> > on a different authority ID.
> >
> > If we wanted those two user communities to interoperate, though,
> > they would have to agree on a common node number allocation
> > authority structure, maybe one that's federated in some way.  In
> > order to have the two communities interoperate using CBHE when one
> > of them uses "cbhe.ccsds.org" as authority ID and the other uses
> > "your.domain.net" as authority ID, we would have to change the
> > definition of CBHE.  As the I-D is written, if your authority ID
> > isn't "cbhe.ccsds.org" you're not CBHE conformant -- there isn't any
> > way to decompress back to the correct authority ID string, because
> > neither that string nor any compressed representation of it is
> > carried anywhere in the compressed bundle.
> 
> It seems to me that if such a case crops up, a new document specifying
> some kind of registration rules will be necessary, no?  I sure
> interpreted the cbhe.ccsds.org (b) form to be a promise of some sort
> of registration authority at that point, to avoid collisions.  If it's
> _not_ such a commitment, then that seems to me to be something that
> will need addressing, even if just by a single sentence in the
> document saying, "No promises about uniqueness here."

Good point, Andrew.  I don't think this is the right place to be defining node number allocation rules, so I agree, it would make sense to add a sentence saying that the assignment of node numbers to nodes will be accomplished by methods TBD.  My first thought is that we could ask IANA to do this, but it's also possible that (for example) individual national space agencies might want to assign node numbers to their own spacecraft; I'm inclined to just leave it undetermined at this point.

Scott

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Kevin Fall <[email-masked]>, DTN interest <[email-masked]>
Date: Tue, 17 Mar 2009 23:29:43 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Naming and Addressing

--_000_3A5AA67A8B120B48825BFFCF54438561255FBA62F8NDJSSCC03ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

 Scott >>> In ION we address this by drawing a firm distinction between DTN=
 endpoints and underlying convergence-layer protocol "ducts", with a manage=
d mapping between the two.  The former are necessarily URIs, but the latter=
 are not.

Kevin > I think in most cases you don't care about the identity of a node. =
I care about the identity of the bundle source node.  If I am receiving a P=
ayload Confidentiality Block or Bundle Authentication Block, I need to matc=
h the identity to the proper crypto key/certificate.  This may be an indire=
ct identification if the source node can provide me the proper key ID and I=
 have that key/certificate, than I may feel pretty comfortable that I trust=
 the source node.

Kevin > You care about the authorship of data.

Authorship of the Data in side the bundle or the Bundle or authorship of th=
e bundle itself?

I see the data inside the bundle as not visible to the DTN network.  Who cr=
eated the bundle and  requesting use of  my resources is of interest to my =
bundle forwarding agent.  I may be willing to pass bundles created by Scott=
 or coming from other people who are associated in some way with Scott - Sc=
ott's friends.  However, I may not want to pass Kevin's bundles or bundles =
from people who associate with Kevin.  So, how do I determine who is associ=
ated with Scott and who is associated with Kevin in a way the scales?

Hmmm - I'm at Google the next three days, maybe I should post this problem =
on the wall in the morning and see if there is an answer later in the day! =
 :-)

/will

--_000_3A5AA67A8B120B48825BFFCF54438561255FBA62F8NDJSSCC03ndcn_
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.16809" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-brea=
k: after-white-space"><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#00=
00ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT>
<DIV dir=3Dltr align=3Dleft><BR><SPAN class=3D187210104-18032009><FONT face=
=3DArial=20
color=3D#0000ff size=3D2>&nbsp;Scott&nbsp;&gt;&gt;&gt;&nbsp;</FONT></SPAN>I=
n ION we=20
address this by drawing a firm distinction between DTN endpoints and underl=
ying=20
convergence-layer protocol "ducts", with a managed mapping between the two.=
=20
&nbsp;The former are necessarily URIs, but the latter are not.<BR><SPAN=20
class=3D187210104-18032009><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009>Kevin &gt;&nbs=
p;</SPAN>I=20
think in most cases you don't care about the identity of a node. <SPAN=20
class=3D187210104-18032009><FONT face=3DArial color=3D#0000ff size=3D2>I ca=
re about the=20
identity of the&nbsp;bundle source node.&nbsp; If&nbsp;I am receiving&nbsp;=
a=20
Payload Confidentiality Block or&nbsp;Bundle Authentication Block, I need t=
o=20
match the&nbsp;identity to the proper crypto key/certificate.&nbsp; This ma=
y be=20
an indirect identification if the source node can provide me the proper=20
key&nbsp;ID and I have that key/certificate, than I may&nbsp;feel&nbsp;pret=
ty=20
comfortable that&nbsp;I trust the source node.&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2><FONT face=3D"Times New Roman" color=3D#000000=20
size=3D3></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2><FONT face=3D"Times New Roman" color=3D#000000 siz=
e=3D3>Kevin=20
&gt;&nbsp;You care about the authorship of=20
data.</FONT><BR><BR></FONT></SPAN><SPAN class=3D187210104-18032009><FONT=20
face=3DArial color=3D#0000ff size=3D2>Authorship of the Data in&nbsp;side t=
he bundle=20
or the Bundle or authorship of the bundle itself?&nbsp;&nbsp;&nbsp;=20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>I see the data inside the bundle as not visible to=
 the DTN=20
network.&nbsp; Who&nbsp;created the bundle and&nbsp; requesting use of&nbsp=
; my=20
resources is&nbsp;of interest to my bundle forwarding agent.&nbsp; I&nbsp;m=
ay be=20
willing to pass bundles created by Scott or coming from other people&nbsp;w=
ho=20
are associated in some way with Scott - Scott's&nbsp;friends.&nbsp; However=
, I=20
may not want to pass Kevin's bundles or bundles from people who associate w=
ith=20
Kevin.&nbsp; So, how do I determine who is associated with Scott and who is=
=20
associated with Kevin in a way the scales?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Hmmm - I'm at Google the next three days, maybe I =
should=20
post this problem on the wall in the morning and see if there is an answer =
later=20
in the day!&nbsp; :-)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D187210104-18032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>/will</FONT></SPAN></DIV></BODY></HTML>

--_000_3A5AA67A8B120B48825BFFCF54438561255FBA62F8NDJSSCC03ndcn_--

From: Peter Lovell <[email-masked]>
To: "William D. (GRC-RCN0) Ivancic" <[email-masked]>, dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 22:10:54 -0400
Subject: [dtn-interest] Re(2):  BSP update

Hi Will,

the expanded description of "key information" in section 2.7 is correct.
The brief summary
>But a little later is states
>"      - key information: key material encoded or protected by the key
>      management system, and used to transport an ephemeral key
>      protected by a long-term key.  This item is discussed further
>      below in Section 2.7"
... is older and should have been (will be) updated.

It used to be correct when we had a separate item for "key identifier",
and that's where the details such as certificate identifier were placed.
The problem was that  that approach created too much coupling between
the ciphersuite and the key management code. That is, the ciphersuite
had to know a lot of detail about how the key management system worked.
You can see the result of the changes in the "KeySteward" code in the
reference implementation, and I will credit the work done at LeHigh
(Mooi Choo Chuah and Ryan Metzger) for surfacing the issue.

So all the things related to how a long-term key is specified go into
"key information". Because there will be many ways to specify this I use
the CMS asn.1 approach. That has many advantages -- the identifiers are
already in RFCs, there's a body of code that does it, etc etc.

To provide at least one answer to your question about how to identify
keys, you can have an asn.1-encoded cert identifier in "key information"
to say which one to use. For a PIB (signature) this would probably be
all you need -- "this is the cert for the pubkey to use to verify the
signature". For PCB (encryption) you'd also specify a cert - the one
that was used to encrypt the data key. In addition, you have to include
that encrypted key in the "key information" item. They're asn.1-encoded
so you can get them apart and know what they are.

This approach allows for more extensive key management stuff than
required in the spec. Given the very-disconnected nature of dtn's (and
no key or SA negotiation) this seems appropriate. What it means is that,
at least in the reference implementation, the ciphersuites specify the
handling of the data but don't have to deal with key transport. For
example, PCB3 protects data using AES-GCM with 128-bit key. That's the
ciphersuite spec and AES-GCM-128 is  what it is. And the spec says that
the key is encrypted using RSA. Well, that's fine and conformant
implementations must accept such a key specification. But they can also
easily choose alternative key-transport schemes, but still with the PCB3
ciphersuite. In RI and similar implementations, the ciphersuite
specifies data handling and key handling. But while data handling is
fixed and constrained, key handling is flexible and extensible -- as
long as you implement support for the required key specification.

It may well be that certain systems have their own key systems and don't
use any of the typical key identifier schemes we have. The LeHigh system
was one such, and formed short-term user groups with symmetric KEKs. The
advantage of the "key information" item is that it allows this
unanticipated usage even within the standard ciphersuites.

I'm sure we'll discuss this more at the meeting.

Cheers.....Peter

On Tue, Mar 17, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>Peter,
>
>After Figure 2, all the fields are explained except:
> ciphersuite params data, security result data.  That information is
>presented elsewhere in portions of the specification such as in 2.4
>"..If neither the
>   destination nor security-destination resolves the key to use for
>   decryption, the ciphersuite parameters field can be used to indicate
>   the decryption key with which the BEK can be recovered."
>
>I am sort of confused as to what piece of information I would/should use
>to identify the key or certificate to use to decrypt the bundle or the
>Bundle Encryption Key.  If the source EID is not unique is it the
>Security Parameter.  However later the security parameter in 2.6 says
>
>"  Item types are
>      0: reserved
>      1: initialization vector (IV)
>      2: reserved
>      3: key information"
>
>But a little later is states
>"      - key information: key material encoded or protected by the key
>      management system, and used to transport an ephemeral key
>      protected by a long-term key.  This item is discussed further
>      below in Section 2.7"
>
>Which to me implies the key information is "key material encoded or
>protected by the key
>      management system" and thus not something that can be used to
>identify the core certificate.
>
>
>/Will
>
>
>
>******************************
>William D. Ivancic
>Phone 216-433-3494
>Fax 216-433-8705
>Networking Lab 216-433-2620
>DTN Lab 216-433-2981
>Mobile 440-503-4892
>http://roland.grc.nasa.gov/~ivancic
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On
>> Behalf Of Peter Lovell
>> Sent: Tuesday, March 17, 2009 5:02 PM
>> To: dtn interest
>> Subject: Re: [dtn-interest] BSP update
>>
>> Hi all,
>>
>> here's an updated BSP spec that we can review in Mountain
>> View. The spec submission is closed so it's not on RFC site
>> yet but will be when it reopens.
>>
>> The changes are small, dealing mainly with Stephen's comments.
>>
>> Cheers.....Peter
>>
>> p.s. this is the same one I had circulated to a few people on Sunday.
>> There being no specific issues I'm sending to everyone
>>

From: Peter Lovell <[email-masked]>
To: "Adrian J. Hooke" <[email-masked]>, Elwyn Davies <[email-masked]>
Date: Tue, 17 Mar 2009 21:37:04 -0400
Cc: dtn interest <[email-masked]>, "Denise Reed <[email-masked]>.  Carla LaFever" <[email-masked]>
Subject: [dtn-interest] Re(2):  March 19-20 Logistics/Agenda

On Thu, Mar 12, 2009, Adrian J. Hooke <[email-masked]> wrote:

>We have a private NASA meeting in the same room on Tuesday and
>Wednesday and I had asked for it to be set up with a teleconference
>set, laptop projector, screen ...

Hi Adrian,

you're not shooting another Andrew-Thomas-style NASA movie, are you??
[ROFL]

Cheers.....Peter

From: Kevin Fall <[email-masked]>
To: DTN interest <[email-masked]>
Date: Tue, 17 Mar 2009 17:58:55 -0700
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-metadata-block

--Apple-Mail-20--814786145
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

> From: Kevin Fall
> Date: March 17, 2009 5:44:46 PM PDT
> To: Hans Kruse <[email-masked]>
> Cc: "Symington, Susan F." <[email-masked]>, DTN <[email-masked] 
> >
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg- 
> bundle-metadata-block
>
> Right.  Couldn't we just have a "blah blah ontology" descriptor  
> block?  The idea of blocks themselves being extensible in somewhat  
> arbitrary ways seems troubling to me.  Certainly it would be  
> possible to reserve some # of block numbers..
>
> - K
>
>
> On Mar 5, 2009, at Mar 512:39 PMPST, Hans Kruse wrote:
>
>> I am not sure I am entirely comfortable with that.   Even if they  
>> are not "publicly available", couldn't collisions still occur?  You  
>> use a number for an ontology, but your router also forwards bundles  
>> for another project.  If they start using the same number for their  
>> (different) meta-data blocks, there will be a problem.
>>
>> How about specifying that a specific range of numbers requires IANA  
>> registration (or one could specify a range that does NOT require  
>> registration; depends on which case might be more common).   That  
>> would provide protection for implementations that need to work in  
>> an environment where bundles from different projects can get mixed.
>>
>> On Mar 5, 2009, at 3:00 PM, Symington, Susan F. wrote:
>>
>>>> #2 Should ontologies be managed by IANA? If so, should the
>>>> rule be specification required? It says "...providing the
>>>> content and format have been defined and documented as
>>>> part of an ontology" which'd imply a spec (or is there
>>>> an ontology-police somewhere else? :-)
>>>>
>>> No, I don't believe that these ontologies should be managed by  
>>> IANA. Many, as I stated, will not ever be made publicly available,  
>>> so such registration should not be a requirement. Certainly folks  
>>> could register their ontologies with IANA if desired, but it  
>>> shouldn't be required.
>>
>> Hans Kruse, Professor
>> J. Warren McClure School of Information and Telecommunication Systems
>> Adjunct Associate Professor of Electrical Engineering and Computer  
>> Science
>> 292 Lindley Hall, Ohio University, Athens, OH, 45701
>> 740-593-4891 voice, 740-593-4889 fax
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--Apple-Mail-20--814786145
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">Kevin Fall&nbsp;</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"5" color=3D"#000000" style=3D"font: 18.0px =
Helvetica; color: #000000"><b>Date: </b></font><font face=3D"Helvetica" =
size=3D"5" style=3D"font: 18.0px Helvetica">March 17, 2009 5:44:46 PM =
PDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica">Hans Kruse &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>Cc: </b></font><font =
face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">"Symington, Susan F." &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>>, DTN &lt;<a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a>></font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica"><b>Re: [dtn-interest] RG "last call" on =
draft-irtf-dtnrg-bundle-metadata-block</b></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div> </div><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Right. &nbsp;Couldn't we just =
have a "blah blah ontology" descriptor block? &nbsp;The idea of blocks =
themselves being extensible in somewhat arbitrary ways seems troubling =
to me. &nbsp;Certainly it would be possible to reserve some # of block =
numbers..<div><br></div><div>- =
K</div><div><br></div><div><br><div><div>On Mar 5, 2009, at Mar 512:39 =
PMPST, Hans Kruse wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I am not sure I am entirely =
comfortable with that. &nbsp; Even if they are not "publicly available", =
couldn't collisions still occur? &nbsp;You use a number for an ontology, =
but your router also forwards bundles for another project. &nbsp;If they =
start using the same number for their (different) meta-data blocks, =
there will be a problem.<div><br></div><div>How about specifying that a =
specific range of numbers requires IANA registration (or one could =
specify a range that does NOT require registration; depends on which =
case might be more common). &nbsp; That would provide protection for =
implementations that need to work in an environment where bundles from =
different projects can get mixed.</div><div><br><div><div>On Mar 5, =
2009, at 3:00 PM, Symington, Susan F. wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><blockquote type=3D"cite">#2 =
Should ontologies be managed by IANA? If so, should =
the<br></blockquote><blockquote type=3D"cite">rule be specification =
required? It says "...providing the<br></blockquote><blockquote =
type=3D"cite">content and format have been defined and documented =
as<br></blockquote><blockquote type=3D"cite">part of an ontology" =
which'd imply a spec (or is there<br></blockquote><blockquote =
type=3D"cite">an ontology-police somewhere else? =
:-)<br></blockquote><blockquote type=3D"cite"><br></blockquote>No, I =
don't believe that these ontologies should be managed by IANA. Many, as =
I stated, will not ever be made publicly available, so such registration =
should not be a requirement. Certainly folks could register their =
ontologies with IANA if desired, but it shouldn't be =
required.<br></span></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Hans =
Kruse, Professor</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren =
McClure School of Information and Telecommunication =
Systems</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Adjunct Associate Professor =
of Electrical Engineering and Computer Science</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">740-593-4891 voice, =
740-593-4889 fax</font></div></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></div>_______________________________________________<br>d=
tn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote></div><br></div></div></blockquote></div><br></body></html>=

--Apple-Mail-20--814786145--

From: Kevin Fall <[email-masked]>
To: DTN interest <[email-masked]>
Date: Tue, 17 Mar 2009 17:57:48 -0700
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

--Apple-Mail-19--814852657
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

> From: Kevin Fall
> Date: March 17, 2009 5:34:45 PM PDT
> To: Susan Symington <[email-masked]>
> Cc: DTN <[email-masked]>
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg- 
> bundle-previous-hop-block
>
> related to several of these issues, I'm not so sure why this is  
> extensible.  If you want a previous hop EID, then we can have a  
> block for that and if you want a timestamp (or two, etc), then that  
> could be a different block.  [it might be curious if you had w/out  
> the other, though as it brings up just who put the timestamp in  
> there, but one could imagine a possible use case for that].
>
> - K
>
>
> On Mar 4, 2009, at Mar 42:24 AMPST, Stephen Farrell wrote:
>
>>
>> I have a few issues with this one that I think might warrant
>> discussion (attached).
>>
>> Sorry if these've come up before and I wasn't paying attention.
>>
>> Stephen.
>>
>> SF comments on draft-irtf-dtnrg-bundle-previous-hop-block-05
>>
>> 20090304
>>
>> #1 IANA stuff.  Given that we'll probably want a block type  
>> registry, why make
>> this one exensible as well? I think I'd prefer that we not make  
>> this extensible
>> even though there're only 8 bits for block types. I guess I'm  
>> wondering why all
>> values added for single-hop purposes should use this block type,  
>> which seems to
>> be implied by the current scheme.
>>
>> #2 If a bundle with this is sent to a node that doesn't implement  
>> this block
>> then it'll delete the block before forwarding. However, the  
>> dictionary in that
>> forwarded bundle will still contain any EIDs inserted for this  
>> block, thus
>> breaking e2e integrity. Wouldn't it be better for this block to not  
>> use the
>> dictionary to avoid this problem?
>>
>> #3 The timestamp seems ambiguous - is it the time at which the  
>> bundle departs
>> the forwarder? Why not allow adding the time of arrival as well?
>>
>> #4 Is there really a use-case for the EID-only version of this? If  
>> not, or if
>> its a corner case, then changing this to make the timestamp (or  
>> two, see #2)
>> mandatory would be simpler.
>>
>> #5 The timestamp has a 1second granularity, but in the BP we have a  
>> sequence
>> value as well to distinguish bundles sent in the same second.  
>> Suggest copying
>> that here too or (maybe better) having a timstamp that allows  
>> microseconds as
>> well.
>>
>> #6 Given the 1s granularity and that the timestamp is an offset  
>> from the bundle
>> creation time, the text should give guidance on rounding up or down.
>>
>> #7 Making the timestamp an offset means that if we define a way for
>> timeless-nodes to use the BP (e.g. with a "special" time value and  
>> some other
>> block/flag) then this offset scheme might be affected. If this  
>> timestamp were
>> the wall-clock time of the forwarder then the dependency wouldn't  
>> arise.
>>
>> #8 What if the forwarder has no clock?
>>
>> #9 Why would a bundle ever have >1 of these blocks? (As is allowed  
>> by 3.1)
>>
>> #10 Security considerations: what if the forwarder lies about its  
>> EID or the
>> time? This block could provide a nice way to subvert routing  
>> strategies, e.g.
>> to create a DoS against the EID named as the forwarder, if the  
>> receiver uses
>> that to decide to route bundles via that EID. There may be other  
>> security
>> issues as well but I think receivers should be warned to think  
>> about this.
>>
>> #11 Security considerations: "If encryption of this block is  
>> desired..."
>> Another alternative would be to encapsulate which is probably worth  
>> a mention.
>>
>> #12 If a BP implementation doesn't properly implement the "Discard  
>> block if it
>> can't be processed" then this block will persist unexpectedly.   
>> Dunno if that's
>> a risk worth a mention in the sec. cons. section or not?  (If there  
>> are BP
>> implementations out there that don't do block discarding right, or  
>> at all, then
>> I suspect it should be mentioned.)
>>
>> Nits:
>>
>> #1 Intro says that the two formats are "mandatory" which is odd -  
>> presumably
>> that's mandatory-to-implement (if supporting this spec)?
>>
>> #2 I think the text could be shortened, its a bit wordy.
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--Apple-Mail-19--814852657
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><br><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">Kevin Fall&nbsp;</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"5" color=3D"#000000" style=3D"font: 18.0px =
Helvetica; color: #000000"><b>Date: </b></font><font face=3D"Helvetica" =
size=3D"5" style=3D"font: 18.0px Helvetica">March 17, 2009 5:34:45 PM =
PDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica">Susan Symington &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>Cc: </b></font><font =
face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px Helvetica">DTN =
&lt;<a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a>></font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica"><b>Re: [dtn-interest] RG "last call" on =
draft-irtf-dtnrg-bundle-previous-hop-block</b></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div> </div><div>related to =
several of these issues, I'm not so sure why this is extensible. =
&nbsp;If you want a previous hop EID, then we can have a block for that =
and if you want a timestamp (or two, etc), then that could be a =
different block. &nbsp;[it might be curious if you had w/out the other, =
though as it brings up just who put the timestamp in there, but one =
could imagine a possible use case for that].<br><br>- K<br><br><br>On =
Mar 4, 2009, at Mar 42:24 AMPST, Stephen Farrell =
wrote:<br><br><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">I have a few issues with this one that I think might =
warrant<br></blockquote><blockquote type=3D"cite">discussion =
(attached).<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Sorry if =
these've come up before and I wasn't paying =
attention.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Stephen.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">SF comments on =
draft-irtf-dtnrg-bundle-previous-hop-block-05<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">20090304<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#1 IANA stuff. =
&nbsp;Given that we'll probably want a block type registry, why =
make<br></blockquote><blockquote type=3D"cite">this one exensible as =
well? I think I'd prefer that we not make this =
extensible<br></blockquote><blockquote type=3D"cite">even though =
there're only 8 bits for block types. I guess I'm wondering why =
all<br></blockquote><blockquote type=3D"cite">values added for =
single-hop purposes should use this block type, which seems =
to<br></blockquote><blockquote type=3D"cite">be implied by the current =
scheme.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#2 If a bundle =
with this is sent to a node that doesn't implement this =
block<br></blockquote><blockquote type=3D"cite">then it'll delete the =
block before forwarding. However, the dictionary in =
that<br></blockquote><blockquote type=3D"cite">forwarded bundle will =
still contain any EIDs inserted for this block, =
thus<br></blockquote><blockquote type=3D"cite">breaking e2e integrity. =
Wouldn't it be better for this block to not use =
the<br></blockquote><blockquote type=3D"cite">dictionary to avoid this =
problem?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#3 The =
timestamp seems ambiguous - is it the time at which the bundle =
departs<br></blockquote><blockquote type=3D"cite">the forwarder? Why not =
allow adding the time of arrival as well?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#4 Is there =
really a use-case for the EID-only version of this? If not, or =
if<br></blockquote><blockquote type=3D"cite">its a corner case, then =
changing this to make the timestamp (or two, see =
#2)<br></blockquote><blockquote type=3D"cite">mandatory would be =
simpler.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#5 The =
timestamp has a 1second granularity, but in the BP we have a =
sequence<br></blockquote><blockquote type=3D"cite">value as well to =
distinguish bundles sent in the same second. Suggest =
copying<br></blockquote><blockquote type=3D"cite">that here too or =
(maybe better) having a timstamp that allows microseconds =
as<br></blockquote><blockquote =
type=3D"cite">well.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#6 Given the 1s =
granularity and that the timestamp is an offset from the =
bundle<br></blockquote><blockquote type=3D"cite">creation time, the text =
should give guidance on rounding up or down.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#7 Making the =
timestamp an offset means that if we define a way =
for<br></blockquote><blockquote type=3D"cite">timeless-nodes to use the =
BP (e.g. with a "special" time value and some =
other<br></blockquote><blockquote type=3D"cite">block/flag) then this =
offset scheme might be affected. If this timestamp =
were<br></blockquote><blockquote type=3D"cite">the wall-clock time of =
the forwarder then the dependency wouldn't =
arise.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#8 What if the =
forwarder has no clock?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#9 Why would a =
bundle ever have >1 of these blocks? (As is allowed by =
3.1)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#10 Security =
considerations: what if the forwarder lies about its EID or =
the<br></blockquote><blockquote type=3D"cite">time? This block could =
provide a nice way to subvert routing strategies, =
e.g.<br></blockquote><blockquote type=3D"cite">to create a DoS against =
the EID named as the forwarder, if the receiver =
uses<br></blockquote><blockquote type=3D"cite">that to decide to route =
bundles via that EID. There may be other =
security<br></blockquote><blockquote type=3D"cite">issues as well but I =
think receivers should be warned to think about =
this.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#11 Security =
considerations: "If encryption of this block is =
desired..."<br></blockquote><blockquote type=3D"cite">Another =
alternative would be to encapsulate which is probably worth a =
mention.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#12 If a BP =
implementation doesn't properly implement the "Discard block if =
it<br></blockquote><blockquote type=3D"cite">can't be processed" then =
this block will persist unexpectedly. &nbsp;Dunno if =
that's<br></blockquote><blockquote type=3D"cite">a risk worth a mention =
in the sec. cons. section or not? &nbsp;(If there are =
BP<br></blockquote><blockquote type=3D"cite">implementations out there =
that don't do block discarding right, or at all, =
then<br></blockquote><blockquote type=3D"cite">I suspect it should be =
mentioned.)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Nits:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#1 Intro says =
that the two formats are "mandatory" which is odd - =
presumably<br></blockquote><blockquote type=3D"cite">that's =
mandatory-to-implement (if supporting this =
spec)?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">#2 I think the =
text could be shortened, its a bit wordy.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><br></div></blockquote></div><br></body></html>=

--Apple-Mail-19--814852657--

From: Kevin Fall <[email-masked]>
To: DTN interest <[email-masked]>
Date: Tue, 17 Mar 2009 17:57:02 -0700
Subject: Re: [dtn-interest] Naming and Addressing

--Apple-Mail-18--814898468
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

>
>> From: Kevin Fall
>> Date: March 17, 2009 12:14:35 PM PDT
>> To: Elwyn Davies <[email-masked]>
>> Cc: "Burleigh, Scott C" <[email-masked]>, dtn  
>> interest <[email-masked]>
>> Subject: Re: [dtn-interest] Naming and Addressing
>>
>> some comments inline.  I expect to be giving a short presentation  
>> at the upcoming Google meeting that makes more concrete some of the  
>> things I mentioned in Germany (i.e., about naming structures and  
>> URI/scheme use).
>>
>> - K
>>
>>
>> On Mar 17, 2009, at Mar 174:11 AMPDT, Elwyn Davies wrote:
>>
>>> Burleigh, Scott C wrote:
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:dtn-
>>>>> [email-masked]] On Behalf Of  
>>>>> Ivancic,
>>>>> William D. (GRC-RHN0)
>>>>> Sent: Monday, March 16, 2009 9:27 PM
>>>>> To: dtn interest
>>>>> Subject: [dtn-interest] Naming and Addressing
>>>>>
>>>>> Naming and addressing is one of the points of technical  
>>>>> discussion for the
>>>>> DTNRG meetings March 19 and 20.  I thought I could get some  
>>>>> discussion
>>>>> started here.
>>>>>
>>>>> This discussion started on a NASA internal list, but we can  
>>>>> bound the
>>>>> problem there as Space is, in many ways, much simpler due to the  
>>>>> size of
>>>>> the network and the predictability of the network (at least for  
>>>>> a space-
>>>>> base backbone).
>>>>>
>>>>> The current DTN Bundling Architecture (not the bundling  
>>>>> framework, rather
>>>>> the architecture) really does not have a common lower layer  
>>>>> address space.
>>>>> At least that is the way it looks to me.  The bundle agent  
>>>>> connects
>>>>> directly to convergence layers with no DTN addressing scheme.
>>>>>
>>>>
>>>> I would say you are right, Will: the DTN architecture doesn't  
>>>> have any notion of addresses that I am aware of.  Routing of a  
>>>> bundle is done on the basis of the *name* of its destination, not  
>>>> the address (which may well not be known to the sender or any  
>>>> relay point, because the destination node may be locally  
>>>> mobile).  "Late binding" in DTN is, essentially, the resolution  
>>>> of name to address at the last possible moment, in recognition of  
>>>> the significant chance that this resolution will change over the  
>>>> course of the bundle's progress from its source to its  
>>>> destination..
>>>>
>>> One way of expressing this is that the DTN name doesn't define the  
>>> path
>>> in advance.
>>
>>
>> Right, there isn't really a DTN addressing scheme per-se.  That is  
>> by design.  In particular, there is the URI idea with where  
>> different name spaces can be represented.  You can represent any  
>> addressing scheme you choose to use using that construct.  Also,  
>> you can map between them, which is a point I will be interested in  
>> discussing thu/fri.  Note that even in Internet we move between  
>> multiples name and address spaces (e.g., DNS, mail names, and  
>> sometimes IP addresses if we have reason to believe DNS isn't  
>> working).  This type of flexibility is necessary for DTN as well,  
>> so I believe "there can be only one" is absolutely not the right  
>> thing.  Late binding is an option that I think matches well to high- 
>> delay networks.  However, there are some cases where early binding  
>> and possibly source-routing is needed, and the naming/addressing  
>> architecture should be able to handle it too.
>>
>>>
>>>
>>> Because of the overloading of IP addresses as both identifier and
>>> locator, the choice of addresses at the source in IP effectively  
>>> binds
>>> the packet to a path through the IP network before the packet sets  
>>> off.
>>> One can quibble about the details (like load spreading across  
>>> multiple
>>> paths in the core, backup paths coming into play, rerouting) but  
>>> for the
>>> vast majority of packets the routing fate of the packet is known  
>>> at the
>>> time of  despatch. Originally just the destination address mattered.
>>> Now the source and possibly some QoS bits may come into play but  
>>> this
>>> doesn't really change the situation. In IP the per-packet routing
>>> 'decision' at each router is not really a decision at all but a  
>>> lookup.
>>
>> Generally true.  The exception being some of the on-demand ad-hoc  
>> type protocols.
>>
>>>
>>> The decision has been made previously by the control plane routing
>>> protocol and the packet is tied to that path.  [Aside: The IP  
>>> world has
>>> come to be wedded to the path predestination 'principle' (dogma?).
>>> Multipath routing is being considered in the research community  
>>> but is
>>> not mainstream.  Most, if not all, of the proposed fixes for the
>>> multihoming problem and providing an id/locator split still cling  
>>> to the
>>> predestined path, although it may be a bit disguised.]
>>
>> Right, and so most of these discussions tend to involve some sort  
>> of distributed mapping system that takes either "names" or  
>> "addresses" and converts them into some other form of address.   
>> (see LISP from RRG as an example).  In my opinion it only sort of  
>> helps the major problems facing the Internet, at the cost of  
>> introducing some others.  {e.g., try reading the DNSSEC documents  
>> then imagine securing yet another lookup scheme; although its  
>> possibly we won't have it much easier}.
>>
>>>
>>>
>>> In DTN, particularly with the more opportunist encounter type of
>>> network, there is a real decision to be made and this can be  
>>> influenced
>>> by aspects of the bundle, although I think that apart from size and
>>> possibly custody requirements this hasn't had much effect as yet.
>>
>> There is another important couple of decisions:  what protocol to  
>> use and whether to copy of forward the bundle.
>> [not to mention any security issues].
>>
>>>
>>>>
>>>>> To me, it
>>>>> would be desirable to have some type of topological and  
>>>>> hierarchical
>>>>> addressing scheme to aid in routing and security (something  
>>>>> similar to IP-
>>>>> tables).
>>>>>
>>>>
>>>> That would clearly be one, very familiar way to support routing  
>>>> and security, but in my understanding of DTN it would not be the  
>>>> DTN way.
>>>>
>>> IMO it would be highly undesirable to take us down the path of a  
>>> totally
>>> hierarchical system.  Although it looks promising as a scaling
>>> mechanism, the existing IP routing system shows that you have to  
>>> be very
>>> careful about what happens when it gets very big.  Also the notion  
>>> of a
>>> single authority that tends to be the follow on to a hierarchy  
>>> doesn't
>>> chime well with DTN.
>>
>> agree.  Much of the current Internet problems are a consequence of  
>> the hierarchy forced upon us by CIDR. Granted, CIDR was arguably  
>> necessary at the time it was deployed, but things like provider  
>> independence, multihoming, and mobility are made much much harder  
>> by it.
>>>
>>>>
>>>>> However, because there is no common addressing scheme, a
>>>>> multitude of DTN bundle agents looks like a flat network because  
>>>>> I think
>>>>> what we really have is  application-layer store and forward  
>>>>> gateways that
>>>>> can be graphically connected.  So in the strictest definition of  
>>>>> a network
>>>>> being related to graph theory, you sort of have a network.  But  
>>>>> when one
>>>>> looks at what one would expect from a network (things like a  
>>>>> common
>>>>> addressing scheme), it is not currently present.
>>
>> I suggested above why a (loosened) definition of Internet doesn't  
>> support a single common addressing scheme.
>>
>>>>>
>>>>>
>>>>
>>>> Right, the network is different from IP in that routing is done  
>>>> on the basis of name, as far as possible, rather than on the  
>>>> basis of address.  This is one of the significant ways in which  
>>>> DTN differs from IP.
>>>>
>>>>
>>>>> Wes Eddy pointed out the following:
>>>>>
>>>>> "The typical approach is to enable the split by setting up 2 sub- 
>>>>> layers,
>>>>> one with locators below and one with identifiers above.  In DTN,  
>>>>> we have a
>>>>> different approach.  An EID could be either a locator or an  
>>>>> identifier
>>>>> depending on how the EID scheme and forwarding on it are  
>>>>> defined.  Inside a
>>>>> bundle agent though, EIDs and next-hops have to map to  
>>>>> convergence layer
>>>>> addresses, which may or may not be locators themselves, but are  
>>>>> definitely
>>>>> the locators from a bundle agent's point-of-view as they  
>>>>> basically specify
>>>>> network coordinates at some specific time.
>>
>> agree with the gist of this but not sure I'd agree they are  
>> 'definitely the locators'.  But
>> I don't think its very important to argue it either.
>>
>>>>>
>>>>>
>>>>> So ... I'd say that an EID *can* be an address, though you don't  
>>>>> often want
>>>>> it to be one, but a set of convergence layer parameters is the  
>>>>> real address
>>>>> in the DTN architecture."
>>>>>
>>>>
>>>> Right, there are no addresses in use at what serves as the  
>>>> "network protocol" within DTN (the Bundle Protocol), but there  
>>>> are addresses in use within the underlying convergence-layer  
>>>> protocols.  These are the addresses that are computed by "late  
>>>> binding".
>>
>> there are no mandated addresses.
>>
>>>>
>>>>
>>> And they are really only of point-to-point significance in one
>>> forwarding hop.  On a multihop path, the convergence layer  
>>> parameters
>>> (essentially a token to send a bundle along a particular active  
>>> link)
>>> are a local mapping at each node that are not relevant once the  
>>> bundle
>>> has moved to the next node.
>>
>> I wouldn't say point to point exactly, as we might well have a  
>> bcast or mcast distribution model, but
>> yes there is some truth to this point.
>>
>>>
>>>>
>>>>> ---> Back to my thoughts <---
>>>>>
>>>>> I believe BBN is looking at running DTN as the network directly  
>>>>> over a
>>>>> meshed wireless ad hoc network.  Thus DTN is the upper layer  
>>>>> network.
>>>>> There is not IP network.  In this case, I believe they are using  
>>>>> the radio
>>>>> MAC and the Endpoint Identifier and realize this does not  
>>>>> scale.  Also I am
>>>>> not sure if this is a multi-radio system with one MAC address or  
>>>>> something
>>>>> else.  But it has been proven that naming the end system by the  
>>>>> interface
>>>>> is bad for multihoming.
>>>>>
>>>>
>>>> If I understand you right, Will, I agree.  I think the way you  
>>>> get multihoming in DTN is by having multiple convergence-layer  
>>>> service access points (for, most likely, multiple convergence- 
>>>> layer protocols) at a single node.
>>>>
>>> I think there is some confusion here (as there often is in IP
>>> discussions of multihoming) between the logical multihoming  
>>> (typically a
>>> service agreement between the end network and a service provider)   
>>> and
>>> physical multihoming (having multiple independent network interfaces
>>> available simultaneously).  In DTN networks a node may have multiple
>>> physical interfaces (quite possibly using different  convergence- 
>>> layer
>>> protocols) but it can also have multiple logical links over a single
>>> convergence layer (e.g., simultaneous ad hoc Wi-Fi connections).    
>>> And
>>> there is the additional dimension that these links (unlike the  
>>> usual IP
>>> case) are not necessarily simultaneously active/available.  So,  
>>> yes it
>>> is probably not generally clever to identify a node with a single
>>> interface, but that doesn't necessarily prevent it being  
>>> multihomed if
>>> the single interface is a wireless interface that can support  
>>> multiple
>>> ad hoc connections at once.
>>>
>>> In most of the IP multihoming discussions we are talking about a  
>>> hard
>>> wired mapping between the administrative connections of a logically
>>> multihomed node and the physical connections. IP early binding then
>>> ought to tie a packet with given addresses to a path through one or
>>> other of the links.  For a large proportion of DTN networks these
>>> concepts are irrelevant, although gateways will generally have  
>>> different
>>> associations on either side.
>>>>
>>>>> I think we should address multi-homing and mobility at the  
>>>>> onset.  Late-
>>>>> binding might help us here.  Ignoring the problem in the past  
>>>>> has resulted
>>>>> in poor band-aid approaches to trying to get something to work  
>>>>> later.
>>>>>
>>>>
>>>> I agree that we should take multi-homing and mobility into  
>>>> account right from the beginning.
>>>>
>>
>> that was largely the motivation to get rid of "regions" as a  
>> mandated concept
>>
>>> Absolutely.  Dealing (as I do) with 'data mule' type networks many  
>>> of
>>> the nodes are mobile, but early thinking only made them physically
>>> mobile, keeping them essentially within one 'association'  (we  
>>> aren't
>>> allowed to call it a region  but  for the purposes of understanding
>>> history, we were originally talking about nodes only encountering  
>>> nodes
>>> that live in a common area and have some common purpose making it  
>>> useful
>>> for them to talk to one another). We now have to allow at least some
>>> nodes to be very mobile, associating with several other groups of  
>>> DTN
>>> nodes and occasionally migrating back into the (legacy) Internet.
>>>
>>> I think the notion of association is a useful structuring  
>>> mechanism, but
>>> nodes need to be allowed to be members of multiple associations.
>>> Associations could be recursive, but I don't want to go down the  
>>> path of
>>> a single hierarchy.
>>>
>>>
>>>>
>>>>> Perhaps the bundle agent identity does not have to be a URI, but  
>>>>> some
>>>>> unique identifier that can be bound to various URI's (aliased).   
>>>>> This might
>>>>> help security.
>>>>>
>>>>
>>>> In ION we address this by drawing a firm distinction between DTN  
>>>> endpoints and underlying convergence-layer protocol "ducts", with  
>>>> a managed mapping between the two.  The former are necessarily  
>>>> URIs, but the latter are not.
>>
>> I think in most cases you don't care about the identity of a node.   
>> You care about the authorship of data.
>>
>>>>
>>>>
>>>>
>>>>> If we don't have a heretical addressing structure, perhaps we  
>>>>> can develop a
>>>>> hierarchical naming structure.
>>>>>
>>>>
>>>> I think there are good reasons for not doing that in all cases,  
>>>> though.  Hierarchies are convenient, but they also tend to be  
>>>> inflexible and difficult to revise.
>>>>
>>>>
>>> +1
>>
>> I think hierarchical naming, independent of topology, is likely a  
>> reasonable thing.  There may be multiple hierarchical name spaces,  
>> however.
>>
>>>
>>>>> Without some form or hierarchy, will DTNs be simple edge network  
>>>>> gateways
>>>>> do to an inability to scale the network?
>>>>>
>>>>
>>>> I don't think so.  In some ways I think a flat namespace is  
>>>> actually more robust than a hierarchical address space.
>>>>
>>
>> There is a very fundamental question here, and its not only a DTN  
>> question.  Can a non-hierarchical addressing scheme be made to  
>> work.  I have been doing some work with compact routing (see CCR  
>> paper on this for a sort of summary).  The short answer is 'it  
>> seems so', but the longer answer is that when there is too much  
>> dynamics in the network it can be difficult.  I think it is  
>> probably among the most important networking research questions to  
>> answer at this point.
>>
>>
>> - K
>>
>>
>

--Apple-Mail-18--814898468
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><br><blockquote =
type=3D"cite"><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space; "><div><div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">Kevin Fall&nbsp;</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"5" color=3D"#000000" style=3D"font: 18.0px =
Helvetica; color: #000000"><b>Date: </b></font><font face=3D"Helvetica" =
size=3D"5" style=3D"font: 18.0px Helvetica">March 17, 2009 12:14:35 PM =
PDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica">Elwyn Davies &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></font></div><=
div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>Cc: </b></font><font =
face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">"Burleigh, Scott C" &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]=
v</a>>, dtn interest &lt;<a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a>></font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica"><b>Re: [dtn-interest] Naming and =
Addressing</b></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><br></div> </div><div>some comments inline. &nbsp;I expect to be =
giving a short presentation at the upcoming Google meeting that makes =
more concrete some of the things I mentioned in Germany (i.e., about =
naming structures and URI/scheme use).<br><br>- K<br><br><br>On Mar 17, =
2009, at Mar 174:11 AMPDT, Elwyn Davies wrote:<br><br><blockquote =
type=3D"cite">Burleigh, Scott C wrote:<br></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">-----Original =
Message-----<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">From: =
<a =
href=3D"mailto:[email-masked]">dtn-inte=
[email-masked]</a> [<a =
href=3D"mailto:dtn-">mailto:dtn-</a><br></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"mailto:[email-masked]">interest-bou=
[email-masked]</a>] On Behalf Of =
Ivancic,<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">William =
D. (GRC-RHN0)<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Sent: =
Monday, March 16, 2009 9:27 =
PM<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To: =
dtn interest<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Subject:=
 [dtn-interest] Naming and =
Addressing<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Naming =
and addressing is one of the points of technical discussion for =
the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">DTNRG =
meetings March 19 and 20. &nbsp;I thought I could get some =
discussion<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">started =
here.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">This =
discussion started on a NASA internal list, but we can bound =
the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">problem =
there as Space is, in many ways, much simpler due to the size =
of<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">the =
network and the predictability of the network (at least for a =
space-<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">base =
backbone).<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">The =
current DTN Bundling Architecture (not the bundling framework, =
rather<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">the =
architecture) really does not have a common lower layer address =
space.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">At =
least that is the way it looks to me. &nbsp;The bundle agent =
connects<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">directly=
 to convergence layers with no DTN addressing =
scheme.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I would say you are right, Will: =
the DTN architecture doesn't have any notion of addresses that I am =
aware of. &nbsp;Routing of a bundle is done on the basis of the *name* =
of its destination, not the address (which may well not be known to the =
sender or any relay point, because the destination node may be locally =
mobile). &nbsp;"Late binding" in DTN is, essentially, the resolution of =
name to address at the last possible moment, in recognition of the =
significant chance that this resolution will change over the course of =
the bundle's progress from its source to its =
destination..<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote type=3D"cite">One =
way of expressing this is that the DTN name doesn't define the =
path<br></blockquote><blockquote type=3D"cite">in =
advance.<br></blockquote><br><br>Right, there isn't really a DTN =
addressing scheme per-se. &nbsp;That is by design. &nbsp;In particular, =
there is the URI idea with where different name spaces can be =
represented. &nbsp;You can represent any addressing scheme you choose to =
use using that construct. &nbsp;Also, you can map between them, which is =
a point I will be interested in discussing thu/fri. &nbsp;Note that even =
in Internet we move between multiples name and address spaces (e.g., =
DNS, mail names, and sometimes IP addresses if we have reason to believe =
DNS isn't working). &nbsp;This type of flexibility is necessary for DTN =
as well, so I believe "there can be only one" is absolutely not the =
right thing. &nbsp;Late binding is an option that I think matches well =
to high-delay networks. &nbsp;However, there are some cases where early =
binding and possibly source-routing is needed, and the naming/addressing =
architecture should be able to handle it too.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Because of the =
overloading of IP addresses as both identifier =
and<br></blockquote><blockquote type=3D"cite">locator, the choice of =
addresses at the source in IP effectively =
binds<br></blockquote><blockquote type=3D"cite">the packet to a path =
through the IP network before the packet sets =
off.<br></blockquote><blockquote type=3D"cite">One can quibble about the =
details (like load spreading across multiple<br></blockquote><blockquote =
type=3D"cite">paths in the core, backup paths coming into play, =
rerouting) but for the<br></blockquote><blockquote type=3D"cite">vast =
majority of packets the routing fate of the packet is known at =
the<br></blockquote><blockquote type=3D"cite">time of &nbsp;despatch. =
Originally just the destination address =
mattered.<br></blockquote><blockquote type=3D"cite">Now the source and =
possibly some QoS bits may come into play but =
this<br></blockquote><blockquote type=3D"cite">doesn't really change the =
situation. In IP the per-packet routing<br></blockquote><blockquote =
type=3D"cite">'decision' at each router is not really a decision at all =
but a lookup.<br></blockquote><br>Generally true. &nbsp;The exception =
being some of the on-demand ad-hoc type protocols.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">The decision =
has been made previously by the control plane =
routing<br></blockquote><blockquote type=3D"cite">protocol and the =
packet is tied to that path. &nbsp;[Aside: The IP world =
has<br></blockquote><blockquote type=3D"cite">come to be wedded to the =
path predestination 'principle' (dogma?).<br></blockquote><blockquote =
type=3D"cite">Multipath routing is being considered in the research =
community but is<br></blockquote><blockquote type=3D"cite">not =
mainstream. &nbsp;Most, if not all, of the proposed fixes for =
the<br></blockquote><blockquote type=3D"cite">multihoming problem and =
providing an id/locator split still cling to =
the<br></blockquote><blockquote type=3D"cite">predestined path, although =
it may be a bit disguised.]<br></blockquote><br>Right, and so most of =
these discussions tend to involve some sort of distributed mapping =
system that takes either "names" or "addresses" and converts them into =
some other form of address. &nbsp;(see LISP from RRG as an example). =
&nbsp;In my opinion it only sort of helps the major problems facing the =
Internet, at the cost of introducing some others. &nbsp;{e.g., try =
reading the DNSSEC documents then imagine securing yet another lookup =
scheme; although its possibly we won't have it much =
easier}.<br><br><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">In DTN, =
particularly with the more opportunist encounter type =
of<br></blockquote><blockquote type=3D"cite">network, there is a real =
decision to be made and this can be =
influenced<br></blockquote><blockquote type=3D"cite">by aspects of the =
bundle, although I think that apart from size =
and<br></blockquote><blockquote type=3D"cite">possibly custody =
requirements this hasn't had much effect as =
yet.<br></blockquote><br>There is another important couple of decisions: =
&nbsp;what protocol to use and whether to copy of forward the =
bundle.<br>[not to mention any security issues].<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To me, =
it<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">would =
be desirable to have some type of topological and =
hierarchical<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">addressing scheme to aid in routing and security =
(something similar to =
IP-<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">tables).<br></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">That would clearly be one, very =
familiar way to support routing and security, but in my understanding of =
DTN it would not be the DTN =
way.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote type=3D"cite">IMO =
it would be highly undesirable to take us down the path of a =
totally<br></blockquote><blockquote type=3D"cite">hierarchical system. =
&nbsp;Although it looks promising as a =
scaling<br></blockquote><blockquote type=3D"cite">mechanism, the =
existing IP routing system shows that you have to be =
very<br></blockquote><blockquote type=3D"cite">careful about what =
happens when it gets very big. &nbsp;Also the notion of =
a<br></blockquote><blockquote type=3D"cite">single authority that tends =
to be the follow on to a hierarchy doesn't<br></blockquote><blockquote =
type=3D"cite">chime well with DTN.<br></blockquote><br>agree. &nbsp;Much =
of the current Internet problems are a consequence of the hierarchy =
forced upon us by CIDR. Granted, CIDR was arguably necessary at the time =
it was deployed, but things like provider independence, multihoming, and =
mobility are made much much harder by it.<br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">However,=
 because there is no common addressing scheme, =
a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">multitude of DTN bundle agents looks like a flat network =
because I think<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">what =
we really have is &nbsp;application-layer store and forward gateways =
that<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">can be =
graphically connected. &nbsp;So in the strictest definition of a =
network<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">being =
related to graph theory, you sort of have a network. &nbsp;But when =
one<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">looks =
at what one would expect from a network (things like a =
common<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">addressing scheme), it is not currently =
present.<br></blockquote></blockquote></blockquote><br>I suggested above =
why a (loosened) definition of Internet doesn't support a single common =
addressing scheme.<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Right, the network is different =
from IP in that routing is done on the basis of name, as far as =
possible, rather than on the basis of address. &nbsp;This is one of the =
significant ways in which DTN differs from =
IP.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Wes =
Eddy pointed out the =
following:<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">"The =
typical approach is to enable the split by setting up 2 =
sub-layers,<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">one =
with locators below and one with identifiers above. &nbsp;In DTN, we =
have a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">different approach. &nbsp;An EID could be either a locator =
or an identifier<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">depending on how the EID scheme and forwarding on it are =
defined. &nbsp;Inside =
a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">bundle =
agent though, EIDs and next-hops have to map to convergence =
layer<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">addresses, which may or may not be locators themselves, =
but are definitely<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">the =
locators from a bundle agent's point-of-view as they basically =
specify<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">network =
coordinates at some specific =
time.<br></blockquote></blockquote></blockquote><br>agree with the gist =
of this but not sure I'd agree they are 'definitely the locators'. =
&nbsp;But<br>I don't think its very important to argue it =
either.<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">So ... =
I'd say that an EID *can* be an address, though you don't often =
want<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">it to =
be one, but a set of convergence layer parameters is the real =
address<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">in the =
DTN architecture."<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Right, there are no addresses in =
use at what serves as the "network protocol" within DTN (the Bundle =
Protocol), but there are addresses in use within the underlying =
convergence-layer protocols. &nbsp;These are the addresses that are =
computed by "late binding".<br></blockquote></blockquote><br>there are =
no mandated addresses.<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote type=3D"cite">And =
they are really only of point-to-point significance in =
one<br></blockquote><blockquote type=3D"cite">forwarding hop. &nbsp;On a =
multihop path, the convergence layer =
parameters<br></blockquote><blockquote type=3D"cite">(essentially a =
token to send a bundle along a particular active =
link)<br></blockquote><blockquote type=3D"cite">are a local mapping at =
each node that are not relevant once the =
bundle<br></blockquote><blockquote type=3D"cite">has moved to the next =
node.<br></blockquote><br>I wouldn't say point to point exactly, as we =
might well have a bcast or mcast distribution model, but<br>yes there is =
some truth to this point.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">---> =
Back to my thoughts =
&lt;---<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">I =
believe BBN is looking at running DTN as the network directly over =
a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">meshed =
wireless ad hoc network. &nbsp;Thus DTN is the upper layer =
network.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">There =
is not IP network. &nbsp;In this case, I believe they are using the =
radio<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">MAC =
and the Endpoint Identifier and realize this does not scale. &nbsp;Also =
I am<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">not =
sure if this is a multi-radio system with one MAC address or =
something<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">else. =
&nbsp;But it has been proven that naming the end system by the =
interface<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">is bad =
for multihoming.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">If I understand you right, Will, =
I agree. &nbsp;I think the way you get multihoming in DTN is by having =
multiple convergence-layer service access points (for, most likely, =
multiple convergence-layer protocols) at a single =
node.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote type=3D"cite">I =
think there is some confusion here (as there often is in =
IP<br></blockquote><blockquote type=3D"cite">discussions of multihoming) =
between the logical multihoming (typically a<br></blockquote><blockquote =
type=3D"cite">service agreement between the end network and a service =
provider) &nbsp;and<br></blockquote><blockquote type=3D"cite">physical =
multihoming (having multiple independent network =
interfaces<br></blockquote><blockquote type=3D"cite">available =
simultaneously). &nbsp;In DTN networks a node may have =
multiple<br></blockquote><blockquote type=3D"cite">physical interfaces =
(quite possibly using different =
&nbsp;convergence-layer<br></blockquote><blockquote =
type=3D"cite">protocols) but it can also have multiple logical links =
over a single<br></blockquote><blockquote type=3D"cite">convergence =
layer (e.g., simultaneous ad hoc Wi-Fi connections). =
&nbsp;&nbsp;And<br></blockquote><blockquote type=3D"cite">there is the =
additional dimension that these links (unlike the usual =
IP<br></blockquote><blockquote type=3D"cite">case) are not necessarily =
simultaneously active/available. &nbsp;So, yes =
it<br></blockquote><blockquote type=3D"cite">is probably not generally =
clever to identify a node with a single<br></blockquote><blockquote =
type=3D"cite">interface, but that doesn't necessarily prevent it being =
multihomed if<br></blockquote><blockquote type=3D"cite">the single =
interface is a wireless interface that can support =
multiple<br></blockquote><blockquote type=3D"cite">ad hoc connections at =
once.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">In most of the =
IP multihoming discussions we are talking about a =
hard<br></blockquote><blockquote type=3D"cite">wired mapping between the =
administrative connections of a logically<br></blockquote><blockquote =
type=3D"cite">multihomed node and the physical connections. IP early =
binding then<br></blockquote><blockquote type=3D"cite">ought to tie a =
packet with given addresses to a path through one =
or<br></blockquote><blockquote type=3D"cite">other of the links. =
&nbsp;For a large proportion of DTN networks =
these<br></blockquote><blockquote type=3D"cite">concepts are irrelevant, =
although gateways will generally have =
different<br></blockquote><blockquote type=3D"cite">associations on =
either side.<br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">I =
think we should address multi-homing and mobility at the onset. =
&nbsp;Late-<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">binding =
might help us here. &nbsp;Ignoring the problem in the past has =
resulted<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">in =
poor band-aid approaches to trying to get something to work =
later.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I agree that we should take =
multi-homing and mobility into account right from the =
beginning.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><br>that was largely the =
motivation to get rid of "regions" as a mandated =
concept<br><br><blockquote type=3D"cite">Absolutely. &nbsp;Dealing (as I =
do) with 'data mule' type networks many of<br></blockquote><blockquote =
type=3D"cite">the nodes are mobile, but early thinking only made them =
physically<br></blockquote><blockquote type=3D"cite">mobile, keeping =
them essentially within one 'association' &nbsp;(we =
aren't<br></blockquote><blockquote type=3D"cite">allowed to call it a =
region &nbsp;but &nbsp;for the purposes of =
understanding<br></blockquote><blockquote type=3D"cite">history, we were =
originally talking about nodes only encountering =
nodes<br></blockquote><blockquote type=3D"cite">that live in a common =
area and have some common purpose making it =
useful<br></blockquote><blockquote type=3D"cite">for them to talk to one =
another). We now have to allow at least some<br></blockquote><blockquote =
type=3D"cite">nodes to be very mobile, associating with several other =
groups of DTN<br></blockquote><blockquote type=3D"cite">nodes and =
occasionally migrating back into the (legacy) =
Internet.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I think the =
notion of association is a useful structuring mechanism, =
but<br></blockquote><blockquote type=3D"cite">nodes need to be allowed =
to be members of multiple associations.<br></blockquote><blockquote =
type=3D"cite">Associations could be recursive, but I don't want to go =
down the path of<br></blockquote><blockquote type=3D"cite">a single =
hierarchy.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Perhaps =
the bundle agent identity does not have to be a URI, but =
some<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">unique =
identifier that can be bound to various URI's (aliased). &nbsp;This =
might<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">help =
security.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">In ION we address this by =
drawing a firm distinction between DTN endpoints and underlying =
convergence-layer protocol "ducts", with a managed mapping between the =
two. &nbsp;The former are necessarily URIs, but the latter are =
not.<br></blockquote></blockquote><br>I think in most cases you don't =
care about the identity of a node. &nbsp;You care about the authorship =
of data.<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">If we =
don't have a heretical addressing structure, perhaps we can develop =
a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">hierarchical naming =
structure.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I think there are good reasons =
for not doing that in all cases, though. &nbsp;Hierarchies are =
convenient, but they also tend to be inflexible and difficult to =
revise.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite">+1<br></blockquote><br>I think hierarchical naming, =
independent of topology, is likely a reasonable thing. &nbsp;There may =
be multiple hierarchical name spaces, however.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Without some form or hierarchy, =
will DTNs be simple edge network =
gateways<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">do to =
an inability to scale the =
network?<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I don't think so. &nbsp;In some =
ways I think a flat namespace is actually more robust than a =
hierarchical address space.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><br>There is a very =
fundamental question here, and its not only a DTN question. &nbsp;Can a =
non-hierarchical addressing scheme be made to work. &nbsp;I have been =
doing some work with compact routing (see CCR paper on this for a sort =
of summary). &nbsp;The short answer is 'it seems so', but the longer =
answer is that when there is too much dynamics in the network it can be =
difficult. &nbsp;I think it is probably among the most important =
networking research questions to answer at this point.<br><br><br>- =
K<br><br><br></div></blockquote></div><br></div></div></blockquote></div><=
br></body></html>=

--Apple-Mail-18--814898468--

From: Kevin Fall <[email-masked]>
To: DTN interest <[email-masked]>
Date: Tue, 17 Mar 2009 17:54:40 -0700
Subject: [dtn-interest] test e-mail (#2) / please ignore this too

sorry about this...

From: "Fall, Kevin" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 17:53:07 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] test email / please ignore

--_000_02968BB921677D479DAB47F25B7312230101B39639orsmsx504amrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

seems my outgoing e-mail is acting fishy....

--_000_02968BB921677D479DAB47F25B7312230101B39639orsmsx504amrc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>seems my outgoing e-mail is acting fishy&#8230;.<o:p><=
/o:p></p>

</div>

</body>

</html>

--_000_02968BB921677D479DAB47F25B7312230101B39639orsmsx504amrc_--

From: Kevin Fall <[email-masked]>
To: Hans Kruse <[email-masked]>
Date: Tue, 17 Mar 2009 17:44:46 -0700
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-metadata-block

--Apple-Mail-17--815634660
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Right.  Couldn't we just have a "blah blah ontology" descriptor  
block?  The idea of blocks themselves being extensible in somewhat  
arbitrary ways seems troubling to me.  Certainly it would be possible  
to reserve some # of block numbers..

- K

On Mar 5, 2009, at Mar 512:39 PMPST, Hans Kruse wrote:

> I am not sure I am entirely comfortable with that.   Even if they  
> are not "publicly available", couldn't collisions still occur?  You  
> use a number for an ontology, but your router also forwards bundles  
> for another project.  If they start using the same number for their  
> (different) meta-data blocks, there will be a problem.
>
> How about specifying that a specific range of numbers requires IANA  
> registration (or one could specify a range that does NOT require  
> registration; depends on which case might be more common).   That  
> would provide protection for implementations that need to work in an  
> environment where bundles from different projects can get mixed.
>
> On Mar 5, 2009, at 3:00 PM, Symington, Susan F. wrote:
>
>>> #2 Should ontologies be managed by IANA? If so, should the
>>> rule be specification required? It says "...providing the
>>> content and format have been defined and documented as
>>> part of an ontology" which'd imply a spec (or is there
>>> an ontology-police somewhere else? :-)
>>>
>> No, I don't believe that these ontologies should be managed by  
>> IANA. Many, as I stated, will not ever be made publicly available,  
>> so such registration should not be a requirement. Certainly folks  
>> could register their ontologies with IANA if desired, but it  
>> shouldn't be required.
>
> Hans Kruse, Professor
> J. Warren McClure School of Information and Telecommunication Systems
> Adjunct Associate Professor of Electrical Engineering and Computer  
> Science
> 292 Lindley Hall, Ohio University, Athens, OH, 45701
> 740-593-4891 voice, 740-593-4889 fax
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-17--815634660
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Right. &nbsp;Couldn't we just =
have a "blah blah ontology" descriptor block? &nbsp;The idea of blocks =
themselves being extensible in somewhat arbitrary ways seems troubling =
to me. &nbsp;Certainly it would be possible to reserve some # of block =
numbers..<div><br></div><div>- =
K</div><div><br></div><div><br><div><div>On Mar 5, 2009, at Mar 512:39 =
PMPST, Hans Kruse wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I am not sure I am entirely =
comfortable with that. &nbsp; Even if they are not "publicly available", =
couldn't collisions still occur? &nbsp;You use a number for an ontology, =
but your router also forwards bundles for another project. &nbsp;If they =
start using the same number for their (different) meta-data blocks, =
there will be a problem.<div><br></div><div>How about specifying that a =
specific range of numbers requires IANA registration (or one could =
specify a range that does NOT require registration; depends on which =
case might be more common). &nbsp; That would provide protection for =
implementations that need to work in an environment where bundles from =
different projects can get mixed.</div><div><br><div><div>On Mar 5, =
2009, at 3:00 PM, Symington, Susan F. wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><blockquote type=3D"cite">#2 =
Should ontologies be managed by IANA? If so, should =
the<br></blockquote><blockquote type=3D"cite">rule be specification =
required? It says "...providing the<br></blockquote><blockquote =
type=3D"cite">content and format have been defined and documented =
as<br></blockquote><blockquote type=3D"cite">part of an ontology" =
which'd imply a spec (or is there<br></blockquote><blockquote =
type=3D"cite">an ontology-police somewhere else? =
:-)<br></blockquote><blockquote type=3D"cite"><br></blockquote>No, I =
don't believe that these ontologies should be managed by IANA. Many, as =
I stated, will not ever be made publicly available, so such registration =
should not be a requirement. Certainly folks could register their =
ontologies with IANA if desired, but it shouldn't be =
required.<br></span></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Hans =
Kruse, Professor</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren =
McClure School of Information and Telecommunication =
Systems</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Adjunct Associate Professor =
of Electrical Engineering and Computer Science</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">740-593-4891 voice, =
740-593-4889 fax</font></div></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></div>_______________________________________________<br>d=
tn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></blockquote></div><br></div></body></html>=

--Apple-Mail-17--815634660--

From: Kevin Fall <[email-masked]>
To: Susan Symington <[email-masked]>
Date: Tue, 17 Mar 2009 17:34:45 -0700
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

related to several of these issues, I'm not so sure why this is  
extensible.  If you want a previous hop EID, then we can have a block  
for that and if you want a timestamp (or two, etc), then that could be  
a different block.  [it might be curious if you had w/out the other,  
though as it brings up just who put the timestamp in there, but one  
could imagine a possible use case for that].

- K

On Mar 4, 2009, at Mar 42:24 AMPST, Stephen Farrell wrote:

>
> I have a few issues with this one that I think might warrant
> discussion (attached).
>
> Sorry if these've come up before and I wasn't paying attention.
>
> Stephen.
>
> SF comments on draft-irtf-dtnrg-bundle-previous-hop-block-05
>
> 20090304
>
> #1 IANA stuff.  Given that we'll probably want a block type  
> registry, why make
> this one exensible as well? I think I'd prefer that we not make this  
> extensible
> even though there're only 8 bits for block types. I guess I'm  
> wondering why all
> values added for single-hop purposes should use this block type,  
> which seems to
> be implied by the current scheme.
>
> #2 If a bundle with this is sent to a node that doesn't implement  
> this block
> then it'll delete the block before forwarding. However, the  
> dictionary in that
> forwarded bundle will still contain any EIDs inserted for this  
> block, thus
> breaking e2e integrity. Wouldn't it be better for this block to not  
> use the
> dictionary to avoid this problem?
>
> #3 The timestamp seems ambiguous - is it the time at which the  
> bundle departs
> the forwarder? Why not allow adding the time of arrival as well?
>
> #4 Is there really a use-case for the EID-only version of this? If  
> not, or if
> its a corner case, then changing this to make the timestamp (or two,  
> see #2)
> mandatory would be simpler.
>
> #5 The timestamp has a 1second granularity, but in the BP we have a  
> sequence
> value as well to distinguish bundles sent in the same second.  
> Suggest copying
> that here too or (maybe better) having a timstamp that allows  
> microseconds as
> well.
>
> #6 Given the 1s granularity and that the timestamp is an offset from  
> the bundle
> creation time, the text should give guidance on rounding up or down.
>
> #7 Making the timestamp an offset means that if we define a way for
> timeless-nodes to use the BP (e.g. with a "special" time value and  
> some other
> block/flag) then this offset scheme might be affected. If this  
> timestamp were
> the wall-clock time of the forwarder then the dependency wouldn't  
> arise.
>
> #8 What if the forwarder has no clock?
>
> #9 Why would a bundle ever have >1 of these blocks? (As is allowed  
> by 3.1)
>
> #10 Security considerations: what if the forwarder lies about its  
> EID or the
> time? This block could provide a nice way to subvert routing  
> strategies, e.g.
> to create a DoS against the EID named as the forwarder, if the  
> receiver uses
> that to decide to route bundles via that EID. There may be other  
> security
> issues as well but I think receivers should be warned to think about  
> this.
>
> #11 Security considerations: "If encryption of this block is  
> desired..."
> Another alternative would be to encapsulate which is probably worth  
> a mention.
>
> #12 If a BP implementation doesn't properly implement the "Discard  
> block if it
> can't be processed" then this block will persist unexpectedly.   
> Dunno if that's
> a risk worth a mention in the sec. cons. section or not?  (If there  
> are BP
> implementations out there that don't do block discarding right, or  
> at all, then
> I suspect it should be mentioned.)
>
> Nits:
>
> #1 Intro says that the two formats are "mandatory" which is odd -  
> presumably
> that's mandatory-to-implement (if supporting this spec)?
>
> #2 I think the text could be shortened, its a bit wordy.
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
To: dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 17:10:40 -0700
Subject: [dtn-interest] Fwd:  Naming and Addressing

--Apple-Mail-16--817680641
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

trying a re-send... it didn't look like this went out. [?]

- K

Begin forwarded message:

> From: Kevin Fall <[email-masked]>
> Date: March 17, 2009 12:14:35 PM PDT
> To: Elwyn Davies <[email-masked]>
> Cc: "Burleigh, Scott C" <[email-masked]>, dtn  
> interest <[email-masked]>
> Subject: Re: [dtn-interest] Naming and Addressing
>
> some comments inline.  I expect to be giving a short presentation at  
> the upcoming Google meeting that makes more concrete some of the  
> things I mentioned in Germany (i.e., about naming structures and URI/ 
> scheme use).
>
> - K
>
>
> On Mar 17, 2009, at Mar 174:11 AMPDT, Elwyn Davies wrote:
>
>> Burleigh, Scott C wrote:
>>>> -----Original Message-----
>>>> From: [email-masked]  
>>>> [mailto:dtn-
>>>> [email-masked]] On Behalf Of  
>>>> Ivancic,
>>>> William D. (GRC-RHN0)
>>>> Sent: Monday, March 16, 2009 9:27 PM
>>>> To: dtn interest
>>>> Subject: [dtn-interest] Naming and Addressing
>>>>
>>>> Naming and addressing is one of the points of technical  
>>>> discussion for the
>>>> DTNRG meetings March 19 and 20.  I thought I could get some  
>>>> discussion
>>>> started here.
>>>>
>>>> This discussion started on a NASA internal list, but we can bound  
>>>> the
>>>> problem there as Space is, in many ways, much simpler due to the  
>>>> size of
>>>> the network and the predictability of the network (at least for a  
>>>> space-
>>>> base backbone).
>>>>
>>>> The current DTN Bundling Architecture (not the bundling  
>>>> framework, rather
>>>> the architecture) really does not have a common lower layer  
>>>> address space.
>>>> At least that is the way it looks to me.  The bundle agent connects
>>>> directly to convergence layers with no DTN addressing scheme.
>>>>
>>>
>>> I would say you are right, Will: the DTN architecture doesn't have  
>>> any notion of addresses that I am aware of.  Routing of a bundle  
>>> is done on the basis of the *name* of its destination, not the  
>>> address (which may well not be known to the sender or any relay  
>>> point, because the destination node may be locally mobile).  "Late  
>>> binding" in DTN is, essentially, the resolution of name to address  
>>> at the last possible moment, in recognition of the significant  
>>> chance that this resolution will change over the course of the  
>>> bundle's progress from its source to its destination..
>>>
>> One way of expressing this is that the DTN name doesn't define the  
>> path
>> in advance.
>
>
> Right, there isn't really a DTN addressing scheme per-se.  That is  
> by design.  In particular, there is the URI idea with where  
> different name spaces can be represented.  You can represent any  
> addressing scheme you choose to use using that construct.  Also, you  
> can map between them, which is a point I will be interested in  
> discussing thu/fri.  Note that even in Internet we move between  
> multiples name and address spaces (e.g., DNS, mail names, and  
> sometimes IP addresses if we have reason to believe DNS isn't  
> working).  This type of flexibility is necessary for DTN as well, so  
> I believe "there can be only one" is absolutely not the right  
> thing.  Late binding is an option that I think matches well to high- 
> delay networks.  However, there are some cases where early binding  
> and possibly source-routing is needed, and the naming/addressing  
> architecture should be able to handle it too.
>
>>
>>
>> Because of the overloading of IP addresses as both identifier and
>> locator, the choice of addresses at the source in IP effectively  
>> binds
>> the packet to a path through the IP network before the packet sets  
>> off.
>> One can quibble about the details (like load spreading across  
>> multiple
>> paths in the core, backup paths coming into play, rerouting) but  
>> for the
>> vast majority of packets the routing fate of the packet is known at  
>> the
>> time of  despatch. Originally just the destination address mattered.
>> Now the source and possibly some QoS bits may come into play but this
>> doesn't really change the situation. In IP the per-packet routing
>> 'decision' at each router is not really a decision at all but a  
>> lookup.
>
> Generally true.  The exception being some of the on-demand ad-hoc  
> type protocols.
>
>>
>> The decision has been made previously by the control plane routing
>> protocol and the packet is tied to that path.  [Aside: The IP world  
>> has
>> come to be wedded to the path predestination 'principle' (dogma?).
>> Multipath routing is being considered in the research community but  
>> is
>> not mainstream.  Most, if not all, of the proposed fixes for the
>> multihoming problem and providing an id/locator split still cling  
>> to the
>> predestined path, although it may be a bit disguised.]
>
> Right, and so most of these discussions tend to involve some sort of  
> distributed mapping system that takes either "names" or "addresses"  
> and converts them into some other form of address.  (see LISP from  
> RRG as an example).  In my opinion it only sort of helps the major  
> problems facing the Internet, at the cost of introducing some  
> others.  {e.g., try reading the DNSSEC documents then imagine  
> securing yet another lookup scheme; although its possibly we won't  
> have it much easier}.
>
>>
>>
>> In DTN, particularly with the more opportunist encounter type of
>> network, there is a real decision to be made and this can be  
>> influenced
>> by aspects of the bundle, although I think that apart from size and
>> possibly custody requirements this hasn't had much effect as yet.
>
> There is another important couple of decisions:  what protocol to  
> use and whether to copy of forward the bundle.
> [not to mention any security issues].
>
>>
>>>
>>>> To me, it
>>>> would be desirable to have some type of topological and  
>>>> hierarchical
>>>> addressing scheme to aid in routing and security (something  
>>>> similar to IP-
>>>> tables).
>>>>
>>>
>>> That would clearly be one, very familiar way to support routing  
>>> and security, but in my understanding of DTN it would not be the  
>>> DTN way.
>>>
>> IMO it would be highly undesirable to take us down the path of a  
>> totally
>> hierarchical system.  Although it looks promising as a scaling
>> mechanism, the existing IP routing system shows that you have to be  
>> very
>> careful about what happens when it gets very big.  Also the notion  
>> of a
>> single authority that tends to be the follow on to a hierarchy  
>> doesn't
>> chime well with DTN.
>
> agree.  Much of the current Internet problems are a consequence of  
> the hierarchy forced upon us by CIDR. Granted, CIDR was arguably  
> necessary at the time it was deployed, but things like provider  
> independence, multihoming, and mobility are made much much harder by  
> it.
>>
>>>
>>>> However, because there is no common addressing scheme, a
>>>> multitude of DTN bundle agents looks like a flat network because  
>>>> I think
>>>> what we really have is  application-layer store and forward  
>>>> gateways that
>>>> can be graphically connected.  So in the strictest definition of  
>>>> a network
>>>> being related to graph theory, you sort of have a network.  But  
>>>> when one
>>>> looks at what one would expect from a network (things like a common
>>>> addressing scheme), it is not currently present.
>
> I suggested above why a (loosened) definition of Internet doesn't  
> support a single common addressing scheme.
>
>>>>
>>>>
>>>
>>> Right, the network is different from IP in that routing is done on  
>>> the basis of name, as far as possible, rather than on the basis of  
>>> address.  This is one of the significant ways in which DTN differs  
>>> from IP.
>>>
>>>
>>>> Wes Eddy pointed out the following:
>>>>
>>>> "The typical approach is to enable the split by setting up 2 sub- 
>>>> layers,
>>>> one with locators below and one with identifiers above.  In DTN,  
>>>> we have a
>>>> different approach.  An EID could be either a locator or an  
>>>> identifier
>>>> depending on how the EID scheme and forwarding on it are  
>>>> defined.  Inside a
>>>> bundle agent though, EIDs and next-hops have to map to  
>>>> convergence layer
>>>> addresses, which may or may not be locators themselves, but are  
>>>> definitely
>>>> the locators from a bundle agent's point-of-view as they  
>>>> basically specify
>>>> network coordinates at some specific time.
>
> agree with the gist of this but not sure I'd agree they are  
> 'definitely the locators'.  But
> I don't think its very important to argue it either.
>
>>>>
>>>>
>>>> So ... I'd say that an EID *can* be an address, though you don't  
>>>> often want
>>>> it to be one, but a set of convergence layer parameters is the  
>>>> real address
>>>> in the DTN architecture."
>>>>
>>>
>>> Right, there are no addresses in use at what serves as the  
>>> "network protocol" within DTN (the Bundle Protocol), but there are  
>>> addresses in use within the underlying convergence-layer  
>>> protocols.  These are the addresses that are computed by "late  
>>> binding".
>
> there are no mandated addresses.
>
>>>
>>>
>> And they are really only of point-to-point significance in one
>> forwarding hop.  On a multihop path, the convergence layer parameters
>> (essentially a token to send a bundle along a particular active link)
>> are a local mapping at each node that are not relevant once the  
>> bundle
>> has moved to the next node.
>
> I wouldn't say point to point exactly, as we might well have a bcast  
> or mcast distribution model, but
> yes there is some truth to this point.
>
>>
>>>
>>>> ---> Back to my thoughts <---
>>>>
>>>> I believe BBN is looking at running DTN as the network directly  
>>>> over a
>>>> meshed wireless ad hoc network.  Thus DTN is the upper layer  
>>>> network.
>>>> There is not IP network.  In this case, I believe they are using  
>>>> the radio
>>>> MAC and the Endpoint Identifier and realize this does not scale.   
>>>> Also I am
>>>> not sure if this is a multi-radio system with one MAC address or  
>>>> something
>>>> else.  But it has been proven that naming the end system by the  
>>>> interface
>>>> is bad for multihoming.
>>>>
>>>
>>> If I understand you right, Will, I agree.  I think the way you get  
>>> multihoming in DTN is by having multiple convergence-layer service  
>>> access points (for, most likely, multiple convergence-layer  
>>> protocols) at a single node.
>>>
>> I think there is some confusion here (as there often is in IP
>> discussions of multihoming) between the logical multihoming  
>> (typically a
>> service agreement between the end network and a service provider)   
>> and
>> physical multihoming (having multiple independent network interfaces
>> available simultaneously).  In DTN networks a node may have multiple
>> physical interfaces (quite possibly using different  convergence- 
>> layer
>> protocols) but it can also have multiple logical links over a single
>> convergence layer (e.g., simultaneous ad hoc Wi-Fi connections).    
>> And
>> there is the additional dimension that these links (unlike the  
>> usual IP
>> case) are not necessarily simultaneously active/available.  So, yes  
>> it
>> is probably not generally clever to identify a node with a single
>> interface, but that doesn't necessarily prevent it being multihomed  
>> if
>> the single interface is a wireless interface that can support  
>> multiple
>> ad hoc connections at once.
>>
>> In most of the IP multihoming discussions we are talking about a hard
>> wired mapping between the administrative connections of a logically
>> multihomed node and the physical connections. IP early binding then
>> ought to tie a packet with given addresses to a path through one or
>> other of the links.  For a large proportion of DTN networks these
>> concepts are irrelevant, although gateways will generally have  
>> different
>> associations on either side.
>>>
>>>> I think we should address multi-homing and mobility at the  
>>>> onset.  Late-
>>>> binding might help us here.  Ignoring the problem in the past has  
>>>> resulted
>>>> in poor band-aid approaches to trying to get something to work  
>>>> later.
>>>>
>>>
>>> I agree that we should take multi-homing and mobility into account  
>>> right from the beginning.
>>>
>
> that was largely the motivation to get rid of "regions" as a  
> mandated concept
>
>> Absolutely.  Dealing (as I do) with 'data mule' type networks many of
>> the nodes are mobile, but early thinking only made them physically
>> mobile, keeping them essentially within one 'association'  (we aren't
>> allowed to call it a region  but  for the purposes of understanding
>> history, we were originally talking about nodes only encountering  
>> nodes
>> that live in a common area and have some common purpose making it  
>> useful
>> for them to talk to one another). We now have to allow at least some
>> nodes to be very mobile, associating with several other groups of DTN
>> nodes and occasionally migrating back into the (legacy) Internet.
>>
>> I think the notion of association is a useful structuring  
>> mechanism, but
>> nodes need to be allowed to be members of multiple associations.
>> Associations could be recursive, but I don't want to go down the  
>> path of
>> a single hierarchy.
>>
>>
>>>
>>>> Perhaps the bundle agent identity does not have to be a URI, but  
>>>> some
>>>> unique identifier that can be bound to various URI's (aliased).   
>>>> This might
>>>> help security.
>>>>
>>>
>>> In ION we address this by drawing a firm distinction between DTN  
>>> endpoints and underlying convergence-layer protocol "ducts", with  
>>> a managed mapping between the two.  The former are necessarily  
>>> URIs, but the latter are not.
>
> I think in most cases you don't care about the identity of a node.   
> You care about the authorship of data.
>
>>>
>>>
>>>
>>>> If we don't have a heretical addressing structure, perhaps we can  
>>>> develop a
>>>> hierarchical naming structure.
>>>>
>>>
>>> I think there are good reasons for not doing that in all cases,  
>>> though.  Hierarchies are convenient, but they also tend to be  
>>> inflexible and difficult to revise.
>>>
>>>
>> +1
>
> I think hierarchical naming, independent of topology, is likely a  
> reasonable thing.  There may be multiple hierarchical name spaces,  
> however.
>
>>
>>>> Without some form or hierarchy, will DTNs be simple edge network  
>>>> gateways
>>>> do to an inability to scale the network?
>>>>
>>>
>>> I don't think so.  In some ways I think a flat namespace is  
>>> actually more robust than a hierarchical address space.
>>>
>
> There is a very fundamental question here, and its not only a DTN  
> question.  Can a non-hierarchical addressing scheme be made to  
> work.  I have been doing some work with compact routing (see CCR  
> paper on this for a sort of summary).  The short answer is 'it seems  
> so', but the longer answer is that when there is too much dynamics  
> in the network it can be difficult.  I think it is probably among  
> the most important networking research questions to answer at this  
> point.
>
>
> - K
>
>

--Apple-Mail-16--817680641
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">trying a re-send... it didn't =
look like this went out. [?]<div><br></div><div>- =
K<br><div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">Kevin Fall &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></font></div><=
div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>Date: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">March 17, 2009 12:14:35 PM PDT</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>To: </b></font><font =
face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px Helvetica">Elwyn =
Davies &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></font></div><=
div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>Cc: </b></font><font =
face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">"Burleigh, Scott C" &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]=
v</a>>, dtn interest &lt;<a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a>></font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica"><b>Re: [dtn-interest] Naming and =
Addressing</b></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><br></div> </div><div>some comments inline. &nbsp;I expect to be =
giving a short presentation at the upcoming Google meeting that makes =
more concrete some of the things I mentioned in Germany (i.e., about =
naming structures and URI/scheme use).<br><br>- K<br><br><br>On Mar 17, =
2009, at Mar 174:11 AMPDT, Elwyn Davies wrote:<br><br><blockquote =
type=3D"cite">Burleigh, Scott C wrote:<br></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">-----Original =
Message-----<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">From: =
[email-masked] [<a =
href=3D"mailto:dtn-">mailto:dtn-</a><br></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"mailto:[email-masked]">interest-bou=
[email-masked]</a>] On Behalf Of =
Ivancic,<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">William =
D. (GRC-RHN0)<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Sent: =
Monday, March 16, 2009 9:27 =
PM<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To: =
dtn interest<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Subject:=
 [dtn-interest] Naming and =
Addressing<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Naming =
and addressing is one of the points of technical discussion for =
the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">DTNRG =
meetings March 19 and 20. &nbsp;I thought I could get some =
discussion<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">started =
here.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">This =
discussion started on a NASA internal list, but we can bound =
the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">problem =
there as Space is, in many ways, much simpler due to the size =
of<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">the =
network and the predictability of the network (at least for a =
space-<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">base =
backbone).<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">The =
current DTN Bundling Architecture (not the bundling framework, =
rather<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">the =
architecture) really does not have a common lower layer address =
space.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">At =
least that is the way it looks to me. &nbsp;The bundle agent =
connects<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">directly=
 to convergence layers with no DTN addressing =
scheme.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I would say you are right, Will: =
the DTN architecture doesn't have any notion of addresses that I am =
aware of. &nbsp;Routing of a bundle is done on the basis of the *name* =
of its destination, not the address (which may well not be known to the =
sender or any relay point, because the destination node may be locally =
mobile). &nbsp;"Late binding" in DTN is, essentially, the resolution of =
name to address at the last possible moment, in recognition of the =
significant chance that this resolution will change over the course of =
the bundle's progress from its source to its =
destination..<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote type=3D"cite">One =
way of expressing this is that the DTN name doesn't define the =
path<br></blockquote><blockquote type=3D"cite">in =
advance.<br></blockquote><br><br>Right, there isn't really a DTN =
addressing scheme per-se. &nbsp;That is by design. &nbsp;In particular, =
there is the URI idea with where different name spaces can be =
represented. &nbsp;You can represent any addressing scheme you choose to =
use using that construct. &nbsp;Also, you can map between them, which is =
a point I will be interested in discussing thu/fri. &nbsp;Note that even =
in Internet we move between multiples name and address spaces (e.g., =
DNS, mail names, and sometimes IP addresses if we have reason to believe =
DNS isn't working). &nbsp;This type of flexibility is necessary for DTN =
as well, so I believe "there can be only one" is absolutely not the =
right thing. &nbsp;Late binding is an option that I think matches well =
to high-delay networks. &nbsp;However, there are some cases where early =
binding and possibly source-routing is needed, and the naming/addressing =
architecture should be able to handle it too.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Because of the =
overloading of IP addresses as both identifier =
and<br></blockquote><blockquote type=3D"cite">locator, the choice of =
addresses at the source in IP effectively =
binds<br></blockquote><blockquote type=3D"cite">the packet to a path =
through the IP network before the packet sets =
off.<br></blockquote><blockquote type=3D"cite">One can quibble about the =
details (like load spreading across multiple<br></blockquote><blockquote =
type=3D"cite">paths in the core, backup paths coming into play, =
rerouting) but for the<br></blockquote><blockquote type=3D"cite">vast =
majority of packets the routing fate of the packet is known at =
the<br></blockquote><blockquote type=3D"cite">time of &nbsp;despatch. =
Originally just the destination address =
mattered.<br></blockquote><blockquote type=3D"cite">Now the source and =
possibly some QoS bits may come into play but =
this<br></blockquote><blockquote type=3D"cite">doesn't really change the =
situation. In IP the per-packet routing<br></blockquote><blockquote =
type=3D"cite">'decision' at each router is not really a decision at all =
but a lookup.<br></blockquote><br>Generally true. &nbsp;The exception =
being some of the on-demand ad-hoc type protocols.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">The decision =
has been made previously by the control plane =
routing<br></blockquote><blockquote type=3D"cite">protocol and the =
packet is tied to that path. &nbsp;[Aside: The IP world =
has<br></blockquote><blockquote type=3D"cite">come to be wedded to the =
path predestination 'principle' (dogma?).<br></blockquote><blockquote =
type=3D"cite">Multipath routing is being considered in the research =
community but is<br></blockquote><blockquote type=3D"cite">not =
mainstream. &nbsp;Most, if not all, of the proposed fixes for =
the<br></blockquote><blockquote type=3D"cite">multihoming problem and =
providing an id/locator split still cling to =
the<br></blockquote><blockquote type=3D"cite">predestined path, although =
it may be a bit disguised.]<br></blockquote><br>Right, and so most of =
these discussions tend to involve some sort of distributed mapping =
system that takes either "names" or "addresses" and converts them into =
some other form of address. &nbsp;(see LISP from RRG as an example). =
&nbsp;In my opinion it only sort of helps the major problems facing the =
Internet, at the cost of introducing some others. &nbsp;{e.g., try =
reading the DNSSEC documents then imagine securing yet another lookup =
scheme; although its possibly we won't have it much =
easier}.<br><br><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">In DTN, =
particularly with the more opportunist encounter type =
of<br></blockquote><blockquote type=3D"cite">network, there is a real =
decision to be made and this can be =
influenced<br></blockquote><blockquote type=3D"cite">by aspects of the =
bundle, although I think that apart from size =
and<br></blockquote><blockquote type=3D"cite">possibly custody =
requirements this hasn't had much effect as =
yet.<br></blockquote><br>There is another important couple of decisions: =
&nbsp;what protocol to use and whether to copy of forward the =
bundle.<br>[not to mention any security issues].<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To me, =
it<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">would =
be desirable to have some type of topological and =
hierarchical<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">addressing scheme to aid in routing and security =
(something similar to =
IP-<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">tables).<br></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">That would clearly be one, very =
familiar way to support routing and security, but in my understanding of =
DTN it would not be the DTN =
way.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote type=3D"cite">IMO =
it would be highly undesirable to take us down the path of a =
totally<br></blockquote><blockquote type=3D"cite">hierarchical system. =
&nbsp;Although it looks promising as a =
scaling<br></blockquote><blockquote type=3D"cite">mechanism, the =
existing IP routing system shows that you have to be =
very<br></blockquote><blockquote type=3D"cite">careful about what =
happens when it gets very big. &nbsp;Also the notion of =
a<br></blockquote><blockquote type=3D"cite">single authority that tends =
to be the follow on to a hierarchy doesn't<br></blockquote><blockquote =
type=3D"cite">chime well with DTN.<br></blockquote><br>agree. &nbsp;Much =
of the current Internet problems are a consequence of the hierarchy =
forced upon us by CIDR. Granted, CIDR was arguably necessary at the time =
it was deployed, but things like provider independence, multihoming, and =
mobility are made much much harder by it.<br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">However,=
 because there is no common addressing scheme, =
a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">multitude of DTN bundle agents looks like a flat network =
because I think<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">what =
we really have is &nbsp;application-layer store and forward gateways =
that<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">can be =
graphically connected. &nbsp;So in the strictest definition of a =
network<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">being =
related to graph theory, you sort of have a network. &nbsp;But when =
one<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">looks =
at what one would expect from a network (things like a =
common<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">addressing scheme), it is not currently =
present.<br></blockquote></blockquote></blockquote><br>I suggested above =
why a (loosened) definition of Internet doesn't support a single common =
addressing scheme.<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Right, the network is different =
from IP in that routing is done on the basis of name, as far as =
possible, rather than on the basis of address. &nbsp;This is one of the =
significant ways in which DTN differs from =
IP.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Wes =
Eddy pointed out the =
following:<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">"The =
typical approach is to enable the split by setting up 2 =
sub-layers,<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">one =
with locators below and one with identifiers above. &nbsp;In DTN, we =
have a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">different approach. &nbsp;An EID could be either a locator =
or an identifier<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">depending on how the EID scheme and forwarding on it are =
defined. &nbsp;Inside =
a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">bundle =
agent though, EIDs and next-hops have to map to convergence =
layer<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">addresses, which may or may not be locators themselves, =
but are definitely<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">the =
locators from a bundle agent's point-of-view as they basically =
specify<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">network =
coordinates at some specific =
time.<br></blockquote></blockquote></blockquote><br>agree with the gist =
of this but not sure I'd agree they are 'definitely the locators'. =
&nbsp;But<br>I don't think its very important to argue it =
either.<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">So ... =
I'd say that an EID *can* be an address, though you don't often =
want<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">it to =
be one, but a set of convergence layer parameters is the real =
address<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">in the =
DTN architecture."<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Right, there are no addresses in =
use at what serves as the "network protocol" within DTN (the Bundle =
Protocol), but there are addresses in use within the underlying =
convergence-layer protocols. &nbsp;These are the addresses that are =
computed by "late binding".<br></blockquote></blockquote><br>there are =
no mandated addresses.<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote type=3D"cite">And =
they are really only of point-to-point significance in =
one<br></blockquote><blockquote type=3D"cite">forwarding hop. &nbsp;On a =
multihop path, the convergence layer =
parameters<br></blockquote><blockquote type=3D"cite">(essentially a =
token to send a bundle along a particular active =
link)<br></blockquote><blockquote type=3D"cite">are a local mapping at =
each node that are not relevant once the =
bundle<br></blockquote><blockquote type=3D"cite">has moved to the next =
node.<br></blockquote><br>I wouldn't say point to point exactly, as we =
might well have a bcast or mcast distribution model, but<br>yes there is =
some truth to this point.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">---> =
Back to my thoughts =
&lt;---<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">I =
believe BBN is looking at running DTN as the network directly over =
a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">meshed =
wireless ad hoc network. &nbsp;Thus DTN is the upper layer =
network.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">There =
is not IP network. &nbsp;In this case, I believe they are using the =
radio<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">MAC =
and the Endpoint Identifier and realize this does not scale. &nbsp;Also =
I am<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">not =
sure if this is a multi-radio system with one MAC address or =
something<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">else. =
&nbsp;But it has been proven that naming the end system by the =
interface<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">is bad =
for multihoming.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">If I understand you right, Will, =
I agree. &nbsp;I think the way you get multihoming in DTN is by having =
multiple convergence-layer service access points (for, most likely, =
multiple convergence-layer protocols) at a single =
node.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote type=3D"cite">I =
think there is some confusion here (as there often is in =
IP<br></blockquote><blockquote type=3D"cite">discussions of multihoming) =
between the logical multihoming (typically a<br></blockquote><blockquote =
type=3D"cite">service agreement between the end network and a service =
provider) &nbsp;and<br></blockquote><blockquote type=3D"cite">physical =
multihoming (having multiple independent network =
interfaces<br></blockquote><blockquote type=3D"cite">available =
simultaneously). &nbsp;In DTN networks a node may have =
multiple<br></blockquote><blockquote type=3D"cite">physical interfaces =
(quite possibly using different =
&nbsp;convergence-layer<br></blockquote><blockquote =
type=3D"cite">protocols) but it can also have multiple logical links =
over a single<br></blockquote><blockquote type=3D"cite">convergence =
layer (e.g., simultaneous ad hoc Wi-Fi connections). =
&nbsp;&nbsp;And<br></blockquote><blockquote type=3D"cite">there is the =
additional dimension that these links (unlike the usual =
IP<br></blockquote><blockquote type=3D"cite">case) are not necessarily =
simultaneously active/available. &nbsp;So, yes =
it<br></blockquote><blockquote type=3D"cite">is probably not generally =
clever to identify a node with a single<br></blockquote><blockquote =
type=3D"cite">interface, but that doesn't necessarily prevent it being =
multihomed if<br></blockquote><blockquote type=3D"cite">the single =
interface is a wireless interface that can support =
multiple<br></blockquote><blockquote type=3D"cite">ad hoc connections at =
once.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">In most of the =
IP multihoming discussions we are talking about a =
hard<br></blockquote><blockquote type=3D"cite">wired mapping between the =
administrative connections of a logically<br></blockquote><blockquote =
type=3D"cite">multihomed node and the physical connections. IP early =
binding then<br></blockquote><blockquote type=3D"cite">ought to tie a =
packet with given addresses to a path through one =
or<br></blockquote><blockquote type=3D"cite">other of the links. =
&nbsp;For a large proportion of DTN networks =
these<br></blockquote><blockquote type=3D"cite">concepts are irrelevant, =
although gateways will generally have =
different<br></blockquote><blockquote type=3D"cite">associations on =
either side.<br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">I =
think we should address multi-homing and mobility at the onset. =
&nbsp;Late-<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">binding =
might help us here. &nbsp;Ignoring the problem in the past has =
resulted<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">in =
poor band-aid approaches to trying to get something to work =
later.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I agree that we should take =
multi-homing and mobility into account right from the =
beginning.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><br>that was largely the =
motivation to get rid of "regions" as a mandated =
concept<br><br><blockquote type=3D"cite">Absolutely. &nbsp;Dealing (as I =
do) with 'data mule' type networks many of<br></blockquote><blockquote =
type=3D"cite">the nodes are mobile, but early thinking only made them =
physically<br></blockquote><blockquote type=3D"cite">mobile, keeping =
them essentially within one 'association' &nbsp;(we =
aren't<br></blockquote><blockquote type=3D"cite">allowed to call it a =
region &nbsp;but &nbsp;for the purposes of =
understanding<br></blockquote><blockquote type=3D"cite">history, we were =
originally talking about nodes only encountering =
nodes<br></blockquote><blockquote type=3D"cite">that live in a common =
area and have some common purpose making it =
useful<br></blockquote><blockquote type=3D"cite">for them to talk to one =
another). We now have to allow at least some<br></blockquote><blockquote =
type=3D"cite">nodes to be very mobile, associating with several other =
groups of DTN<br></blockquote><blockquote type=3D"cite">nodes and =
occasionally migrating back into the (legacy) =
Internet.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I think the =
notion of association is a useful structuring mechanism, =
but<br></blockquote><blockquote type=3D"cite">nodes need to be allowed =
to be members of multiple associations.<br></blockquote><blockquote =
type=3D"cite">Associations could be recursive, but I don't want to go =
down the path of<br></blockquote><blockquote type=3D"cite">a single =
hierarchy.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Perhaps =
the bundle agent identity does not have to be a URI, but =
some<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">unique =
identifier that can be bound to various URI's (aliased). &nbsp;This =
might<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">help =
security.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">In ION we address this by =
drawing a firm distinction between DTN endpoints and underlying =
convergence-layer protocol "ducts", with a managed mapping between the =
two. &nbsp;The former are necessarily URIs, but the latter are =
not.<br></blockquote></blockquote><br>I think in most cases you don't =
care about the identity of a node. &nbsp;You care about the authorship =
of data.<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">If we =
don't have a heretical addressing structure, perhaps we can develop =
a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">hierarchical naming =
structure.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I think there are good reasons =
for not doing that in all cases, though. &nbsp;Hierarchies are =
convenient, but they also tend to be inflexible and difficult to =
revise.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite">+1<br></blockquote><br>I think hierarchical naming, =
independent of topology, is likely a reasonable thing. &nbsp;There may =
be multiple hierarchical name spaces, however.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Without some form or hierarchy, =
will DTNs be simple edge network =
gateways<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">do to =
an inability to scale the =
network?<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I don't think so. &nbsp;In some =
ways I think a flat namespace is actually more robust than a =
hierarchical address space.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><br>There is a very =
fundamental question here, and its not only a DTN question. &nbsp;Can a =
non-hierarchical addressing scheme be made to work. &nbsp;I have been =
doing some work with compact routing (see CCR paper on this for a sort =
of summary). &nbsp;The short answer is 'it seems so', but the longer =
answer is that when there is too much dynamics in the network it can be =
difficult. &nbsp;I think it is probably among the most important =
networking research questions to answer at this point.<br><br><br>- =
K<br><br><br></div></blockquote></div><br></div></body></html>=

--Apple-Mail-16--817680641--

Date: Tue, 17 Mar 2009 19:47:02 -0400
From: Armando Caro <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Naming and Addressing

Ivancic, William D. (GRC-RHN0) wrote:

> The current DTN Bundling Architecture (not the bundling framework, rather the architecture) really does not have a common lower layer address space.  At least that is the way it looks to me. 
  <snip>
 > So in the strictest definition of a network being related to graph 
theory, you sort of have a network.  But when one looks at what one 
would expect from a network (things like a common addressing scheme), it 
is not currently present.

I agree with these points.

> I believe BBN is looking at running DTN as the network directly over a meshed wireless ad hoc network.  Thus DTN is the upper layer network.  There is not IP network. 

Not exactly. First, BBN is using DTN in more than one project, and each 
project may use DTN in slightly different ways. To clarify, the BBN DTN 
stack is written in a way that allows it to be used as an IP overlay, IP 
underlay, or something non-IP altogether. Also, a node can use the BBN 
DTN stack to 'gateway' between any of these types of uses.

Based on your description, you are probably referring to BBN's use of 
DTN in the DARPA WNaN program. Assuming that, let me clarify a few more 
points...

> In this case, I believe they are using the radio MAC and the Endpoint Identifier and realize this does not scale.

Yes, but not exclusively. We have the notion of "MAC EIDs", which is an 
algorithmic mapping between MAC addresses and EIDs for the purposes of 
project specific goals. However, we also have the notion of what we call 
"arbitrary EIDs", for lack of a better name. These are EIDs are 
essentially arbitrary names that map to nodes, independent of their address.

>  Also I am not sure if this is a multi-radio system with one MAC address or something else.

Multi-transceiver radio, but one MAC address.

>  But it has been proven that naming the end system by the interface is bad for multihoming.

Yes, we agree... and our design avoids that pitfall.

> Perhaps the bundle agent identity does not have to be a URI, but some unique identifier that can be bound to various URI's (aliased).  This might help security.  

Yes, this is the conclusion that we came to. Also for the purposes of 
routing control traffic, internal system messaging (IPCs), etc... it's 
more efficient to pass around unique node IDs instead of arbitrarily 
long URI/EIDs. Disseminating EID-to-NodeID mappings only as necessary is 
more efficient.

-- 
Armando

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Peter Lovell <[email-masked]>, dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 18:18:11 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] BSP update

Peter,

After Figure 2, all the fields are explained except:
 ciphersuite params data, security result data.  That information is presented elsewhere in portions of the specification such as in 2.4 "..If neither the
   destination nor security-destination resolves the key to use for
   decryption, the ciphersuite parameters field can be used to indicate
   the decryption key with which the BEK can be recovered."

I am sort of confused as to what piece of information I would/should use to identify the key or certificate to use to decrypt the bundle or the Bundle Encryption Key.  If the source EID is not unique is it the Security Parameter.  However later the security parameter in 2.6 says 

"  Item types are
      0: reserved
      1: initialization vector (IV)
      2: reserved
      3: key information"

But a little later is states
"      - key information: key material encoded or protected by the key
      management system, and used to transport an ephemeral key
      protected by a long-term key.  This item is discussed further
      below in Section 2.7"

Which to me implies the key information is "key material encoded or protected by the key
      management system" and thus not something that can be used to identify the core certificate.

/Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Peter Lovell
> Sent: Tuesday, March 17, 2009 5:02 PM
> To: dtn interest
> Subject: Re: [dtn-interest] BSP update
> 
> Hi all,
> 
> here's an updated BSP spec that we can review in Mountain 
> View. The spec submission is closed so it's not on RFC site 
> yet but will be when it reopens.
> 
> The changes are small, dealing mainly with Stephen's comments.
> 
> Cheers.....Peter
> 
> p.s. this is the same one I had circulated to a few people on Sunday.
> There being no specific issues I'm sending to everyone
> 

From: Peter Lovell <[email-masked]>
To: dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 17:01:47 -0400
Subject: Re: [dtn-interest] BSP update

--Boundary_(ID_MK2Ynh94Bd0F+MsR18e4cQ)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Hi all,

here's an updated BSP spec that we can review in Mountain View. The spec
submission is closed so it's not on RFC site yet but will be when it reopens.

The changes are small, dealing mainly with Stephen's comments.

Cheers.....Peter

p.s. this is the same one I had circulated to a few people on Sunday.
There being no specific issues I'm sending to everyone

--Boundary_(ID_MK2Ynh94Bd0F+MsR18e4cQ)
Content-type: text/plain; name=draft-irtf-dtnrg-bundle-security-08a.txt;
	x-mac-type=00000000; x-mac-creator=00000000
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
	filename=draft-irtf-dtnrg-bundle-security-08a.txt

DTN Research Group                                        S.F. Symington
Internet-Draft                                     The MITRE Corporation
Expires: September 15, 2009                                   S. Farrell
                                                  Trinity College Dublin
                                                                H. Weiss
                                                               P. Lovell
                                                            SPARTA, Inc.
                                                          March 14, 2009

                 Bundle Security Protocol Specification
                  draft-irtf-dtnrg-bundle-security-08

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 15, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Symington, et al.      Expires September 15, 2009               [Page 1]

Internet-Draft          Bundle Security Protocol              March 2009

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Symington, et al.      Expires September 15, 2009               [Page 2]

Internet-Draft          Bundle Security Protocol              March 2009

Abstract

   This document defines the bundle security protocol, which provides
   data integrity and confidentiality services.  We also describe
   various bundle security considerations including policy options.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conformance  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Related Documents  . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Security Blocks  . . . . . . . . . . . . . . . . . . . . . . .  8
     2.1.  Abstract Security Block  . . . . . . . . . . . . . . . . .  9
     2.2.  Bundle Authentication Block  . . . . . . . . . . . . . . . 13
     2.3.  Payload Integrity Block  . . . . . . . . . . . . . . . . . 14
     2.4.  Payload Confidentiality Block  . . . . . . . . . . . . . . 15
     2.5.  Extension Security Block . . . . . . . . . . . . . . . . . 19
     2.6.  Parameters and Result Fields . . . . . . . . . . . . . . . 20
     2.7.  Key Transport  . . . . . . . . . . . . . . . . . . . . . . 22
     2.8.  PIB and PCB combinations . . . . . . . . . . . . . . . . . 22
   3.  Security Processing  . . . . . . . . . . . . . . . . . . . . . 25
     3.1.  Nodes as policy enforcement points . . . . . . . . . . . . 25
     3.2.  Processing order of security blocks  . . . . . . . . . . . 25
     3.3.  Security Zones . . . . . . . . . . . . . . . . . . . . . . 28
     3.4.  Canonicalisation of bundles  . . . . . . . . . . . . . . . 30
     3.5.  Endpoint ID confidentiality  . . . . . . . . . . . . . . . 35
     3.6.  Bundles received from other nodes  . . . . . . . . . . . . 35
     3.7.  The At-Most-Once-Delivery Option . . . . . . . . . . . . . 37
     3.8.  Bundle Fragmentation and Reassembly  . . . . . . . . . . . 38
     3.9.  Reactive fragmentation . . . . . . . . . . . . . . . . . . 38
   4.  Standard Ciphersuites  . . . . . . . . . . . . . . . . . . . . 40
     4.1.  BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 40
     4.2.  PIB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 41
     4.3.  PCB-RSA-AES128-PAYLOAD-PIB-PCB . . . . . . . . . . . . . . 42
     4.4.  ESB-RSA-AES128-EXT . . . . . . . . . . . . . . . . . . . . 45
   5.  Key Management . . . . . . . . . . . . . . . . . . . . . . . . 49
   6.  Default Security Policy  . . . . . . . . . . . . . . . . . . . 50
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 52
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 53
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 54
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 54
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56

Symington, et al.      Expires September 15, 2009               [Page 3]

Internet-Draft          Bundle Security Protocol              March 2009

1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document defines security features for the bundle protocol
   [DTNBP] intended for use in delay tolerant networks, in order to
   provide DTN security services.

   The bundle protocol is used in DTNs which overlay multiple networks,
   some of which may be challenged by limitations such as intermittent
   and possibly unpredictable loss of connectivity, long or variable
   delay, asymmetric data rates, and high error rates.  The purpose of
   the bundle protocol is to support interoperability across such
   stressed networks.  The bundle protocol is layered on top of
   underlay-network-specific convergence layers, on top of network-
   specific lower layers, to enable an application in one network to
   communicate with an application in another network, both of which are
   spanned by the DTN.

   Security will be important for the bundle protocol.  The stressed
   environment of the underlying networks over which the bundle protocol
   will operate makes it important that the DTN be protected from
   unauthorized use, and this stressed environment poses unique
   challenges on the mechanisms needed to secure the bundle protocol.
   Furthermore, DTNs may very likely be deployed in environments where a
   portion of the network might become compromised, posing the usual
   security challenges related to confidentiality, integrity and
   availability.

   Separate security processing applies to the payload block and to the
   various extension blocks that may accompany it in a bundle, as
   varying security requirements may apply to them.

   This document describes both the base Bundle Security Protocol (BSP)
   and a set of standard ciphersuites.  A ciphersuite is a specific
   collection of various cryptographic algorithms and implementation
   rules that are used together to provide certain security services.

1.1.  Conformance

   As indicated above, this document describes both BSP and the standard
   ciphersuites.  A conformant implementation MUST implement BSP.  It
   MAY implement some or all of the standard ciphersuites, and MAY
   provide other ciphersuites.

   An implementation described as "conformant plus standard

Symington, et al.      Expires September 15, 2009               [Page 4]

Internet-Draft          Bundle Security Protocol              March 2009

   ciphersuites" MUST implement BSP and all the standard ciphersuites.
   It MAY provide support for other ciphersuites as well.

1.2.  Related Documents

   This document is best read and understood within the context of the
   following other DTN documents:

      The Delay-Tolerant Network Architecture [DTNarch] defines the
      architecture for delay-tolerant networks, but does not discuss
      security at any length.

      The DTN Bundle Protocol [DTNBP] defines the format and processing
      of the blocks used to implement the bundle protocol, excluding the
      security-specific blocks defined here.

      The Delay-Tolerant Networking Security Overview [DTNsecOver]
      provides an informative overview and high-level description of DTN
      security.

1.3.  Terminology

   We introduce the following terminology for purposes of clarity:

      source - the bundle node from which a bundle originates

      destination - the bundle node to which a bundle is ultimately
      destined

      forwarder - the bundle node that forwarded the bundle on its most
      recent hop

      intermediate receiver or "next hop" - the neighboring bundle node
      to which a forwarder forwards a bundle.

   In the figure below, which is adapted from figure 1 in the Bundle
   Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and
   BN4) reside above some transport layer(s).  Three distinct transport
   and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also
   shown.

Symington, et al.      Expires September 15, 2009               [Page 5]

Internet-Draft          Bundle Security Protocol              March 2009

   +---------v-|   +->>>>>>>>>>v-+     +->>>>>>>>>>v-+   +-^---------+
   | BN1     v |   | ^   BN2   v |     | ^   BN3   v |   | ^  BN4    |
   +---------v-+   +-^---------v-+     +-^---------v-+   +-^---------+
   | T1      v |   + ^  T1/T2  v |     + ^  T2/T3  v |   | ^  T3     |
   +---------v-+   +-^---------v-+     +-^---------v +   +-^---------+
   | N1      v |   | ^  N1/N2  v |     | ^  N2/N3  v |   | ^  N3     |
   +---------v-+   +-^---------v +     +-^---------v-+   +-^---------+
   |         >>>>>>>>^         >>>>>>>>>>^         >>>>>>>>^         |
   +-----------+   +------------+      +-------------+   +-----------+
   |                     |                    |                      |
   |<--  An Internet --->|                    |<--- An Internet  --->|
   |                     |                    |                      |

   BN = "Bundle Node" (as defined in the Bundle Protocol Specification

   Bundle Nodes Sit at the Application layer of the Internet Model.

                                 Figure 1

   Bundle node BN1 originates a bundle that it forwards to BN2.  BN2
   forwards the bundle to BN3, and BN3 forwards the bundle to BN4.  BN1
   is the source of the bundle and BN4 is the destination of the bundle.
   BN1 is the first forwarder, and BN2 is the first intermediate
   receiver; BN2 then becomes the forwarder, and BN3 the intermediate
   receiver; BN3 then becomes the last forwarder, and BN4 the last
   intermediate receiver, as well as the destination.

   If node BN2 originates a bundle (for example, a bundle status report
   or a custodial signal), which is then forwarded on to BN3, and then
   to BN4, then BN2 is the source of the bundle (as well as being the
   first forwarder of the bundle) and BN4 is the destination of the
   bundle (as well as being the final intermediate receiver).

   We introduce the following security-specific DTN terminology:

      security-source - a bundle node that adds a security block to a
      bundle

      security-destination - a bundle node that processes a security
      block of a bundle

      security zone - that part of the network path from the security-
      source to the security-destination

   Referring to Figure 1 again:

   If the bundle that originates at BN1 as source is given a security
   block by BN1, then BN1 is the security-source of this bundle with

Symington, et al.      Expires September 15, 2009               [Page 6]

Internet-Draft          Bundle Security Protocol              March 2009

   respect to that security block, as well as being the source of the
   bundle.

   If the bundle that originates at BN1 as source is given a security
   block by BN2, then BN2 is the security-source of this bundle with
   respect to that security block, even though BN1 is the source.

   If the bundle that originates at BN1 as source is given a security
   block by BN1 that is intended to be processed by BN3, then BN1 is the
   security-source and BN3 is the security destination with respect to
   this security block.  The security zone for this block is BN1 to BN3.

   A bundle may have multiple security blocks.  The security-source of a
   bundle with respect to a given security block in the bundle may be
   the same as or different from the security-source of the bundle with
   respect to a different security block in the bundle.  Similarly, the
   security-destination of a bundle with respect to each of that
   bundle's security blocks may be the same or different.  Therefore the
   security zones for various blocks may be and often will be different.

   If the bundle that originates at BN1 as source is given a security
   block by BN1 that is intended to be processed by BN3, and BN2 adds a
   security block with security-destination BN4, the security zones for
   the two blocks overlap but not completely.  This problem is discussed
   further in Section 3.3.

   Forwarding nodes MUST transmit blocks in the same order as they were
   received.  This requirement applies to all dtn nodes, not just ones
   which implement security processing.  Blocks in a bundle may be added
   or deleted according to the applicable specification, but those
   blocks which are both received and transmitted MUST be transmitted in
   the same order that they were received.

   The block sequence also indicates the order in which certain
   significant actions have affected the bundle, and therefore the
   sequence in which actions must occur in order to produce the bundle
   at its destination.

Symington, et al.      Expires September 15, 2009               [Page 7]

Internet-Draft          Bundle Security Protocol              March 2009

2.  Security Blocks

   There are four types of security block that MAY be included in a
   bundle.  These are the Bundle Authentication Block (BAB), the Payload
   Integrity Block (PIB), the Payload Confidentiality Block (PCB) and
   the Extension Security Block (ESB).

      The BAB is used to assure the authenticity and integrity of the
      bundle along a single hop from forwarder to intermediate receiver.

      The PIB is used to assure the authenticity and integrity of the
      payload from the PIB security-source, which creates the PIB, to
      the PIB security-destination, which verifies the PIB
      authenticator.  The authentication information in the PIB may (if
      the ciphersuite allows) be verified by any node inbetween the PIB
      security-source and the PIB security-destination that has access
      to the cryptographic keys and revocation status information
      required to do so.

      Since a BAB protects a bundle on a "hop-by-hop" basis and a PIB
      protects on a (sort of) "end-to-end" basis, whenever both are
      present the BAB MUST form the "outer" layer of protection - that
      is, the BAB MUST always be calculated and added to the bundle
      after the PIB has been calculated and added to the bundle.

      The PCB indicates that the payload has been encrypted, in whole or
      in part, at the PCB security-source in order to protect the bundle
      content while in transit to the PCB security-destination.

      The ESB provides security for non-payload blocks in a bundle, such
      as metadata.  PIB and PCB protect the payload and are regarded as
      "part of" the payload rather than being "non-payload" blocks.  ESB
      therefore is not applied to PIB or PCBs.

   Each of the security blocks uses the Canonical Bundle Block Format as
   defined in the Bundle Protocol Specification.  That is, each security
   block is comprised of the following elements:

      - Block type code

      - Block processing control flags

      - Block EID reference list (optional)

      - Block data length

      - Block-type-specific data fields

Symington, et al.      Expires September 15, 2009               [Page 8]

Internet-Draft          Bundle Security Protocol              March 2009

   Since the four security blocks have most fields in common, we can
   shorten the description of the Block-type-specific data fields of
   each security block if we first define an abstract security block
   (ASB) and then specify each of the real blocks in terms of the fields
   which are present/absent in an ASB.  Note that no bundle ever
   contains an actual ASB, which is simply a specification artifact.

2.1.  Abstract Security Block

   An ASB consists of the following mandatory and optional fields:

      - Block-type code (one byte) - as in all bundle protocol blocks
      except the primary bundle block.  The block types codes for the
      security blocks are:

         BundleAuthentication Block - BAB: 0x02

         PayloadIntegrity Block - PIB: 0x03

         PayloadConfidentiality Block - PCB: 0x04

         Extension Security Block - ESB: 0x09

      - Block processing control flags (SDNV) - defined as in all bundle
      protocol blocks except the primary bundle block (as described in
      the Bundle Protocol [DTNBP]).  SDNV encoding is described in the
      bundle protocol.  There are no general constraints on the use of
      the block processing flags, and some specific requirements are
      discussed later.

      - EID references - composite field defined in [DTNBP] containing
      references to one or two EIDs.  Presence of the EID-reference
      field is indicated by the setting of the "block contains an EID-
      reference field" (EID_REF) bit of the block processing control
      flags.  If one or more references is present, flags in the
      ciphersuite ID field, described below, specify which.

      If no EID fields are present then the composite field itself is
      omitted entirely, rather than containing a count field of zero,
      since such a representation is not permitted.  The EID_REF bit is
      not set.

      The possible EIDs are:-

Symington, et al.      Expires September 15, 2009               [Page 9]

Internet-Draft          Bundle Security Protocol              March 2009

         - (optional) Security-source - specifies the security source
         for the service.  If this is omitted, then the source of the
         bundle is assumed to be the security-source.

         - (optional) Security-destination - specifies the security
         destination for the service.  If this is omitted, then the
         destination of the bundle is assumed to be the security-
         destination.

      If two EIDs are present, security-source is first and security-
      destination comes second.

      - Block data length (SDNV) - as in all bundle protocol blocks
      except the primary bundle block.  SDNV encoding is described in
      the bundle protocol.

      - Block-type-specific data fields as follows:

         - Ciphersuite ID (SDNV)

         - Ciphersuite flags (SDNV)

         - (optional) Correlator - when more than one related block is
         inserted then this field MUST have the same value in each
         related block instance.  This is encoded as an SDNV.  See note
         in Section 3.8 with regard to correlator values in bundle
         fragments.

         - (optional) Ciphersuite parameters - compound field of next
         two items

            - Ciphersuite parameters length - specifies the length of
            the following Ciphersuite parameters data field and is
            encoded as an SDNV.

            - Ciphersuite parameters data - parameters to be used with
            the ciphersuite in use, e.g. a key identifier or
            initialization vector (IV).  See Section 2.6 for a list of
            potential parameters and their encoding rules.  The
            particular set of parameters that are included in this field
            are defined as part of the ciphersuite specification.

Symington, et al.      Expires September 15, 2009              [Page 10]

Internet-Draft          Bundle Security Protocol              March 2009

         - (optional) Security result - compound field of next two items

            - Security result length - contains the length of the next
            field and is encoded as an SDNV.

            - Security result data - contains the results of the
            appropriate ciphersuite-specific calculation (e.g. a
            signature, MAC or ciphertext block key).

   +----------------+----------------+----------------+----------------+
   | type           |  flags (SDNV)  |  EID ref list(comp)             |
   +----------------+----------------+----------------+----------------+
   | length  (SDNV)                  |  ciphersuite (SDNV)             |
   +----------------+----------------+----------------+----------------+
   | ciphersuite flags (SDNV)        |  correlator  (SDNV)             |
   +----------------+----------------+----------------+----------------+
   |params len(SDNV)| ciphersuite params data                          |
   +----------------+----------------+----------------+----------------+
   |res-len  (SDNV) | security result data                             |
   +----------------+----------------+----------------+----------------+

   The structure of an abstract security block

                                 Figure 2

   Some ciphersuites are specified in Section 4, which also specifies
   the rules which MUST be satisfied by ciphersuite specifications.
   Additional ciphersuites MAY be defined in separate specifications.
   Ciphersuite IDs not specified are reserved.  Implementations of the
   bundle security protocol decide which ciphersuites to support,
   subject to the requirements of section Section 4.  It is RECOMMENDED
   that implementations that allow additional ciphersuites permit
   ciphersuite ID values at least up to and including 127, and they MAY
   decline to allow larger ID values.

   The structure of the ciphersuite flags field is shown in Figure 3.
   In each case the presence of an optional field is indicated by
   setting the value of the corresponding flag to one.  A value of zero
   indicates the corresponding optional field is missing.  Presently
   there are five flags defined for the field and for convenience these
   are shown as they would be extracted from a single-byte SDNV.  Future
   additions may cause the field to grow to the left so, as with the
   flags fields defined in [DTNBP], the description below numbers the
   bit positions from the right rather than the standard RFC definition
   which numbers bits from the left.

Symington, et al.      Expires September 15, 2009              [Page 11]

Internet-Draft          Bundle Security Protocol              March 2009

      src - bit 4 indicates whether the EID-reference field of the ASB
      contains the optional reference to the security-source.

      dest - bit 3 indicates whether the EID-reference field of the ASB
      contains the optional reference to the security-destination.

      parm - bit 2 indicates whether the ciphersuite-parameters-length
      and ciphersuite parameters data fields are present or not.

      corr - bit 1 indicates whether or not the ASB contains an optional
      correlator.

      res - bit 0 indicates whether or not the ASB contains the security
      result length and security result data fields.

      bits 5-6 are reserved for future use.

   Ciphersuite flags
     Bit   Bit   Bit   Bit   Bit   Bit   Bit
      6     5     4     3     2     1     0
   +-----+-----+-----+-----+-----+-----+-----+
   | reserved  |src  |dest |parm |corr |res  |
   +-----+-----+-----+-----+-----+-----+-----+

                                 Figure 3

   A little bit more terminology: if the block is a PIB then when we
   refer to the "PIB-source", we mean the security source for the PIB as
   represented by the EID reference in the EID-references field.
   Similarly we may refer to the PCB-dest, meaning the security-
   destination of the PCB, again as represented by an EID reference.
   For example, referring to Figure 1 again, if the bundle that
   originates at BN1 as source is given a Confidentiality Block (PCB) by
   BN1 that is protected using a key held by BN3 and it is given a
   Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source
   and the PIB-source of the bundle, and BN3 is the PCB-dest of the
   bundle.

   The correlator field is used to associate several related instances
   of a security block.  This can be used to place a BAB that contains
   the ciphersuite information at the "front" of a (probably large)
   bundle, and another correlated BAB that contains the security result
   at the "end" of the bundle.  This allows even very memory-constrained
   nodes to be able to process the bundle and verify the BAB.  There are
   similar use cases for multiple related instances of PIB and PCB as
   will be seen below.

Symington, et al.      Expires September 15, 2009              [Page 12]

Internet-Draft          Bundle Security Protocol              March 2009

   The ciphersuite specification MUST make it clear whether or not
   multiple block instances are allowed, and if so, under what
   conditions.  Some ciphersuites can of course leave flexibility to the
   implementation, whereas others might mandate a fixed number of
   instances.

   For convenience, we use the term "first block" to refer to the
   initial block in a group of correlated blocks, or to the single block
   if there are no others in the set.  Obviously there can be several
   unrelated groups in a bundle, each containing only one block or more
   than one, and each has its own "first block".

2.2.  Bundle Authentication Block

   In this section we describe typical BAB field values for two
   scenarios - where a single instance of the BAB contains all the
   information and where two related instances are used, one "up front"
   which contains the ciphersuite and another following the payload
   which contains the security result (e.g. a MAC).

   For the case where a single BAB is used:

      The block-type code field value MUST be 0x02.

      The block processing control flags value can be set to whatever
      values are required by local policy.

      The ciphersuite ID MUST be documented as a hop-by-hop
      authentication-ciphersuite which requires one instance of the BAB.

      The correlator field MUST NOT be present.

      The ciphersuite parameters field MAY be present, if so specified
      in the ciphersuite specification.

      An EID reference to the security-source SHOULD be present and, if
      so, it MUST identify the forwarder of the bundle.  (If the
      forwarding node is identified in another block of the bundle that
      the next hop supports, e.g., the Previous Hop Insertion Block, the
      forwarding node need not be identified in the BAB.  Similarly, if
      the forwarding node is known through other implementation-specific
      means, such as from the convergence layer, an EID reference need
      not be included.)

      An EID reference to the security-destination SHOULD NOT be present
      unless the ciphersuite requires this information (since the first
      node receiving the bundle ought be the one to validate the BAB).

Symington, et al.      Expires September 15, 2009              [Page 13]

Internet-Draft          Bundle Security Protocol              March 2009

      The security result MUST be present as it is effectively the
      "output" from the ciphersuite calculation (e.g. the MAC or
      signature) applied to the (relevant parts of) the bundle (as
      specified in the ciphersuite definition).

   For the case using two related BAB instances, the first instance is
   as defined above, except the ciphersuite ID MUST be documented as a
   hop-by-hop authentication ciphersuite that requires two instances of
   the BAB.  In addition, the correlator MUST be present and the
   security result length and security result fields MUST be absent.
   The second instance of the BAB MUST have the same correlator value
   present and MUST contain security result length and security result
   data fields.  The other optional fields MUST NOT be present.
   Typically, this second instance of a BAB will be the last block of
   the bundle.

2.3.  Payload Integrity Block

   A PIB is an ASB with the following additional restrictions:

      The block type code value MUST be 0x03.

      The block processing control flags value can be set to whatever
      values are required by local policy.

      The ciphersuite ID MUST be documented as an end-to-end
      authentication-ciphersuite or as an end-to-end error-detection-
      ciphersuite.

      The correlator MUST be present if the ciphersuite requires more
      than one related instance of a PIB be present in the bundle.  The
      correlator MUST NOT be present if the ciphersuite only requires
      one instance of the PIB in the bundle.

      The ciphersuite parameters field MAY be present.

      An EID reference to the security-source MAY be present.

      An EID reference to the security-destination MAY be present.

      The security result is effectively the "output" from the
      ciphersuite calculation (e.g. the MAC or signature) applied to the
      (relevant parts of) the bundle.  As in the case of the BAB, this
      field MUST be present if the correlator is absent.  If more than
      one related instance of the PIB is required then this is handled
      in the same way as described for the BAB above.

Symington, et al.      Expires September 15, 2009              [Page 14]

Internet-Draft          Bundle Security Protocol              March 2009

      The ciphersuite may process less than the entire original bundle
      payload, either because the current payload is a fragment of the
      original bundle or just becuase it is defined to process some
      subset.  For whatever reason, if the ciphersuite processes less
      than the complete, original bundle payload MUST specify, as part
      of the ciphersuite parameters, which bytes of the bundle payload
      are protected.

   For some ciphersuites, (e.g. those using asymmetric keying to produce
   signatures or those using symmetric keying with a group key), the
   security information can be checked at any hop on the way to the
   destination that has access to the required keying information.  This
   possibility is further discussed in Section 3.6 below.

   Most asymmetric PIB-ciphersuites will use the PIB-source to indicate
   the signer and will not require the PIB-dest field because the key
   needed to verify the PIB authenticator will be a public key
   associated with the PIB-source.

2.4.  Payload Confidentiality Block

   A typical confidentiality ciphersuite will encrypt the payload using
   a randomly generated bundle encrypting key (BEK) and will use a PCB
   security parameter to carry the BEK encrypted with some long term key
   encryption key (KEK) or well-known public key.  If neither the
   destination nor security-destination resolves the key to use for
   decryption, the ciphersuite parameters field can be used to indicate
   the decryption key with which the BEK can be recovered.  Subsequent
   PCB security results will contain blocks encrypted using the BEK if
   non-payload blocks are to be encrypted.

   It is STRONGLY RECOMMENDED that a data integrity mechanism be used in
   conjunction with confidentiality, and that encryption-only
   ciphersuites NOT be used.  The "authentication tag" or "integrity
   check value" is stored into security-result rather than being
   appended to the payload as is common in some protocols since, as
   described below, it is important that there be no change in the size
   of the payload.

   The payload is encrypted "in-place", that is, following encryption,
   the payload block payload field contains ciphertext, not plaintext.
   The payload block processing flags are unmodified.

   The "in-place" encryption of payload bytes is to allow bundle payload
   fragmentation and re-assembly, and custody transfer, to operate
   without knowledge of whether or not encryption has occurred and, if
   so, how many times.

Symington, et al.      Expires September 15, 2009              [Page 15]

Internet-Draft          Bundle Security Protocol              March 2009

   Fragmentation and reassembly and custody transfer are adversely
   affected by a change in size of the payload due to ambiguity about
   what byte range of the original payload is actually in any particular
   fragment.  Ciphersuites SHOULD place any payload expansion, such as
   authentication tags (integrity check values) and any padding
   generated by a block-mode cipher, into an "integrity check value"
   item in the security-result field (see Section 2.6) of the
   confidentiality block.

   Payload super-encryption is allowed.  The second application of
   confidentiality does not generally protect the parameters of the
   first which represent a vulnerability in some circumstances.
   Ciphersuites SHOULD define super-encryption such that it protects the
   parameters of earlier encryption.

   Confidentiality can be applied to blocks other than the payload and
   in some cases this is recommended.  The ciphersuite may apply
   different rules to confidentiality for non-payload blocks.

   For example, multiple related PCB instances are required if both the
   payload and the PIBs in the bundle are to be encrypted.  These
   multiple PCB instances require correlators to associate them with
   each other.

   Confidentiality is normally applied to the payload, and possibly to
   additional blocks.  It is RECOMMENDED to apply a Payload
   Confidentiality ciphersuite to non-payload blocks only if these
   should be super-encrypted with the payload.  If super-encryption of
   the block is not desired then protection of the block should be done
   using the Extension Security Block mechanism rather than PCB.

   There are situations where more than one PCB instance is required but
   the instances are not "related" in the sense which requires
   correlators.  One example is where a payload is encrypted for more
   than one security-destination so as to be robust in the face of
   routing uncertainties.  These multiple PCB instances, are not
   "related" and should not contain correlators.

   A PCB is an ASB with the following additional restrictions:

      The block type code value MUST be 0x04.

      The block processing control flags value can be set to whatever
      values are required by local policy, except that a PCB "first
      block" MUST have the "replicate in every fragment" flag set.  This
      flag SHOULD NOT be set otherwise.

Symington, et al.      Expires September 15, 2009              [Page 16]

Internet-Draft          Bundle Security Protocol              March 2009

      The ciphersuite ID MUST be documented as a confidentiality-
      ciphersuite.

      The correlator MUST be present if there is more than one related
      PCB instance.  The correlator MUST NOT be present if there are no
      related PCB instances.

      If a correlator is present, the key information MUST be placed in
      the PCB "first block".

      Any additional bytes generated as a result of encryption and/or
      authentication processing of the payload SHOULD be placed in an
      "integrity check value" field (see Section 2.6) in the security-
      result of the first PCB.

      The ciphersuite parameters field MAY be present.

      An EID reference to the security-source MAY be present.

      An EID reference to the security-destination MAY be present.

      The security result MAY be present and normally contains fields
      such as an encrypted bundle encryption key, authentication tag or
      the encrypted versions of bundle blocks other than the payload
      block.

   As was the case for the BAB and PIB, if the ciphersuite requires more
   than one instance of the PCB, then the "first block" MUST contain any
   optional fields (e.g. security destination etc.) that apply to all
   instances with this correlator.  These MUST be contained in the first
   instance and MUST NOT be repeated in other correlated blocks.  Fields
   that are specific to a particular instance of the PCB MAY appear in
   that PCB.  For example, security result fields MAY (and probably
   will) be included in multiple related PCB instances, with each result
   being specific to that particular block.  Similarly, several PCBs
   might each contain a ciphersuite parameters field with an IV specific
   to that PCB instance.

   Put another way: when confidentiality will generate multiple blocks,
   it MUST first create a PCB with the required ciphersuite ID,
   parameters etc. as specified above.  Typically, this PCB will appear
   "early" in the bundle.  If this "first" PCB doesn't contain all of
   the ciphertext, then it may be followed by other, correlated PCBs
   which MUST NOT repeat the ciphersuite parameters, security-source, or
   security-destination fields from the first PCB.

   PCB ciphersuites MUST specify which blocks are to be encrypted.  The
   specification MAY be flexible and be dependent upon block type,

Symington, et al.      Expires September 15, 2009              [Page 17]

Internet-Draft          Bundle Security Protocol              March 2009

   security policy, various data values and other inputs but it MUST be
   deterministic.  The determination of whether a block is to be
   encrypted or not MUST NOT be ambiguous.

   The ciphersuite may process less than the entire original bundle
   payload, either because the current payload is a fragment of the
   original bundle or just becuase it is defined to process some subset.
   For whatever reason, if the ciphersuite processes less than the
   complete, original bundle payload MUST specify, as part of the
   ciphersuite parameters, which bytes of the bundle payload are
   protected.

   After decryption the recovered plaintext should then replace the PCB
   in the bundle for further processing (e.g.  PIB verification).  This
   recovered plaintext MUST contain all the appropriate block type,
   processing flags and length information.  In other words delete the
   PCB in question and place the recovered plaintext, which consists of
   some complete non-payload block, in the bundle at the location from
   which the PCB was deleted.

   A ciphersuite MUST NOT mix payload data and a non-payload block in a
   single PCB.

   Even if a to-be-encrypted block has the "discard" flag set, whether
   or not the PCB's "discard" flag is set is an implementation/policy
   decision for the encrypting node.  (The "discard" flag is more
   properly called the "discard if block cannot be processed" flag.)

   Any existing eid-list in the to-be-encapsulated original block
   remains exactly as-is, and becomes the eid-list for the replacing
   block.  The encapsulation process MUST NOT replace or remove the
   existing eid-list entries.  This is critically important for correct
   updating of entries at the security-destination.

   At the security-destination, either specific destination or the
   bundle destination, the processes described above are reversed.  The
   payload is decrypted in-place using the salt, IV and key values in
   the first PCB, including verification using the ICV.  These values
   are described below in Section 2.6.  Each correlated PCB is also
   processed at the same destination, using the salt and key values from
   the first PCB and the block-specific IV item.  The "encapsulated
   block" item in security-result is decrypted, and validated using the
   tag which was appended to the ciphertext of the original block data.
   Assuming the validation succeeds, the resultant plaintext, which is
   the entire content of the original block, replaces the PCB at the
   same place in the bundle.  The block type reverts to that of the
   original block prior to encapsulation, and the other block-specific
   data fields also return to their original values.  Implementors are

Symington, et al.      Expires September 15, 2009              [Page 18]

Internet-Draft          Bundle Security Protocol              March 2009

   cautioned that this "replacement" process requires delicate
   stitchery, as the eid-list contents in the decapsulated block are
   invalid.  As noted above, the eid-list references in the original
   block were preserved in the replacing PCB, and will have been updated
   as necessary as the bundle has toured the dtnet.  The references from
   the PCB MUST replace the references within the eid-list of the newly-
   decapsulated block.  Caveat implementor.

2.5.  Extension Security Block

   Extension security blocks provide protection for non-payload portions
   of a bundle.  They MUST NOT be used for the primary block or payload,
   including payload-related security blocks.

   It is sometimes desirable to protect certain parts of a bundle in
   ways other than those applied to the bundle payload.  One such
   example is bundle metadata that might specify the kind of data in the
   payload but not the actual payload detail, as described in [DTNMD].

   ESBs are typically used to apply confidentiality protection.  While
   it is possible to create an integrity-only ciphersuite, the block
   protection is not transparent and makes access to the data more
   difficult.  For simplicity, this discussion describes use of a
   confidentiality ciphersulte.

   The protection mechanisms in ESBs are similar to other security
   blocks with two important differences:

      - different key values are used (using same key as for payload
      would defeat the purpose)

      - the block is not encrypted or super-encrypted with the payload

   A typical ESB ciphersuite will encrypt the payload using a randomly
   generated ephemeral key and will use the security parameters to carry
   the key encrypted with some long term key encryption key (KEK) or
   well-known public key.  If neither the destination nor security-
   destination resolves the key to use for decryption, the ciphersuite
   parameters field can be used to indicate the decryption key with
   which the BEK can be recovered.

   It is STRONGLY RECOMMENDED that a data integrity mechanism be used in
   conjunction with confidentiality, and that encryption-only
   ciphersuites NOT be used.  AES-GCM satisfies this requirement.

   The ESB is placed in the bundle in the same position as the block
   being protected.  That is, the entire original block is processed
   (encrypted etc) and encapsulated in a "replacing" ESB-type block, and

Symington, et al.      Expires September 15, 2009              [Page 19]

Internet-Draft          Bundle Security Protocol              March 2009

   this appears in the bundle at the same sequential position as the
   original block.  The processed data is placed in the security-result
   field.

   The process is reversed at the security destination with the
   recovered plaintext block replacing the ESB that had encapsulated it.
   Processing of EID-list entries, if any, is described above in
   Section 2.4 and this must be followed in order to correctly recover
   EIDs.

   An ESB is an ASB with the following additional restrictions:

   Block type is 0x09.

   Ciphersuite flags indicate which fields are present in this block.

   EID references MUST be stored in the EID reference list.

   Security-source MAY be present.  If not present, then the bundle-
   source is the security-source.

   Security-destination MAY be present.  If not present, then the
   bundle-destination is the security-destination.

   The security-parameters MAY optionally contain a block-type field to
   indicate the type of the encapsulated block.  Since this replicates a
   field in the encrypted portion of the block, it is a slight security
   risk and its use is therefore OPTIONAL.

2.6.  Parameters and Result Fields

   Various ciphersuites include several items in the security-parameters
   and/or security-result fields.  Which items may appear is defined by
   the particular ciphersuite description.  A ciphersuite MAY support
   several instances of the same type within a single block.

   Each item is represented as type-length-value.  Type is a single byte
   indicating which item this is.  Length is the count of data bytes to
   follow, and is an SDNV-encoded integer.  Value is the data content of
   the item.

   Item types are

      0: reserved

      1: initialization vector (IV)

Symington, et al.      Expires September 15, 2009              [Page 20]

Internet-Draft          Bundle Security Protocol              March 2009

      2: reserved

      3: key information

      4: fragment range (offset and length as a pair of SDNVs)

      5: integrity signature

      6: reserved

      7: salt

      8: PCB integrity check value (ICV)

      9: reserved

      10: encapsulated block

      11: block type of encapsulated block

      12 - 191: reserved

      192 - 250: private use

      251 - 255: reserved

   The folowing descriptions apply to usage of these items for all
   ciphersuites.  Additional characteristics are noted in the discussion
   for specific suites.

      - initialization vector(IV): random value, typically eight to
      sixteen bytes

      - key information: key material encoded or protected by the key
      management system, and used to transport an ephemeral key
      protected by a long-term key.  This item is discussed further
      below in Section 2.7

      - fragment range: pair of SDNV values (offset then length)
      specifying the range of payload bytes to which a particular
      operation applies.  This is termed "fragment range" since that is
      its typical use, even though sometimes it may describe a subset
      range that is not a fragment

      - integrity signature: result of BA or PI digest or signing
      operation.  This item is discussed further below in Section 2.7

Symington, et al.      Expires September 15, 2009              [Page 21]

Internet-Draft          Bundle Security Protocol              March 2009

      - salt: an IV-like value used by certain confidentiality suites

      - PCB integrity check value(ICV): output from certain
      confidentiality ciphersuite operations to be used at the
      destination to verify that the protected data has not been
      modified

      - encapsulated block: result of confidentiality operation on
      certain blocks, contains the ciphertext of the block and may also
      contain an integrity check value appended to the ciphertext; may
      also contain padding if required by the encryption mode; used for
      non-payload blocks only

      - block type of encapsulated block: block type code for a block
      that has been encapsulated in ESB

2.7.  Key Transport

   This specification endeavours to maintain separation between the
   security protocol and key management.  However these two interact in
   the transfer of key information etc from security-source to security-
   destination.  The intent of the separation is to facilitate use of a
   variety of key management systems without a necessity to tailor a
   ciphersuite to each individually.

   The key management process deals with such things as long-term keys,
   specifiers for long-term keys, certificates for long-term keys and
   integrity signatures using long-term keys.  The ciphersuite itself
   should not require a knowledge of these, and separation is improved
   if it treats these as opaque entities, to be handled by the key
   management process.

   The key management process deals specifically with the content of two
   of the items defined above in Section 2.6:- key information (item
   type 3) and integrity signature (item type 5).  The content of these
   items MUST be ASN.1-encoded as described in [RFC3852] and related
   RFCs.

   Many situations will require several pieces of key information.
   Ciphersuites MUST accept these packed into a single key-information
   item with ASN.1 encoding and MAY choose to accept them if sent as
   separate items.

2.8.  PIB and PCB combinations

   Given the above definitions, nodes are free to combine applications
   of PIB and PCB in any way they wish - the correlator value allows for
   multiple applications of security services to be handled separately.

Symington, et al.      Expires September 15, 2009              [Page 22]

Internet-Draft          Bundle Security Protocol              March 2009

   Since PIB and PCB apply to the payload and ESB to non-payload blocks,
   combinations of ESB with PIB and/or PCB are not considered.

   There are some obvious security problems that could arise when
   applying multiple services.  For example, if we encrypted a payload
   but left a PIB security result containing a signature in the clear,
   payload guesses could be confirmed.

   We cannot, in general, prevent all such problems since we cannot
   assume that every ciphersuite definition takes account of every other
   ciphersuite definition.  However, we can limit the potential for such
   problems by requiring that any ciphersuite which applies to one
   instance of a PIB or PCB, must be applied to all instances with the
   same correlator.

   We now list the PIB and PCB combinations which we envisage as being
   useful to support:

      Encrypted tunnels - a single bundle may be encrypted many times
      en-route to its destination.  Clearly it must be decrypted an
      equal number of times, but we can imagine each encryption as
      representing the entry into yet another layer of tunnel.  This is
      supported by using multiple instances of PCB, but with the payload
      encrypted multiple times, "in-place".  Depending upon the
      ciphersuite defintion, other blocks can and should be encrypted,
      as discussed above and in Section 2.4 to ensure that parameters
      are protected in the case of super-encryption.

      Multiple parallel authenticators - a single security source might
      wish to protect the integrity of a bundle in multiple ways.  This
      could be required if the bundle's path is unpredictable, and if
      various nodes might be involved as security destinations.
      Similarly, if the security source cannot determine in advance
      which algorithms to use, then using all might be reasonable.  This
      would result in uses of PIB which presumably all protect the
      payload, and which cannot in general protect one another.  Note
      that this logic can also apply to a BAB, if the unpredictable
      routing happens in the convergence layer, so we also envisage
      support for multiple parallel uses of BAB.

      Multiple sequential authenticators - if some security destination
      requires assurance about the route that bundles have taken, then
      it might insist that each forwarding node add its own PIB.  More
      likely, however would be that outbound "bastion" nodes would be
      configured to sign bundles as a way of allowing the sending
      "domain" to take accountability for the bundle.  In this case, the
      various PIBs will likely be layered, so that each protects the
      earlier applications of PIB.

Symington, et al.      Expires September 15, 2009              [Page 23]

Internet-Draft          Bundle Security Protocol              March 2009

      Authenticated and encrypted bundles - a single bundle may require
      both authentication and confidentiality.  Some specifications
      first apply the authenticator and follow this by encrypting the
      payload and authenticator.  As noted previously in the case where
      the authenticator is a signature, there are security reasons for
      this ordering.  (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB
      ciphersuite defined later in Section 4.3.)  Others apply the
      authenticator after encryption, that is, to the ciphertext.  This
      ordering is generally recommended and minimizes attacks which, in
      some cases, can lead to recovery of the encryption key.

   There are no doubt other valid ways to combine PIB and PCB instances,
   but these are the "core" set supported in this specification.  Having
   said that, as will be seen, the standard ciphersuites defined here
   are quite specific and restrictive in terms of limiting the
   flexibility offered by the correlator mechanism.  This is primarily
   in order to keep this specification as simple as possible, while at
   the same time supporting the above scenarios.

Symington, et al.      Expires September 15, 2009              [Page 24]

Internet-Draft          Bundle Security Protocol              March 2009

3.  Security Processing

   This section describes the security aspects of bundle processing.

3.1.  Nodes as policy enforcement points

   All nodes are REQUIRED to have and enforce their own configurable
   security policies, whether these policies be explicit or default, as
   defined in Section 6.

   All nodes serve as Policy Enforcement Points (PEP) insofar as they
   enforce polices that may restrict the permissions of bundle nodes to
   inject traffic into the network.  Policies may apply to traffic
   originating at the current node, traffic terminating at the current
   node and traffic to be forwarded by the current node to other nodes.
   If a particular transmission request, originating either locally or
   remotely, satisfies the node's policy or policies and is therefore
   accepted, then an outbound bundle can be created and dispatched.  If
   not, then in its role as a PEP, the node will not create or forward a
   bundle.  Error handling for such cases is currently considered out of
   scope of this document.

   Policy enforcing code MAY override all other processing steps
   described here and elsewhere in this document.  For example, it is
   valid to implement a node which always attempts to attach a PIB.
   Similarly it is also valid to implement a node which always rejects
   all requests which imply the use of a PIB.

   Nodes MUST consult their security policy to determine the criteria
   that a received bundle ought to meet before it will be forwarded.
   These criteria MUST include a determination of whether or not the
   received bundle must include a valid BAB, PIB or PCB.  If the bundle
   does not meet the node's policy criteria, then the bundle MUST be
   discarded and processed no further; in this case, a bundle status
   report indicating the failure MAY be generated.

   The node's policy MAY call for the node to add or subtract some
   security blocks, for example, requiring the node attempt to encrypt
   (parts of) the bundle for some security-destination, or requiring
   that the node add a PIB.  If the node's policy requires a BAB to be
   added to the bundle, it MUST be added last so that the calculation of
   its security result may take into consideration the values of all
   other blocks in the bundle.

3.2.  Processing order of security blocks

   The processing order of security actions for a bundle is critically
   important for the actions to complete successfully.  In general, the

Symington, et al.      Expires September 15, 2009              [Page 25]

Internet-Draft          Bundle Security Protocol              March 2009

   actions performed at the originating node must be executed in the
   reverse sequence at the destination.  There are variations and
   exceptions, and these are noted below.

   The sequence is maintained in the ordering of security blocks in the
   bundle.  It is for this reason that blocks may not be rearranged at
   forwarding nodes, whether they support the security protocols or not.
   The only blocks that participate in this ordering are the primary and
   payload blocks, and the PIB and PCB security blocks themselves.  All
   other extension blocks, including ESBs, are ignored for purposes of
   determining the processing order.

   The security blocks are added to and removed from a bundle in a last-
   in-first-out (LIFO) manner, with the top of the stack immediately
   after the primary block.  A newly-created bundle has just the primary
   and payload blocks, and the stack is empty.  As security actions are
   requested for the bundle, security blocks are pushed onto the stack
   immediately after the primary block.  The early actions have security
   blocks close to the payload, later actions have blocks nearer to the
   primary block.  The actions deal with only those blocks in the bundle
   at the time so, for example, the first to be added processes only the
   payload and primary blocks, the next might process the first if it
   chooses and the payload and primary, and so on.  The last block to be
   added can process all the blocks.

   When the bundle is received, this process is reversed and security
   processing begins at the top of the stack, immediately after the
   primary block.  The security actions are performed and the block is
   popped from the stack.  Processing continues with the next security
   block until finally only the payload and primary blocks remain.

   The simplicity of this description is undermined by various real-
   world requirements.  Nonetheless it serves as a helpful initial
   framework for understanding the bundle security process.

   The first issue is a very common one and easy to handle.  The bundle
   may be sent indirectly to its destination, requiring several
   forwarding hops to finally arrive there.  Security processing happens
   at each node, assuming that the node supports bundle security.  For
   the following discussion, we assume that a bundle is created and that
   confidentiality, then payload integrity and finally bundle
   authentication are applied to it.  The block sequence would therefore
   be primary-BAB-PIB-PCB-payload.  Traveling from source to destination
   requires going through one intermediate node, so the trip consists of
   two hops.

   When the bundle is received at the intermediate node, the receive
   processing validates the BA block and pops it from the stack.

Symington, et al.      Expires September 15, 2009              [Page 26]

Internet-Draft          Bundle Security Protocol              March 2009

   However the PIBs and PCBs have the final destination as their
   security destination, so these can't be processed and removed.  The
   intermediate node then begins the send process with the four
   remaining blocks in the bundle.  The outbound processing adds any
   security blocks required by local policy, and these are pushed on the
   stack immediately after the primary block, ahead of the PIB.  In this
   example, the intermediate node adds a PIB as a signature that the
   bundle has passed through the node.

   The receive processing at the destination first handles the
   intermediate node's PIB and pops it, next is the originator's PIB,
   also popped, and finally the originator's confidentiality block which
   allows the payload to be decrypted and the bundle handled for
   delivery.

   This simple scheme can easily be extended to very complex networks.
   It cannot deal with security zones that overlap partially but not
   completely and these are discussed further below in Section 3.3.
   Administrators SHOULD NOT configure security-sources and security-
   destinations in a network such that overlapping security zones are
   created.

   The second issue relates to the reversibility of certain security
   process actions.  In general, the actions fall into two categories:
   those which do not affect other parts of the bundle, and those which
   are fully reversible.  Creating a bundle signature, for example, does
   not change the bundle content except for the result.  The encryption
   performed as part of the confidentiality processing does change the
   bundle, but the reverse processing at the destination restores the
   original content.

   The third category is the one where the bundle content has changed
   slightly and in a non-destructive way, but there is no mechanism to
   reverse the change.  The simplest example is the addition of an EID-
   reference to a security block.  The addition of the reference causes
   the text to be added to the bundle's dictionary.  The text may be
   used also by other references so removal of the block and this
   specific eid-reference does not cause removal of the text from the
   dictionary.  This shortcoming is of no impact to the "sequential" or
   "wrapping" security schemes described above, but does cause failures
   with "parallel" authentication mechanisms.  Solutions for this
   problem are implementation-specific and typically involve multi-pass
   processing such that blocks are added at one stage and the security
   results calculated at a later stage of the overall process.

   Certain ciphersuites have sequence requirements for their correct
   operation, most notably the BundleAuthentication ciphersuites.
   Processing for BundleAuthentication is required to happen after all

Symington, et al.      Expires September 15, 2009              [Page 27]

Internet-Draft          Bundle Security Protocol              March 2009

   other sending operations, and prior to any receive operations at the
   next hop node.  It follows therefore that BA blocks must always be
   pushed onto the stack after all others.

   Although we describe the security block list as a stack, there are
   some blocks which are placed after the payload and therefore are not
   part of the stack.  The BundleAuthentication ciphersuite #1 ("BA1")
   requires a second, correlated block to contain the security-result
   and this block is placed after the payload, usually as the last block
   in the bundle.  We can apply the stack rules even to these blocks by
   specifying that they be added to the end of the bundle at the same
   time that their "owner" or "parent" block is pushed on the stack.  In
   fact, they form a stack beginning at the payload but growing in the
   other direction.  Also, not all blocks in the main stack have a
   corresponding entry in the trailing stack.  The only blocks which
   MUST follow the payload are those mandated by ciphersuites as
   correlated blocks for holding a security-result.  No other blocks are
   required to follow the payload block and it is RECOMMENDED that they
   NOT do so.

   ESBs are effectively placeholders for the blocks they encapsulate
   and, since those do not form part of the processing sequence
   described above, ESBs themselves do not either.  ESBs may be
   correlated, however, so the "no reordering" requirement applies to
   them as well.

3.3.  Security Zones

   Each security block has a security zone, as described in the
   discussion for Figure 1, and the zones for various blocks are often
   different.

   BA blocks are always for a single hop and these restricted zones
   never cause conflict.

   The zones for PIBs and PCBs are often from bundle source to bundle
   destination, to provide end-to-end protection.  A bundle-source-to-
   bundle-destination zone likewise never causes a problem.

   Another common scenario is for gateway-to-gateway protection of
   traffic between two sub-networks.

   Looking at Figure 1 and the simplified version shown in Figure 4, we
   can regard BN2 and BN3 as gateways connecting the two subnetworks
   labeled "An Internet".  As long as they provide security for the BN2-
   BN3 zone, all is well.  Problems begin, for example, when BN2 adds
   blocks with BN4 as the security-destination, and originating node BN1
   has created blocks with BN3 as security-destination.  We now have two

Symington, et al.      Expires September 15, 2009              [Page 28]

Internet-Draft          Bundle Security Protocol              March 2009

   zones and neither is a subset of the other.

   +---------v-|   +->>>>>>>>>>v-+     +->>>>>>>>>>v-+   +-^---------+
   | BN1     v |   | ^   BN2   v |     | ^   BN3   v |   | ^  BN4    |
   +---------v-+   +-^---------v-+     +-^---------v-+   +-^---------+
             >>>>>>>>^         >>>>>>>>>>^         >>>>>>>>^

    <-------------  BN1 to BN3 zone  ------------>

                       <-------------  BN2 to BN4 zone  ------------>

   Overlapping security zones

                                 Figure 4

   Consider the case where the security concern is for data integrity,
   so the blocks are PayloadIntegrity.  BN1 creates one ("PIa") along
   with the new bundle, and BN2 pushes its own PIB "PIb" on the stack,
   with security-destination BN4.  When this bundle arrives at BN3, the
   bundle blocks are

   primary - PIb - PIa - payload

   Block PIb is not destined for this node BN3 so must be forwarded.
   This is the security-destination for block PIa so, after validation,
   it should be removed from the bundle.  But that will invalidate the
   PIb signature when the block is checked at the final destination.
   The PIb signature includes the primary block, PIb itself, PIa and the
   payload block, so PIa MUST remain in the bundle.  This is why
   security blocks are treated as a stack and add/remove operations are
   permitted only at the top-of-stack.

   The situation would be worse if the security concern is
   confidentiality, so PCBs are employed, such as the confidentiality
   ciphersuite #3 ("PC3") described in Section 4.3.  In this scenario,
   BN1 would encrypt the bundle with BN3 as security-destination, BN2
   would super-encrypt the payload and encapsulate the PC3 block for
   security-destination BN4.  BN3 forwards all the blocks without
   change.  BN4 decrypts the payload from its super-encryption and
   decapsulates the PC3 block, only to find that it should have been
   processed earlier.  Assuming that BN4 has no access to BN3's key
   store, BN4 has no way to decrypt the bundle and recover the original
   content.

Symington, et al.      Expires September 15, 2009              [Page 29]

Internet-Draft          Bundle Security Protocol              March 2009

3.4.  Canonicalisation of bundles

   In order to verify a signature or MAC on a bundle the exact same
   bits, in the exact same order, must be input to the calculation upon
   verification as were input upon initial computation of the original
   signature or MAC value.  Consequently, a node MUST NOT change the
   encoding of any URI in the dictionary field, e.g., changing the DNS
   part of some HTTP URL from lower case to upper case.  Because bundles
   may be modified while in transit (either correctly or due to
   implementation errors), a canonical form of any given bundle (that
   contains a BAB or PIB) must be defined.

   This section defines two bundle canonicalisation algorithms which can
   be used by various ciphersuites.

3.4.1.  Strict canonicalisation

   The first algorithm that can be used permits no changes at all to the
   bundle between the security-source and the security-destination.  It
   is mainly intended for use in BAB ciphersuites.  This algorithm
   conceptually catenates all blocks in the order presented, but omits
   all security result data fields in blocks of this ciphersuite type.
   That is, when a BA ciphersuite specifies this algorithm then we omit
   all BAB security results for all BA ciphersuites, when a PIB
   ciphersuite specifies this algorithm then we omit all PIB security
   results for all PI ciphersuites.  All security result length fields
   are included, even though their corresponding security result data
   fields are omitted.

   Notes:

      - In the above we specify that security result data is omitted.
      This means that no bytes of the security result data are input.
      We do not set the security result length to zero.  Rather, we
      assume that the security result length will be known to the module
      that implements the ciphersuite before the security result is
      calculated, and require that this value be in the security result
      length field even though the security result data itself will be
      omitted.

      - The 'res' bit of the ciphersuite ID, which indicates whether or
      not the security result length and security result data field are
      present, is part of the canonical form.

      -The value of the block data length field, which indicates the
      length of the block, is also part of the canonical form.  Its
      value indicates the length of the entire bundle when the bundle
      includes the security result data field.

Symington, et al.      Expires September 15, 2009              [Page 30]

Internet-Draft          Bundle Security Protocol              March 2009

      -BABs are always added to bundles after PIBs, so when a PIB
      ciphersuite specifies this strict canonicalisation algorithm and
      the PIB is received with a bundle that also includes one or more
      BABs, application of strict canonicalisation as part of the PIB
      security result verification process requires that all BABs in the
      bundle be ignored entirely.

3.4.2.  Mutable canonicalisation

   This algorithm is intended to protect parts of the bundle which
   should not be changed in-transit.  Hence it omits the mutable parts
   of the bundle.

   The basic approach is to define a canonical form of the primary block
   and catenate it with the security and payload blocks in the order
   that they will be transmitted.  This algorithm ignores all other
   blocks because it cannot be determined whether or not they will
   change as the bundle transits the network.

   Many fields in various blocks are stored as variable-length SDNVs.
   These are canonicalized in unpacked form, as eight-byte fixed-width
   fields in network byte order.  The size of eight bytes is chosen
   because implementations may handle larger values as invalid, as noted
   in [DTNBP].

   The canonical form of the primary block is shown in Figure 5.
   Essentially, it de-references the dictionary block, adjusts lengths
   where necessary and ignores flags that may change in transit.

Symington, et al.      Expires September 15, 2009              [Page 31]

Internet-Draft          Bundle Security Protocol              March 2009

   +----------------+----------------+----------------+----------------+
   |    Version     |      Processing flags (incl. COS and  SRR)       |
   +----------------+----------------+---------------------------------+
   |                Canonical primary block length                     |
   +----------------+----------------+---------------------------------+
   |                Destination endpoint ID length                     |
   +----------------+----------------+---------------------------------+
   |                                                                   |
   |                      Destination endpoint ID                      |
   |                                                                   |
   +----------------+----------------+---------------------------------+
   |                    Source endpoint ID length                      |
   +----------------+----------------+----------------+----------------+
   |                                                                   |
   |                        Source endpoint ID                         |
   |                                                                   |
   +----------------+----------------+---------------------------------+
   |                  Report-to endpoint ID length                     |
   +----------------+----------------+----------------+----------------+
   |                                                                   |
   |                      Report-to endpoint ID                        |
   |                                                                   |
   +----------------+----------------+----------------+----------------+
   |                                                                   |
   +                    Creation Timestamp (2 x SDNV)                  +
   |                                                                   |
   +---------------------------------+---------------------------------+
   |                             Lifetime                              |
   +----------------+----------------+----------------+----------------+

   The canonical form of the primary bundle block.

                                 Figure 5

   The fields shown in Figure 5 are:

      Version is the single-byte value in the primary block.

      Processing flags in the primary block is an SDNV, and includes the
      class-of-service (COS) and status report request (SRR) fields.
      For purposes of canonicalization, the SDNV is unpacked into a
      fixed-width field and some bits are masked out.  The unpacked
      field is ANDed with mask 0x0000 0000 003E 031F to set to zero all
      reserved bits and the "bundle is a fragment" bit.

      Length - a four-byte value containing the length (in bytes) of
      this structure, in network byte order.

Symington, et al.      Expires September 15, 2009              [Page 32]

Internet-Draft          Bundle Security Protocol              March 2009

      Destination endpoint ID length and value - are the length (as a
      four byte value in network byte order) and value of the
      destination endpoint ID from the primary bundle block.  The URI is
      simply copied from the relevant part(s) of the dictionary block
      and is not itself canonicalised.  Although the dictionary entries
      contain null-terminators, the null-terminators are not included in
      the length or the canonicalization.

      Source endpoint ID length and value are handled similarly to the
      destination.

      Report-to endpoint ID length and value are handled similarly to
      the destination.

      Creation time (2 x SDNV) and Lifetime (SDNV) are simply copied
      from the primary block, with the SDNV values being represented as
      eight-byte unpacked values.

      Fragment offset and Total application data unit length are
      ignored, as is the case for the "bundle is a fragment" bit
      mentioned above.  If the payload data to be canonicalized is less
      than the complete, original bundle payload, the offset and length
      are specified in the security-parameters.

   For non-primary blocks being included in the canonicalization, the
   block processing flags value used for canonicalization is the
   unpacked SDNV value with reserved and mutable bits masked to zero.
   The unpacked value is ANDed with mask 0x0000 0000 0000 0057 to zero
   reserved bits and the "last block" flag.  The "last block" flag is
   ignored because BABs and other security blocks may be added for some
   parts of the journey but not others so the setting of this bit might
   change from hop to hop.

   Endpoint ID references in security blocks are canonicalized using the
   de-referenced text form in place of the reference pair.  The
   reference count is not included, nor is the length of the endpoint ID
   text.

   The block-length is canonicalized as an eight-byte unpacked value in
   network byte order.  If the payload data to be canonicalized is less
   than the complete, original bundle payload, this field contain the
   size of the data being canonicalized (the "effective block") rather
   that the actual size of the block.

   Payload blocks are generally canonicalized as-is with the exception
   that in some instances only a portion of the payload data is to be
   protected.  In such a case, only those bytes are included in the
   canonical form, and additional ciphersuite parameters are required to

Symington, et al.      Expires September 15, 2009              [Page 33]

Internet-Draft          Bundle Security Protocol              March 2009

   specify which part of the payload is protected, as discussed further
   below.

   Security blocks are handled likewise, except that the ciphersuite
   will likely specify that the "current" security block security result
   field not be considered part of the canonical form.  This differs
   from the strict canonicalisation case since we might use the mutable
   canonicalisation algorithm to handle sequential signatures such that
   signatures cover earlier ones.

   ESBs MUST NOT be included in the canonicalization.

   Notes:

      - The canonical form of the bundle is not transmitted.  It is
      simply an artifact used as input to digesting.

      - We omit the reserved flags because we cannot determine if they
      will change in transit.  The masks specified above may have to be
      revised if additional flags are defined and they need to be
      protected.

      - Our URI encoding does not preserve the "null-termination"
      convention from the dictionary field, nor do we separate the
      scheme and ssp as is done there.

      - The URI encoding will cause errors if any node rewrites the
      dictionary content (e.g. changing the DNS part of an HTTP URL from
      lower-case to upper case).  This could happen transparently when a
      bundle is synched to disk using one set of software and then read
      from disk and forwarded by a second set of software.  Because
      there are no general rules for canonicalising URIs (or IRIs), this
      problem may be an unavoidable source of integrity failures.

      - All SDNV fields here are canonicalized as eight-byte unpacked
      values in network byte order.  Length fields are canonicalized as
      four-byte values in network byte order.  Encoding does not need
      optimization since the values are never sent over the network.

      If a bundle is fragmented before the PIB is applied then the PIB
      applies to a fragment and not the entire bundle.  However, the
      protected fragment could be subsequently further fragmented, which
      would leave the verifier unable to know which bytes were protected
      by the PIB.  Even in the absence of frgmentation the same
      situation applies if the ciphersuite is defined to allow
      protection of less than the entire, original bundle payload.

Symington, et al.      Expires September 15, 2009              [Page 34]

Internet-Draft          Bundle Security Protocol              March 2009

      For this reason, PIB ciphersuites which support applying a PIB to
      less than the complete, original bundle payload MUST specify, as
      part of the ciphersuite parameters, which bytes of the bundle
      payload are protected.  When verification occurs, only the
      specified range of the payload bytes are input to PIB
      verification.  It is valid for a ciphersuite to be specified so as
      to only apply to entire bundles and not to fragments.  A
      ciphersuite may be specified to apply to only a portion of the
      payload, regardless of whether the payload is a fragment or the
      complete original bundle payload.

      The same fragmentation issue applies equally to PCB ciphersuites.
      Ciphersuites which support applying confidentiality to fragments
      MUST specify, as part of the ciphersuite parameters, which bytes
      of the bundle payload are protected.  When decrypting a fragment,
      only the specified bytes are processed.  It is also valid for a
      confidentiality ciphersuite to be specified so as to only apply to
      entire bundles and not to fragments.

   This definition of mutable canonicalization assumes that endpoint IDs
   themselves are immutable and is unsuitable for use in environments
   where that assumption might be violated.

   Since the canonicalization applies to a specific bundle rather than a
   payload, an originator's signature cannot be verified if a payload is
   forwarded, as the forwarded bundle will have a different source.

   The solution for either of these issues is to use a PIB ciphersuite
   having an alternate version of mutable canonicalization that does not
   include any fields from the primary block.

3.5.  Endpoint ID confidentiality

   Every bundle MUST contain a primary block that contains the source
   and destinations endpoint IDs, and others, and that cannot be
   encrypted.  If endpoint ID confidentiality is required, then bundle-
   in-bundle encapsulation may solve this problem in some instances.

   Similarly, confidentiality requirements may also apply to other parts
   of the primary block (e.g. the current-custodian) and that is
   supported in the same manner.

3.6.  Bundles received from other nodes

   Nodes implementing this specification SHALL consult their security
   policy to determine whether or not a received bundle is required by
   policy to include a BAB.  If the bundle has no BAB and one is not
   required then BAB processing on the received bundle is complete and

Symington, et al.      Expires September 15, 2009              [Page 35]

Internet-Draft          Bundle Security Protocol              March 2009

   the bundle is ready to be further processed for PCB/PIB handling or
   delivery or forwarding.

   If the bundle is required to have a BAB but does not, then the bundle
   MUST be discarded and processed no further.  If the bundle is
   required to have a BAB but all of its BABs identify a different node
   other than the receiving node as the BAB security destination, then
   the bundle MUST be discarded and processed no further.

   If the bundle has one or more BABs that identify the receiving node
   as the BAB security destination, or for which there is no security
   destination, then the value in the security result field(s) of the
   BAB(s) MUST be verified according to the ciphersuite specification.
   If for all such BABs in the bundle either the BAB security source
   cannot be determined or the security result value check fails, the
   bundle has failed to authenticate and the bundle MUST be discarded
   and processed no further.  Otherwise, if any of the BABs present
   verify, the bundle is ready for further processing as determined by
   extension blocks and/or policy.

   BABs received in a bundle MUST be stripped before the bundle is
   forwarded.  New BABs MAY be added as required by policy.  This may
   require correcting the "last block" field of the to-be-forwarded
   bundle.

   Further processing of the bundle must take place in the order
   indicated by the various blocks from the primary block to the payload
   block, except as defined by an applicable specification.

   If the bundle has a PCB and the receiving node is the PCB destination
   for the bundle (either because the node is listed as the bundle's
   PCB-dest or because the node is listed as the bundle's destination
   and there is no PCB-dest), the node MUST decrypt the relevant parts
   of the bundle in accordce with the ciphersuite specification.  The
   PCB SHALL be deleted.  If the relevant parts of the bundle cannot be
   decrypted (i.e. the decryption key cannot be deduced or decryption
   fails), then the bundle MUST be discarded and processed no further;
   in this case a bundle deletion status report (see the Bundle Protocol
   [DTNBP]) indicating the decryption failure MAY be generated.  If the
   PCB security result included the ciphertext of a block other than the
   payload block, the recovered plaintext block MUST be placed in the
   bundle at the location from which the PCB was deleted.

   If the bundle has one or more PIBs for which the receiving node is
   the bundle's PIB destination (either because the node is listed in
   the bundle's PIB-dest or because the node is listed as the bundle's
   destination and there is no PIB-dest), the node MUST verify the value
   in the PIB security result field(s) in accordance with the

Symington, et al.      Expires September 15, 2009              [Page 36]

Internet-Draft          Bundle Security Protocol              March 2009

   ciphersuite specification.  If all the checks fail, the bundle has
   failed to authenticate and the bundle SHALL be processed according to
   the security policy.  A bundle status report indicating the failure
   MAY be generated.  Otherwise, if the PIB verifies, the bundle is
   ready to be processed for either delivery or forwarding.  Before
   forwarding the bundle, the node SHOULD remove the PIB from the
   bundle, subject to the requirements of Section 3.2, unless it is
   likely that some downstream node will also be able to verify the PIB.

   If the bundle has a PIB and the receiving node is not the bundle's
   PIB-dest the receiving node MAY attempt to verify the value in the
   security result field.  If it is able to check and the check fails,
   the node SHALL discard the bundle and it MAY send a bundle status
   report indicating the failure.

   If the bundle has an ESB and the receiving node is the ESB
   destination for the bundle (either because the node is listed as the
   bundle's ESB-dest or because the node is listed as the bundle's
   destination and there is no ESB-dest), the node MUST decrypt and/or
   decapsulate the encapsulated block in accordance with the ciphersuite
   specification.  The decapsulated block replaces the ESB in the bundle
   block sequence, and the ESB is thereby deleted.  If the content
   cannot be decrypted (i.e., the decryption key cannot be deduced or
   decryption fails), then the bundle MUST be discarded and processed no
   further unless the security policy specifies otherwise.  In this case
   a bundle deletion status report (see the Bundle Protocol [DTNBP])
   indicating the decryption failure MAY be generated.

3.7.  The At-Most-Once-Delivery Option

   An application may request (in an implementation specific manner)
   that a node be registered as a member of an endpoint and that
   received bundles destined for that endpoint be delivered to that
   application.

   An option for use in such cases is known as "at-most-once-delivery".
   If this option is chosen, the application indicates that it wants the
   node to check for duplicate bundles, discard duplicates, and deliver
   at most one copy of each received bundle to the application.  If this
   option is not chosen, the application indicates that it wants the
   node to deliver all received bundle copies to the application.  If
   this option is chosen, the node SHALL deliver at most one copy of
   each received bundle to the application.  If the option is not
   chosen, the node SHOULD, subject to policy, deliver all bundles.

   To enforce this the node MUST look at the source/timestamp pair value
   of each complete (reassembled, if necessary) bundle received and
   determine if this pair, which uniquely identifies a bundle, has been

Symington, et al.      Expires September 15, 2009              [Page 37]

Internet-Draft          Bundle Security Protocol              March 2009

   previously received.  If it has, then the bundle is a duplicate.  If
   it has not, then the bundle is not a duplicate.  The source/timestamp
   pair SHALL be added to the list of pair values already received by
   that node.

   Each node implementation may decide how long to maintain a table of
   pair value state.

   Additional discussion relevant to at-most-delivery is in the DTN
   Retransmission Block specification [DTNRB].

3.8.  Bundle Fragmentation and Reassembly

   If it is necessary for a node to fragment a bundle and security
   services have been applied to that bundle, the fragmentation rules
   described in [DTNBP] MUST be followed.  As defined there and repeated
   here for completeness, only the payload may be fragmented; security
   blocks, like all extension blocks, can never be fragmented.  In
   addition, the following security-specific processing is REQUIRED:

   The security policy requirements for a bundle must be applied
   individually to all the bundles resulting from a fragmentation event.

   If the original bundle contained a PIB, then each of the PIB
   instances MUST be included in some fragment.

   If the original bundle contained one or more PCBs, then any PCB
   instances containing a key information item MUST have the "replicate
   in every fragment" flag set, and thereby be replicated in every
   fragment.  This is to ensure that the canonical block-sequence can be
   recovered during reassembly.

   If the original bundle contained one or more correlated PCBs not
   containing a key information item, then each of these MUST be
   included in some fragment, but SHOULD NOT be sent more than once.
   They MUST be placed in a fragment in accordance with the
   fragmentation rules described in [DTNBP].

   Note: various fragments may have additional security blocks added at
   this or later stages and it is possible that correlators may collide.
   In order to facilitate uniqueness, ciphersuites SHOULD include the
   fragment-offset of the fragment as a high-order component of the
   correlator.

3.9.  Reactive fragmentation

   When a partial bundle has been received, the receiving node SHALL
   consult its security policy to determine if it may fragment the

Symington, et al.      Expires September 15, 2009              [Page 38]

Internet-Draft          Bundle Security Protocol              March 2009

   bundle, converting the received portion into a bundle fragment for
   further forwarding.  Whether or not reactive fragmentation is
   permitted SHALL depend on the security policy and the ciphersuite
   used to calculate the BAB authentication information, if required.
   (Some BAB ciphersuites, i.e., the standard BAB-HMAC ciphersuite
   defined in Section 4.1, do not accommodate reactive fragmentation
   because the security result in the BAB requires that the entire
   bundle be signed.  It is conceivable, however, that a BAB ciphersuite
   could be defined such that multiple security results are calculated,
   each on a different segment of a bundle, and that these security
   results could be interspersed between bundle payload segments such
   that reactive fragmentation could be accommodated.)

   If the bundle is reactively fragmented by the intermediate receiver
   and the BAB-ciphersuite is of an appropriate type (e.g. with multiple
   security results embedded in the payload), the bundle MUST be
   fragmented immediately after the last security result value in the
   partial payload that is received.  Any data received after the last
   security result value MUST be dropped.

   If a partial bundle is received at the intermediate receiver and is
   reactively fragmented and forwarded, only the part of the bundle that
   was not received MUST be retransmitted, though more of the bundle MAY
   be retransmitted.  Before retransmitting a portion of the bundle, it
   SHALL be changed into a fragment and, if the original bundle included
   a BAB, the fragmented bundle MUST also, and its BAB SHALL be
   recalculated.

   This specification does not currently define any ciphersuite which
   can handle this reactive fragmentation case.

   An interesting possibility is a ciphersuite definition such that the
   transmission of a follow-up fragment would be accompanied by the
   signature for the payload up to the restart point.

Symington, et al.      Expires September 15, 2009              [Page 39]

Internet-Draft          Bundle Security Protocol              March 2009

4.  Standard Ciphersuites

   This section defines the standard ciphersuites for this
   specification.  There is currently one standard ciphersuite for use
   with each of the security block types BAB, PIB, PCB and ECB.  The BAB
   ciphersuite is based on shared secrets using HMAC.  The PIB
   ciphersuite is based on digital signatures using RSA with SHA256.
   The PCB and ESB ciphersuites are based on using RSA for key transport
   and AES for bulk encryption.

4.1.  BAB-HMAC

   The BAB-HMAC ciphersuite has ciphersuite ID value 0x001.

   Security parameters are optional with this scheme, but if used then
   the only field that can be present is key information (see
   Section 2.6).  The exact type of key information to be used is an
   implementation issue.  In the absence of key information the receiver
   is expected to be able to find the correct key based on the sending
   identity.  The sending identity may be known from the security-source
   field or the content of a previous-hop block in the bundle.  It may
   also be determined using implementation-specific means such as the
   convergence layer.

   BAB-HMAC uses the strict canonicalisation algorithm in Section 3.4.1.

   Strict canonicalization supports digesting of a fragment-bundle.  It
   does not permit the digesting of only a subset of the payload, but
   only the complete contents of the payload of the current bundle,
   which might be a fragment.  The "fragment range" item for security-
   parameters is not used to indicate a fragment, as this information is
   digested within the primary block.

   The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104].

   This ciphersuite requires the use of two related instances of the
   BAB.  It involves placing the first BAB instance (as defined in
   Section 2.2) just after the primary block.  The second (correlated)
   instance of the BAB MUST be placed after all other blocks (except
   possibly other BAB blocks) in the bundle.

   This means that normally, the BAB will be the second and last blocks
   of the bundle.  If a forwarder wishes to apply more than one
   correlated BAB pair, then this can be done.  There is no requirement
   that each application "wrap" the others, but the forwarder MUST
   insert all the "up front" BABs, and their "at back" "partners"
   (without any security result), before canonicalising.

Symington, et al.      Expires September 15, 2009              [Page 40]

Internet-Draft          Bundle Security Protocol              March 2009

   Inserting more than one correlated BAB pair would be useful if the
   bundle could be routed to more than one potential "next-hop" or if
   both an old or a new key were valid at sending time, with no
   certainty about the situation that will obtain at reception time.

   The security result is the output of the HMAC-SHA1 calculation with
   input being the result of running the entire bundle through the
   strict canonicalisation algorithm.  Both required BAB instances MUST
   be included in the bundle before canonicalisation.

4.2.  PIB-RSA-SHA256

   The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02.

   If the bundle being signed has been fragmented before signing, then
   we have to specify which bytes were signed in case the signed bundle
   is subsequently fragmented for a second time.  If the bundle is a
   fragment, then the ciphersuite parameters MUST include a fragment-
   range field, as described in Section 2.6, specifying the offset and
   length of the signed fragment.  If the entire bundle is signed then
   these numbers MUST be omitted.

   The ciphersuite parameters field MAY also contain a key information
   item.  The exact type of key information to be used is an
   implementation issue.  In the absence of a key identifier, the
   verifier of the PIB is expected to be able to use the security source
   (if supplied) or else the bundle source (if no security source is
   present) in order to determine the correct public key to use for PIB
   verification.

   PIB-RSA-SHA256 uses the mutable canonicalisation algorithm
   Section 3.4.2, with the security-result data field for only the
   "current" block being excluded from the canonical form.  The
   resulting canonical form of the bundle is the input to the signing
   process.  This ciphersuite requires the use of a single instance of
   the PIB.

   RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
   signature scheme in [RFC4055].  The output of the signing process is
   the security result item for the PIB.

   "Commensurate strength" cryptography is generally held to be a good
   idea.  A combination of RSA with SHA256 is reckoned to require a 3076
   bit RSA key according to this logic.  Few implementations will choose
   this length by default (and probably some just won't support such
   long keys).  Since this is an experimental protocol, we expect that
   1024 or 2048 bit RSA keys will be used in many cases, and that that
   will be fine since we also expect that the hash function "issues"

Symington, et al.      Expires September 15, 2009              [Page 41]

Internet-Draft          Bundle Security Protocol              March 2009

   will be resolved before any standard would be derived from this
   protocol.

4.3.  PCB-RSA-AES128-PAYLOAD-PIB-PCB

   The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID
   value 0x003.

   This scheme encrypts PIBs, PCBs and the payload.  The key size for
   this ciphersuite is 128 bits.

   Encryption is done using the AES algorithm in Galois/Counter Mode
   (GCM) as described in [RFC5084] [Note: parts of the following
   description are borrowed from RFC 4106].

   The choice of GCM avoids expansion of the payload, which causes
   problems with fragmentation/reassembly and custody transfer.  GCM
   also includes authentication, essential in preventing attacks that
   can alter the decrypted plaintext or even recover the encryption key.

   GCM is a block cipher mode of operation providing both
   confidentiality and data origin authentication.  The GCM
   authenticated encryption operation has four inputs: a secret key, an
   initialization vector (IV), a plaintext, and an input for additional
   authenticated data (AAD) which is not used here.  It has two outputs,
   a ciphertext whose length is identical to the plaintext, and an
   authentication tag, also known as the Integrity Check Value (ICV).

   For consistency with the description in [RFC5084], we refer to the
   GCM IV as a nonce.  The same key and nonce combination MUST NOT be
   used more than once.  The nonce has the following layout

   +----------------+----------------+---------------------------------+
   |                               salt                                |
   +----------------+----------------+---------------------------------+
   |                                                                   |
   |                      initialization vector                        |
   |                                                                   |
   +----------------+----------------+---------------------------------+

   Nonce format.

                                 Figure 6

   The salt field is a four-octet value, usually chosen at random.  It
   MUST be the same for all PCBs which have the same correlator value.
   The salt need not be kept secret.

Symington, et al.      Expires September 15, 2009              [Page 42]

Internet-Draft          Bundle Security Protocol              March 2009

   The initialization vector (IV) is an eight-octet value, usually
   chosen at random.  It MUST be different for all PCBs which have the
   same correlator value.  The value need not be kept secret.

   The key (bundle encryption key, BEK) is a sixteen-octet (128 bits)
   value, usually chosen at random.  The value MUST be kept secret, as
   described below.

   The integrity check value is a sixteen-octet value used to verify
   that the protected data has not been altered.  The value need not be
   kept secret.

   This ciphersuite requires the use of a single PCB instance to deal
   with payload confidentiality.  If the bundle already contains PIBs or
   PCBs then the ciphersuite will create additional correlated blocks to
   protect these PIBs and PCBs.  These "additional" blocks replace the
   original blocks on a one-for-one basis, so the number of blocks
   remains unchanged.  All these related blocks MUST have the same
   correlator value.  The term "first PCB" in this section refers to the
   single PCB if there is only one or, if there are several, then to the
   one containing the key information.  This MUST be the first of the
   set.

   First PCB - the first PCB may contain a correlator value, and may
   specify security-source and/or security-destination in the eid-list.
   If not specified, the bundle-source and bundle-destination
   respectively are used for these values, as with other ciphersuites.
   The block MUST contain security-parameters and security-result
   fields.  Each field may contain several items formatted as described
   in Section 2.6.

   Security-parameters

      key information

      salt

      IV (this instance applies only to payload)

      fragment offset and length, if bundle is a fragment

   Security-result

      ICV

   Subsequent PCBs MUST contain a correlator value to link them to the
   first PCB.  Security-source and security-destination are implied from
   the first PCB, however see the discussion in Section 2.4 concerning

Symington, et al.      Expires September 15, 2009              [Page 43]

Internet-Draft          Bundle Security Protocol              March 2009

   eid-list entries.  They MUST contain security-parameters and
   security-result fields as follows:

   Security-parameters

      IV for this specific block

   Security-result

      encapsulated block

   The security-parameters and security-result fields in the subsequent
   PCBs MUST NOT contain any items other than these two.  Items such as
   key and salt are supplied in the first PCB and MUST NOT be repeated.

   Protection of the key is performed as described above in Section 2.7.
   Key management for this ciphersuite MUST support PKCSv2.1
   rsaEncryption as specified in [RFC3370] and MAY support other
   schemes.  The output from the key management protection scheme ("key
   information") is placed in the security-parameters field of the first
   PCB.

   If the bundle being encrypted is a fragment-bundle we have to specify
   which bytes are encrypted in case the bundle is subsequently
   fragmented again.  If the bundle is a fragment the ciphersuite
   parameters MUST include a fragment-range field, as described in
   Section 2.6, specifying the offset and length of the encrypted
   fragment.  Note that this is not the same pair of fields which appear
   in the primary block as "offset and length".  The "length" in this
   case is the length of the fragment, not the original length.  If the
   bundle is not a fragment then this field MUST be omitted.

   The confidentiality processing for payload and other blocks is
   different, mainly because the payload might be fragmented later at
   some other node.

   For the payload, only the bytes of the bundle payload field are
   affected, being replaced by ciphertext.  The salt, IV and key values
   specified in the first PCB are used to encrypt the payload, and the
   resultant authentication tag (ICV) is placed in an ICV item in the
   security-result field of that first PCB.  The other bytes of the
   payload block, such as type, flags and length, are not modified.

   For each PIB or PCB to be protected, the entire original block is
   encapsulated in a "replacing" PCB.  This replacing PCB is placed in
   the outgoing bundle in the same position as the original block, PIB
   or PCB.  As mentioned above, this is one-for-one replacement and
   there is no consolidation of blocks or mixing of data in any way.

Symington, et al.      Expires September 15, 2009              [Page 44]

Internet-Draft          Bundle Security Protocol              March 2009

   The encryption process uses AES-GCM with the salt and key values from
   the first PCB, and an IV unique to this PCB.  The process creates
   ciphertext for the entire original block, and an authentication tag
   for validation at the security destination.  For this encapsulation
   process, unlike the processing of the bundle payload, the
   authentication tag is appended to the ciphertext for the block and
   the combination is stored into the "encapsulated block" item in
   security-result.

   The replacing block, of course, also has the same correlator value as
   the first PCB with which it is associated.  It also contains the
   block-specific IV in security-parameters, and the combination of
   original-block-ciphertext and authentication tag, stored as an
   "encapsulated block" item in security-result.

   If the payload was fragmented after encryption then all those
   fragments MUST be present and reassembled before decryption.  This
   process might be repeated several times at different destinations if
   multiple fragmentation actions have occurred.

   The size of the GCM counter field limits the payload size to 2^39 -
   256 bytes, about half a terabyte.  A future revision of this
   specification will address the issue of handling payloads in excess
   of this size.

4.4.  ESB-RSA-AES128-EXT

   The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004.

   This scheme encrypts non-payload blocks.  The key size for this
   ciphersuite is 128 bits.

   Encryption is done using the AES algorithm in Galois/Counter Mode
   (GCM) as described in [RFC5084] [Note: parts of the following
   description are borrowed from RFC 4106].

   GCM is a block cipher mode of operation providing both
   confidentiality and data origin authentication.  The GCM
   authenticated encryption operation has four inputs: a secret key, an
   initialization vector (IV), a plaintext, and an input for additional
   authenticated data (AAD) which is not used here.  It has two outputs,
   a ciphertext whose length is identical to the plaintext, and an
   authentication tag, also known as the Integrity Check Value (ICV).

   For consistency with the description in [RFC5084], we refer to the
   GCM IV as a nonce.  The same key and nonce combination MUST NOT be
   used more than once.  The nonce has the following layout

Symington, et al.      Expires September 15, 2009              [Page 45]

Internet-Draft          Bundle Security Protocol              March 2009

   +----------------+----------------+---------------------------------+
   |                               salt                                |
   +----------------+----------------+---------------------------------+
   |                                                                   |
   |                      initialization vector                        |
   |                                                                   |
   +----------------+----------------+---------------------------------+

   Nonce format.

                                 Figure 7

   The salt field is a four-octet value, usually chosen at random.  It
   MUST be the same for all ESBs which have the same correlator value.
   The salt need not be kept secret.

   The initialization vector (IV) is an eight-octet value, usually
   chosen at random.  It MUST be different for all ESBs which have the
   same correlator value.  The value need not be kept secret.

   The data encryption key is a sixteen-octet (128 bits) value, usually
   chosen at random.  The value MUST be kept secret, as described below.

   The integrity check value is a sixteen-octet value used to verify
   that the protected data has not been altered.  The value need not be
   kept secret.

   This ciphersuite replaces each block to be protected with a
   "replacing" ESB, and each can be individually specified.  If a number
   of related blocks are to be protected they can be grouped as a
   correlated set.  These blocks replace the original blocks on a one-
   for-one basis, so the number of blocks remains unchanged.  All these
   related blocks MUST have the same correlator value.  The term "first
   ESB" in this section refers to the single ESB if there is only one
   or, if there are several, then to the one containing the key or key-
   identifier.  This MUST be the first of the set.  If the blocks are
   individually specified then there is no correlated set and each block
   is its own "first ESB".

   First ESB - the first ESB may contain a correlator value, and may
   specify security-source and/or security-destination in the eid-list.
   If not specified, the bundle-source and bundle-destination
   respectively are used for these values, as with other ciphersuites.
   The block MUST contain security-parameters and security-result
   fields.  Each field may contain several items formatted as described
   in Section 2.6.

   Security-parameters

Symington, et al.      Expires September 15, 2009              [Page 46]

Internet-Draft          Bundle Security Protocol              March 2009

      key information

      salt

      IV for this specific block

   Security-result

      encapsulated block

   Subsequent ESBs MUST contain a correlator value to link them to the
   first ESB.  Security-source and security-destination are implied from
   the first ESB, however see the discussion in Section 2.4 concerning
   eid-list entries.  They MUST contain security-parameters and
   security-result fields as follows:

   Security-parameters

      IV for this specific block

   Security-result

      encapsulated block

   The security-parameters and security-result fields in the subsequent
   ESBs MUST NOT contain any items other than these two.  Items such as
   key and salt are supplied in the first ESB and MUST NOT be repeated.

   Protection of the key is performed as described above in Section 2.7.
   Key management for this ciphersuite MUST support PKCSv2.1
   rsaEncryption as specified in [RFC3370] and MAY support other
   schemes.  The output from the key management protection scheme ("key
   information") is placed in the security-result field of the first
   ESB.

   For each block to be protected, the entire original block is
   encapsulated in a "replacing" ESB.  This replacing ESB is placed in
   the outgoing bundle in the same position as the original block.  As
   mentioned above, this is one-for-one replacement and there is no
   consolidation of blocks or mixing of data in any way.

   The encryption process uses AES-GCM with the salt and key values from
   the first ESB, and an IV unique to this ESB.  The process creates
   ciphertext for the entire original block, and an authentication tag
   for validation at the security destination.  The authentication tag
   is appended to the ciphertext for the block and the combination is
   stored into the "encapsulated block" item in security-result.

Symington, et al.      Expires September 15, 2009              [Page 47]

Internet-Draft          Bundle Security Protocol              March 2009

   The replacing block, of course, also has the same correlator value as
   the first ESB with which it is associated.  It also contains the
   block-specific IV in security-parameters, and the combination of
   original-block-ciphertext and authentication tag, stored as an
   "encapsulated block" item in security-result.

Symington, et al.      Expires September 15, 2009              [Page 48]

Internet-Draft          Bundle Security Protocol              March 2009

5.  Key Management

   Key management in delay tolerant networks is recognized as a
   difficult topic and is one that this specification does not attempt
   to solve.  However, solely in order to support implementation and
   testing,implementations SHOULD support:

      - Long-term pre-shared-symmetric keys for the BAB-HMAC
      ciphersuite.

      - The use of well-known RSA public keys for PIB-RSA-SHA256, PCB-
      RSA-AES128-PAYLOAD-PIB-PCB and ESB-RSA-AES128-EXT ciphersuites.

   Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC3280]
   public key certificates (in the subjectAltName extension)
   implementations SHOULD support this way of distributing public keys.
   Implementations SHOULD NOT be very strict in how they process X.509
   though, for example, it would probably not be correct to insist on
   Certificate Revocation List (CRL) checking in many DTN contexts.

Symington, et al.      Expires September 15, 2009              [Page 49]

Internet-Draft          Bundle Security Protocol              March 2009

6.  Default Security Policy

   Every node serves as a Policy Enforcement Point insofar as it
   enforces some policy that controls the forwarding and delivery of
   bundles via one or more convergence layer protocol implementation.
   Consequently, every node SHALL have and operate according to its own
   configurable security policy, whether the policy be explicit or
   default.  The policy SHALL specify:

      Under what conditions received bundles SHALL be forwarded.

      Under what conditions received bundles SHALL be required to
      include valid BABs.

      Under what conditions the authentication information provided in a
      bundle's BAB SHALL be deemed adequate to authenticate the bundle.

      Under what conditions received bundles SHALL be required to have
      valid PIBs and/or PCBs.

      Under what conditions the authentication information provided in a
      bundle's PIB SHALL be deemed adequate to authenticate the bundle.

      Under what conditions a BAB SHALL be added to a received bundle
      before that bundle is forwarded.

      Under what conditions a PIB SHALL be added to a received bundle
      before that bundle is forwarded.

      Under what conditions a PCB SHALL be added to a received bundle
      before that bundle is forwarded.

      The actions that SHALL be taken in the event that a received
      bundle does not meet the receiving node's security policy
      criteria.

   This specification does not address how security policies get
   distributed to nodes.  It only REQUIRES that nodes have and enforce
   security policies.

   If no security policy is specified at a given node, or if a security
   policy is only partially specified, that node's default policy
   regarding unspecified criteria SHALL consist of the following:

      Bundles that are not well-formed do not meet the security policy
      criteria.

Symington, et al.      Expires September 15, 2009              [Page 50]

Internet-Draft          Bundle Security Protocol              March 2009

      The standard ciphersuites MUST be used.

      All bundles received MUST have a BAB which MUST be verified to
      contain a valid security result.  If the bundle does not have a
      BAB, then the bundle MUST be discarded and processed no further; a
      bundle status report indicating the authentication failure MAY be
      generated.

      No received bundles SHALL be required to have a PIB; if a received
      bundle does have a PIB, however, the PIB can be ignored unless the
      receiving node is the PIB-dest, in which case the PIB MUST be
      verified.

      No received bundles SHALL be required to have a PCB; if a received
      bundle does have a PCB, however, the PCB can be ignored unless the
      receiving node is the PCB-dest, in which case the PCB MUST be
      processed.  If processing of a PCB yields a PIB, that PIB SHALL be
      processed by the node according to the node's security policy.

      A PIB SHALL NOT be added to a bundle before sourcing or forwarding
      it.

      A PCB SHALL NOT be added to a bundle before sourcing or forwarding
      it.

      A BAB MUST always be added to a bundle before that bundle is
      forwarded.

      If a destination node receives a bundle that has a PIB-dest but
      the value in that PIB-dest is not the EID of the destination node,
      the bundle SHALL be delivered at that destination node.

      If a received bundle does not satisfy the node's security policy
      for any reason, then the bundle MUST be discarded and processed no
      further; in this case, a bundle deletion status report (see the
      Bundle Protocol [DTNBP]) indicating the failure MAY be generated.

Symington, et al.      Expires September 15, 2009              [Page 51]

Internet-Draft          Bundle Security Protocol              March 2009

7.  Security Considerations

   If a BAB ciphersuite uses digital signatures but doesn't include the
   security destination (which for a BAB is the next host), then this
   allows the bundle to be sent to some node other than the intended
   adjacent node.  Because the BAB will still authenticate, the
   receiving node may erroneously accept and forward the bundle.  When
   asymmetric BAB ciphersuites are used, the security destination field
   SHOULD therefore be included in the BAB.

   If a bundle's PIB-dest is not the same as its destination, then some
   node other than the destination (the node identified as the PIB-dest)
   is expected to validate the PIB security result while the bundle is
   en route.  However, if for some reason the PIB is not validated,
   there is no way for the destination to become aware of this.
   Typically, a PIB-dest will remove the PIB from the bundle after
   verifying the PIB and before forwarding it.  However, if there is a
   possibility that the PIB will also be verified at a downstream node,
   the PIB-dest will leave the PIB in the bundle.  Therefore, if a
   destination receives a bundle with a PIB that has a PIB-dest (which
   isn't the destination), this may, but does not necessarily, indicate
   a possible problem.

   If a bundle is fragmented after being forwarded by its PIB-source but
   before being received by its PIB-dest, the payload in the bundle MUST
   be reassembled before validating the PIB security result in order for
   the security result to validate correctly.  Therefore, if the PIB-
   dest is not capable of performing payload reassembly, its utility as
   a PIB-dest will be limited to validating only those bundles that have
   not been fragmented since being forwarded from the PIB-source.
   Similarly, if a bundle is fragmented after being forwarded by its
   PIB-source but before being received by its PIB-dest, all fragments
   MUST be received at that PIB-dest in order for the bundle payload to
   be able to be reassembled.  If not all fragments are received at the
   PIB-dest node, the bundle will not be able to be authenticated, and
   will therefore never be forwarded by this PIB-dest node.

   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.

Symington, et al.      Expires September 15, 2009              [Page 52]

Internet-Draft          Bundle Security Protocol              March 2009

8.  IANA Considerations

   None at this time.  If the bundle protocol becomes a standards track
   protocol, then we may want to consider having IANA establish a
   register of block types, and in particular for this specification a
   separate register of ciphersuite specifications.

Symington, et al.      Expires September 15, 2009              [Page 53]

Internet-Draft          Bundle Security Protocol              March 2009

9.  References

9.1.  Normative References

   [DTNBP]    Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [DTNMD]    Symington, S., "Delay-Tolerant Networking Metadata
              Extension Block",
              draft-irtf-dtnrg-bundle-metadata-block-00.txt , June 2007.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S. and J. Reynolds, "Key words for use in RFCs to
              Indicate Requirement Levels", RFC 2119, October 1997.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, August 2002.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509  Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", RFC 4055,
              June 2005.

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)",
              RFC 4106, June 2005.

9.2.  Informative References

   [DTNRB]    Symington, S., "Delay-Tolerant Network Retransmission
              Block",
              draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress,
              April 2007.

   [DTNarch]  Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A.,
              Scott, K., Torgerson, L., and H. Weiss, "Delay-Tolerant

Symington, et al.      Expires September 15, 2009              [Page 54]

Internet-Draft          Bundle Security Protocol              March 2009

              Network Architecture", RFC 4838, April 2007.

   [DTNsecOver]
              Farrell, S., Symington, S., Weiss, H., and P. Lovell,
              "Delay-Tolerant Networking Security Overview",
              draft-irtf-dtnrg-sec-overview-06.txt, work-in-progress,
              March 2009.

   [RFC5084]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
              Encryption in the Cryptographic Message Syntax (CMS)",
              RFC 5084, November 2007.

Symington, et al.      Expires September 15, 2009              [Page 55]

Internet-Draft          Bundle Security Protocol              March 2009

Authors' Addresses

   Susan Flynn Symington
   The MITRE Corporation
   7515 Colshire Drive
   McLean, VA  22102
   US

   Phone: +1 (703) 983-7209
   Email: [email-masked]
   URI:   http://mitre.org/

   Stephen Farrell
   Trinity College Dublin
   Distributed Systems Group
   Department of Computer Science
   Trinity College
   Dublin  2
   Ireland

   Phone: +353-1-608-1539
   Email: [email-masked]

   Howard Weiss
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, MD  21046
   US

   Phone: +1-443-430-8089
   Email: [email-masked]

   Peter Lovell
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, MD  21046
   US

   Phone: +1-443-430-8052
   Email: [email-masked]

Symington, et al.      Expires September 15, 2009              [Page 56]


--Boundary_(ID_MK2Ynh94Bd0F+MsR18e4cQ)--

From: Kevin Fall <[email-masked]>
To: Elwyn Davies <[email-masked]>
Date: Tue, 17 Mar 2009 12:14:35 -0700
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Naming and Addressing

some comments inline.  I expect to be giving a short presentation at  
the upcoming Google meeting that makes more concrete some of the  
things I mentioned in Germany (i.e., about naming structures and URI/ 
scheme use).

- K

On Mar 17, 2009, at Mar 174:11 AMPDT, Elwyn Davies wrote:

> Burleigh, Scott C wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Ivancic,
>>> William D. (GRC-RHN0)
>>> Sent: Monday, March 16, 2009 9:27 PM
>>> To: dtn interest
>>> Subject: [dtn-interest] Naming and Addressing
>>>
>>> Naming and addressing is one of the points of technical discussion  
>>> for the
>>> DTNRG meetings March 19 and 20.  I thought I could get some  
>>> discussion
>>> started here.
>>>
>>> This discussion started on a NASA internal list, but we can bound  
>>> the
>>> problem there as Space is, in many ways, much simpler due to the  
>>> size of
>>> the network and the predictability of the network (at least for a  
>>> space-
>>> base backbone).
>>>
>>> The current DTN Bundling Architecture (not the bundling framework,  
>>> rather
>>> the architecture) really does not have a common lower layer  
>>> address space.
>>> At least that is the way it looks to me.  The bundle agent connects
>>> directly to convergence layers with no DTN addressing scheme.
>>>
>>
>> I would say you are right, Will: the DTN architecture doesn't have  
>> any notion of addresses that I am aware of.  Routing of a bundle is  
>> done on the basis of the *name* of its destination, not the address  
>> (which may well not be known to the sender or any relay point,  
>> because the destination node may be locally mobile).  "Late  
>> binding" in DTN is, essentially, the resolution of name to address  
>> at the last possible moment, in recognition of the significant  
>> chance that this resolution will change over the course of the  
>> bundle's progress from its source to its destination..
>>
> One way of expressing this is that the DTN name doesn't define the  
> path
> in advance.

Right, there isn't really a DTN addressing scheme per-se.  That is by  
design.  In particular, there is the URI idea with where different  
name spaces can be represented.  You can represent any addressing  
scheme you choose to use using that construct.  Also, you can map  
between them, which is a point I will be interested in discussing thu/ 
fri.  Note that even in Internet we move between multiples name and  
address spaces (e.g., DNS, mail names, and sometimes IP addresses if  
we have reason to believe DNS isn't working).  This type of  
flexibility is necessary for DTN as well, so I believe "there can be  
only one" is absolutely not the right thing.  Late binding is an  
option that I think matches well to high-delay networks.  However,  
there are some cases where early binding and possibly source-routing  
is needed, and the naming/addressing architecture should be able to  
handle it too.

>
>
> Because of the overloading of IP addresses as both identifier and
> locator, the choice of addresses at the source in IP effectively binds
> the packet to a path through the IP network before the packet sets  
> off.
> One can quibble about the details (like load spreading across multiple
> paths in the core, backup paths coming into play, rerouting) but for  
> the
> vast majority of packets the routing fate of the packet is known at  
> the
> time of  despatch. Originally just the destination address mattered.
> Now the source and possibly some QoS bits may come into play but this
> doesn't really change the situation. In IP the per-packet routing
> 'decision' at each router is not really a decision at all but a  
> lookup.

Generally true.  The exception being some of the on-demand ad-hoc type  
protocols.

>
> The decision has been made previously by the control plane routing
> protocol and the packet is tied to that path.  [Aside: The IP world  
> has
> come to be wedded to the path predestination 'principle' (dogma?).
> Multipath routing is being considered in the research community but is
> not mainstream.  Most, if not all, of the proposed fixes for the
> multihoming problem and providing an id/locator split still cling to  
> the
> predestined path, although it may be a bit disguised.]

Right, and so most of these discussions tend to involve some sort of  
distributed mapping system that takes either "names" or "addresses"  
and converts them into some other form of address.  (see LISP from RRG  
as an example).  In my opinion it only sort of helps the major  
problems facing the Internet, at the cost of introducing some others.   
{e.g., try reading the DNSSEC documents then imagine securing yet  
another lookup scheme; although its possibly we won't have it much  
easier}.

>
>
> In DTN, particularly with the more opportunist encounter type of
> network, there is a real decision to be made and this can be  
> influenced
> by aspects of the bundle, although I think that apart from size and
> possibly custody requirements this hasn't had much effect as yet.

There is another important couple of decisions:  what protocol to use  
and whether to copy of forward the bundle.
[not to mention any security issues].

>
>>
>>> To me, it
>>> would be desirable to have some type of topological and hierarchical
>>> addressing scheme to aid in routing and security (something  
>>> similar to IP-
>>> tables).
>>>
>>
>> That would clearly be one, very familiar way to support routing and  
>> security, but in my understanding of DTN it would not be the DTN way.
>>
> IMO it would be highly undesirable to take us down the path of a  
> totally
> hierarchical system.  Although it looks promising as a scaling
> mechanism, the existing IP routing system shows that you have to be  
> very
> careful about what happens when it gets very big.  Also the notion  
> of a
> single authority that tends to be the follow on to a hierarchy doesn't
> chime well with DTN.

agree.  Much of the current Internet problems are a consequence of the  
hierarchy forced upon us by CIDR. Granted, CIDR was arguably necessary  
at the time it was deployed, but things like provider independence,  
multihoming, and mobility are made much much harder by it.
>
>>
>>> However, because there is no common addressing scheme, a
>>> multitude of DTN bundle agents looks like a flat network because I  
>>> think
>>> what we really have is  application-layer store and forward  
>>> gateways that
>>> can be graphically connected.  So in the strictest definition of a  
>>> network
>>> being related to graph theory, you sort of have a network.  But  
>>> when one
>>> looks at what one would expect from a network (things like a common
>>> addressing scheme), it is not currently present.

I suggested above why a (loosened) definition of Internet doesn't  
support a single common addressing scheme.

>>>
>>>
>>
>> Right, the network is different from IP in that routing is done on  
>> the basis of name, as far as possible, rather than on the basis of  
>> address.  This is one of the significant ways in which DTN differs  
>> from IP.
>>
>>
>>> Wes Eddy pointed out the following:
>>>
>>> "The typical approach is to enable the split by setting up 2 sub- 
>>> layers,
>>> one with locators below and one with identifiers above.  In DTN,  
>>> we have a
>>> different approach.  An EID could be either a locator or an  
>>> identifier
>>> depending on how the EID scheme and forwarding on it are defined.   
>>> Inside a
>>> bundle agent though, EIDs and next-hops have to map to convergence  
>>> layer
>>> addresses, which may or may not be locators themselves, but are  
>>> definitely
>>> the locators from a bundle agent's point-of-view as they basically  
>>> specify
>>> network coordinates at some specific time.

agree with the gist of this but not sure I'd agree they are  
'definitely the locators'.  But
I don't think its very important to argue it either.

>>>
>>>
>>> So ... I'd say that an EID *can* be an address, though you don't  
>>> often want
>>> it to be one, but a set of convergence layer parameters is the  
>>> real address
>>> in the DTN architecture."
>>>
>>
>> Right, there are no addresses in use at what serves as the "network  
>> protocol" within DTN (the Bundle Protocol), but there are addresses  
>> in use within the underlying convergence-layer protocols.  These  
>> are the addresses that are computed by "late binding".

there are no mandated addresses.

>>
>>
> And they are really only of point-to-point significance in one
> forwarding hop.  On a multihop path, the convergence layer parameters
> (essentially a token to send a bundle along a particular active link)
> are a local mapping at each node that are not relevant once the bundle
> has moved to the next node.

I wouldn't say point to point exactly, as we might well have a bcast  
or mcast distribution model, but
yes there is some truth to this point.

>
>>
>>> ---> Back to my thoughts <---
>>>
>>> I believe BBN is looking at running DTN as the network directly  
>>> over a
>>> meshed wireless ad hoc network.  Thus DTN is the upper layer  
>>> network.
>>> There is not IP network.  In this case, I believe they are using  
>>> the radio
>>> MAC and the Endpoint Identifier and realize this does not scale.   
>>> Also I am
>>> not sure if this is a multi-radio system with one MAC address or  
>>> something
>>> else.  But it has been proven that naming the end system by the  
>>> interface
>>> is bad for multihoming.
>>>
>>
>> If I understand you right, Will, I agree.  I think the way you get  
>> multihoming in DTN is by having multiple convergence-layer service  
>> access points (for, most likely, multiple convergence-layer  
>> protocols) at a single node.
>>
> I think there is some confusion here (as there often is in IP
> discussions of multihoming) between the logical multihoming  
> (typically a
> service agreement between the end network and a service provider)  and
> physical multihoming (having multiple independent network interfaces
> available simultaneously).  In DTN networks a node may have multiple
> physical interfaces (quite possibly using different  convergence-layer
> protocols) but it can also have multiple logical links over a single
> convergence layer (e.g., simultaneous ad hoc Wi-Fi connections).   And
> there is the additional dimension that these links (unlike the usual  
> IP
> case) are not necessarily simultaneously active/available.  So, yes it
> is probably not generally clever to identify a node with a single
> interface, but that doesn't necessarily prevent it being multihomed if
> the single interface is a wireless interface that can support multiple
> ad hoc connections at once.
>
> In most of the IP multihoming discussions we are talking about a hard
> wired mapping between the administrative connections of a logically
> multihomed node and the physical connections. IP early binding then
> ought to tie a packet with given addresses to a path through one or
> other of the links.  For a large proportion of DTN networks these
> concepts are irrelevant, although gateways will generally have  
> different
> associations on either side.
>>
>>> I think we should address multi-homing and mobility at the onset.   
>>> Late-
>>> binding might help us here.  Ignoring the problem in the past has  
>>> resulted
>>> in poor band-aid approaches to trying to get something to work  
>>> later.
>>>
>>
>> I agree that we should take multi-homing and mobility into account  
>> right from the beginning.
>>

that was largely the motivation to get rid of "regions" as a mandated  
concept

> Absolutely.  Dealing (as I do) with 'data mule' type networks many of
> the nodes are mobile, but early thinking only made them physically
> mobile, keeping them essentially within one 'association'  (we aren't
> allowed to call it a region  but  for the purposes of understanding
> history, we were originally talking about nodes only encountering  
> nodes
> that live in a common area and have some common purpose making it  
> useful
> for them to talk to one another). We now have to allow at least some
> nodes to be very mobile, associating with several other groups of DTN
> nodes and occasionally migrating back into the (legacy) Internet.
>
> I think the notion of association is a useful structuring mechanism,  
> but
> nodes need to be allowed to be members of multiple associations.
> Associations could be recursive, but I don't want to go down the  
> path of
> a single hierarchy.
>
>
>>
>>> Perhaps the bundle agent identity does not have to be a URI, but  
>>> some
>>> unique identifier that can be bound to various URI's (aliased).   
>>> This might
>>> help security.
>>>
>>
>> In ION we address this by drawing a firm distinction between DTN  
>> endpoints and underlying convergence-layer protocol "ducts", with a  
>> managed mapping between the two.  The former are necessarily URIs,  
>> but the latter are not.

I think in most cases you don't care about the identity of a node.   
You care about the authorship of data.

>>
>>
>>
>>> If we don't have a heretical addressing structure, perhaps we can  
>>> develop a
>>> hierarchical naming structure.
>>>
>>
>> I think there are good reasons for not doing that in all cases,  
>> though.  Hierarchies are convenient, but they also tend to be  
>> inflexible and difficult to revise.
>>
>>
> +1

I think hierarchical naming, independent of topology, is likely a  
reasonable thing.  There may be multiple hierarchical name spaces,  
however.

>
>>> Without some form or hierarchy, will DTNs be simple edge network  
>>> gateways
>>> do to an inability to scale the network?
>>>
>>
>> I don't think so.  In some ways I think a flat namespace is  
>> actually more robust than a hierarchical address space.
>>

There is a very fundamental question here, and its not only a DTN  
question.  Can a non-hierarchical addressing scheme be made to work.   
I have been doing some work with compact routing (see CCR paper on  
this for a sort of summary).  The short answer is 'it seems so', but  
the longer answer is that when there is too much dynamics in the  
network it can be difficult.  I think it is probably among the most  
important networking research questions to answer at this point.

- K

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Rajesh Krishnan <[email-masked]>
Date: Tue, 17 Mar 2009 13:36:11 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples

>-----Original Message-----
>From: Rajesh Krishnan [mailto:[email-masked]] 
>Sent: Tuesday, March 17, 2009 2:02 PM
>
>Wes:
>
>It may be useful to think of late binding as a generalization.  There
>are mobility management (in a topological sense), name to address
>resolution, alias resolution, as well as other aspects  such as
>maintenance of related dynamic multi-attribute naming data bases to
>late binding.
>
>Mobile IP routes to the IP address of a care-of destination instead
>the address of the actual destination; there is readdressing,  but no
>name resolution at every step.  This procedure does not account for
>routing on multi-attributed names (there is no further name resolution
>post the source), or CLA parameters in heterogeneous networks.
>
>The SPINDLE architecture makes use of care-of resolvers that resemble
>the foreign agent in mobile IP, but there is more to consider beyond
>mobility management alone.
>
>Prithwish  may have additional insights on this topic since I recall
>we went through the same thought process to determine how is late
>binding not just mobility management, routing, alias resolution etc.

I think I understand and agree; the ability for EIDs to "name" things
that aren't just interfaces or sets of interfaces is a strong feature
beyond normal IP-based networking.

But ... if we have pub/sub applications running over a network layer
that includes mobility management (whether Mobile IP, a MANET, etc.),
I think that would yield a similar set of properties to SPINDLE?  It's
certainly a different architecture, but is it functionally equivalent?
Pub/sub systems often support store-and-forward as an option for
messages, so the main difference I see between them and DTN is that
they're usually not as flexible about the "convergence layer adapter"
protocols they're wed to.

So, in my mind there's a good question about placement of features in
layers and whether content-based features belong low-down or higher-up.
We can see there are benefits in placing them low, but what are the
costs?  The question is complicated by the fact that DTN BP can be
either high or low in the stack depending on your deployment case :).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

Date: Tue, 17 Mar 2009 14:01:45 -0400
From: Rajesh Krishnan <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples

Wes:

It may be useful to think of late binding as a generalization.  There
are mobility management (in a topological sense), name to address
resolution, alias resolution, as well as other aspects  such as
maintenance of related dynamic multi-attribute naming data bases to
late binding.

Mobile IP routes to the IP address of a care-of destination instead
the address of the actual destination; there is readdressing,  but no
name resolution at every step.  This procedure does not account for
routing on multi-attributed names (there is no further name resolution
post the source), or CLA parameters in heterogeneous networks.

The SPINDLE architecture makes use of care-of resolvers that resemble
the foreign agent in mobile IP, but there is more to consider beyond
mobility management alone.

Prithwish  may have additional insights on this topic since I recall
we went through the same thought process to determine how is late
binding not just mobility management, routing, alias resolution etc.

Best Regards,
Rajesh

On Tue, Mar 17, 2009 at 12:38 Eddy, Wesley M. (GRC-RCN0)[Verizon]
<[email-masked]> wrote:
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]] On
>>Behalf Of Burleigh, Scott C
>>Sent: Tuesday, March 17, 2009 12:08 PM
>>
>>In case it's helpful, here's what section 3.3.2 of RFC 4838 says:
>>
>> � Binding means interpreting the SSP of an EID for the purpose of
>> � carrying an associated message towards a destination. �For example,
>> � binding might require mapping an EID to a next-hop EID or
>>to a lower-
>> � layer address for transmission. �"Late binding" means that the
>> � binding of a bundle's destination to a particular set of destination
>> � identifiers or addresses does not necessarily happen at the bundle
>> � source. �Because the destination EID is potentially
>>re-interpreted at
>> � each hop, the binding may occur at the source, during transit, or
>> � possibly at the destination(s). �This contrasts with the name-to-
>> � address binding of Internet communications where a DNS lookup at the
>> � source fixes the IP address of the destination node before data is
>> � sent. �Such a circumstance would be considered "early binding"
>> � because the name-to-address translation is performed prior to data
>> � being sent into the network.
>
>
>
> Could Mobile IP similarly be called late-binding as the resolution
> of the HoA to a CoA isn't necessarily at the packet source?
>
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: "Fall, Kevin" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 10:25:19 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] proposed agenda for Google meeting - subject to discussion / change based on interest

--_000_02968BB921677D479DAB47F25B731223F3C5771Dorsmsx504amrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

DTNRG Google Meeting
http://www.dtnrg.org

Dates:
        3/19/09 9am-5pm
        3/20/09 9am-3pm

Address: 1950 Charleston Road, Mountain View, CA 94043, USA
Attendees: http://down.dsg.cs.tcd.ie/dtnrg-at-google/attendees.txt

Day 1 (Mar 19)

09:00- 09:15    Intros / Agenda Bash
09:15- 09:45    Document / RG Status
09:45- 10:30    Discussion of "last call" docs
10:30- 10:45    Break
10:45- 12:30    Discussion of "last call" docs (II)
12:30- 13:45    Lunch
13:45- 14:30    Naming/Addressing/Routing Discussion (I)
14:30- 15:00    DTNBone Discussion
15:00- 15:15    Break
15:15- 16:00    Network Management for DTN Discusion
16:00- 16:30    Future interop plans
16:30- 17:00    scheduled schedule slip

Day 2 (Mar 20)

09:00- 10:30    Naming/Addressing Discussion (II)
10:30- 11:00    Break
11:00- 12:00    Naming/Addressing Discussion (III)
12:00- 13:15    Lunch
13:15- 14:30    Security discussion
14:30- 15:00    Wrap-up / future plans

--_000_02968BB921677D479DAB47F25B731223F3C5771Dorsmsx504amrcor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>DTNRG Google Meeting<o:p></o:p></p>

<p class=3DMsoNormal>http://www.dtnrg.org<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Dates:<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3/19/09 9am=
-5pm<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3/20/09 9am=
-3pm<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Address: 1950 Charleston Road, Mountain View, CA 94043=
, USA<o:p></o:p></p>

<p class=3DMsoNormal>Attendees:
http://down.dsg.cs.tcd.ie/dtnrg-at-google/attendees.txt<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Day 1 (Mar 19)<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>09:00- 09:15&nbsp;&nbsp;&nbsp; Intros / Agenda Bash<o:=
p></o:p></p>

<p class=3DMsoNormal>09:15- 09:45&nbsp;&nbsp;&nbsp; Document / RG Status<o:=
p></o:p></p>

<p class=3DMsoNormal>09:45- 10:30&nbsp;&nbsp;&nbsp; Discussion of &quot;las=
t call&quot; docs<o:p></o:p></p>

<p class=3DMsoNormal>10:30- 10:45&nbsp;&nbsp;&nbsp; Break<o:p></o:p></p>

<p class=3DMsoNormal>10:45- 12:30&nbsp;&nbsp;&nbsp; Discussion of &quot;las=
t call&quot; docs
(II)<o:p></o:p></p>

<p class=3DMsoNormal>12:30- 13:45&nbsp;&nbsp;&nbsp; Lunch<o:p></o:p></p>

<p class=3DMsoNormal>13:45- 14:30&nbsp;&nbsp;&nbsp; Naming/Addressing/Routi=
ng Discussion (I)<o:p></o:p></p>

<p class=3DMsoNormal>14:30- 15:00&nbsp;&nbsp;&nbsp; DTNBone Discussion<o:p>=
</o:p></p>

<p class=3DMsoNormal>15:00- 15:15&nbsp;&nbsp;&nbsp; Break<o:p></o:p></p>

<p class=3DMsoNormal>15:15- 16:00&nbsp;&nbsp;&nbsp; Network Management for =
DTN Discusion<o:p></o:p></p>

<p class=3DMsoNormal>16:00- 16:30&nbsp;&nbsp;&nbsp; Future interop plans<o:=
p></o:p></p>

<p class=3DMsoNormal>16:30- 17:00&nbsp;&nbsp;&nbsp; scheduled schedule slip=
<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Day 2 (Mar 20)<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>09:00- 10:30&nbsp;&nbsp;&nbsp; Naming/Addressing Discu=
ssion (II)<o:p></o:p></p>

<p class=3DMsoNormal>10:30- 11:00&nbsp;&nbsp;&nbsp; Break<o:p></o:p></p>

<p class=3DMsoNormal>11:00- 12:00&nbsp;&nbsp;&nbsp; Naming/Addressing Discu=
ssion (III)<o:p></o:p></p>

<p class=3DMsoNormal>12:00- 13:15&nbsp;&nbsp;&nbsp; Lunch<o:p></o:p></p>

<p class=3DMsoNormal>13:15- 14:30&nbsp;&nbsp;&nbsp; Security discussion<o:p=
></o:p></p>

<p class=3DMsoNormal>14:30- 15:00&nbsp;&nbsp;&nbsp; Wrap-up / future plans<=
o:p></o:p></p>

</div>

</body>

</html>

--_000_02968BB921677D479DAB47F25B731223F3C5771Dorsmsx504amrcor_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>, "'dtn interest'" <[email-masked]>
Date: Tue, 17 Mar 2009 11:58:54 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Late Binding examples

> In case it's helpful, here's what section 3.3.2 of RFC 4838 says:
> 
>    Binding means interpreting the SSP of an EID for the purpose of
>    carrying an associated message towards a destination.  For example,
>    binding might require mapping an EID to a next-hop EID or 
> to a lower-
>    layer address for transmission.  "Late binding" means that the
>    binding of a bundle's destination to a particular set of 
> destination
>    identifiers or addresses does not necessarily happen at the bundle
>    source.  Because the destination EID is potentially 
> re-interpreted at
>    each hop, the binding may occur at the source, during transit, or
>    possibly at the destination(s).  This contrasts with the name-to-
>    address binding of Internet communications where a DNS 
> lookup at the
>    source fixes the IP address of the destination node before data is
>    sent.  Such a circumstance would be considered "early binding"
>    because the name-to-address translation is performed prior to data
>    being sent into the network.
> 
> Scott

OK from that definition, I would have to say you are doing late binding.

/Will

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>, "'dtn interest'" <[email-masked]>
Date: Tue, 17 Mar 2009 11:38:35 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Late Binding examples

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Burleigh, Scott C
>Sent: Tuesday, March 17, 2009 12:08 PM
>
>In case it's helpful, here's what section 3.3.2 of RFC 4838 says:
>
>   Binding means interpreting the SSP of an EID for the purpose of
>   carrying an associated message towards a destination.  For example,
>   binding might require mapping an EID to a next-hop EID or 
>to a lower-
>   layer address for transmission.  "Late binding" means that the
>   binding of a bundle's destination to a particular set of destination
>   identifiers or addresses does not necessarily happen at the bundle
>   source.  Because the destination EID is potentially 
>re-interpreted at
>   each hop, the binding may occur at the source, during transit, or
>   possibly at the destination(s).  This contrasts with the name-to-
>   address binding of Internet communications where a DNS lookup at the
>   source fixes the IP address of the destination node before data is
>   sent.  Such a circumstance would be considered "early binding"
>   because the name-to-address translation is performed prior to data
>   being sent into the network.

Could Mobile IP similarly be called late-binding as the resolution
of the HoA to a CoA isn't necessarily at the packet source?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

Date: Tue, 17 Mar 2009 12:28:01 -0400
From: Rajesh Krishnan <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples

In an IP network, the destination IP address is bound at the source;
the mapping from name to address is determined at source.   DTN routes
on names, and the mapping from name to destination and hence to next
hop addresses (ports, and other parameters) are not entirely
determined at source.

Prithwish's work from SPINDLE looks at two specific mappings:

  * it is easier for some routing protocols to work on a single
namespace; so a mapping from
    a rich namespace to a simpler one that routing uses is valuable

  * the second mapping is the mapping from next hop to the convergence
layer parameters
    (which CLA, address, port, frequency, etc.)

I think it is a good practical decomposition (although not the only
one possible) that is definitely worthy of discussion in detail within
the DTNRG.

-Rajesh

On Tue, Mar 17, 2009 at 11:12 AM, Burleigh, Scott C
<[email-masked]> wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jason Redi
>> Sent: Tuesday, March 17, 2009 4:55 AM
>> To: Burleigh, Scott C; 'dtn interest'
>> Subject: RE: [dtn-interest] Late Binding examples
>>
>> Scott,
>> Sorry -- but I don't understand how that is late-binding from your
>> description. �That sounds like regular old packet forwarding except that you
>> are breaking the choice of link (CLA) from the nexthop decision. �But I
>> don't see naming or addressing decisions involved anywhere.
>
> Let me amplify. �My understanding of "late binding" is that we look up the final destination address at the last possible moment, i.e., we use the final destination's name -- rather than its address -- as the basis for route computation. �That's what ION does: at each node on the end-to-end path, the final destination endpoint name is used as the basis for selecting the next neighbor node (again identified by name, not address) to transmit to, and then that transmission is accomplished by mapping that next-neighbor name to an "outduct" -- which might be to an IP address or might be to some other sort of service access point such as an LTP engine ID.
>
> Scott
>
>> ---
>> �Dr. Jason K. Redi
>> �BBN Technologies
>> �10 Moulton St., Cambridge, MA, 02138
>> �[email-masked]
>>
>>
>> > -----Original Message-----
>> > From: [email-masked] [mailto:dtn-
>> > [email-masked]] On Behalf Of Burleigh,
>> > Scott C
>> > Sent: Tuesday, March 17, 2009 2:45 AM
>> > To: dtn interest
>> > Subject: Re: [dtn-interest] Late Binding examples
>> >
>> > ION certainly uses late binding routinely. �At every hop on the end-to-
>> > end path, the routing algorithm selects a neighboring node to transmit
>> > to and then determines what convergence-layer endpoint (e.g., UDP port
>> > number, LTP span, etc.) to transmit to in order to get the bundle to
>> > that node. �The routing is really orthogonal -- and complementary -- to
>> > late binding, which is a very late step in the forwarding procedure.
>> >
>> > Scott
>> >
>> > > -----Original Message-----
>> > > From: [email-masked] [mailto:dtn-
>> > > [email-masked]] On Behalf Of Ivancic,
>> > > William D. (GRC-RHN0)
>> > > Sent: Monday, March 16, 2009 9:27 PM
>> > > To: dtn interest
>> > > Subject: [dtn-interest] Late Binding examples
>> > >
>> > >
>> > > One sort-of feature of DTN is late binding. �Has anyone implemented
>> > late-
>> > > binding (not to be confused with content-base routing/delivery)? �If
>> > so,
>> > > can you point me to some examples and what addressing scheme was
>> > used? I
>> > > ask because I am unaware of any implemented routing schemes that
>> > really do
>> > > late-binding. �This all is in relation to naming and addressing. �It
>> > seems
>> > > to me that late binding requires distributed name resolvers.
>> > >
>> > > Thanks,
>> > >
>> > >
>> > > /Will
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > dtn-interest mailing list
>> > > [email-masked]
>> > > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >
>> > _______________________________________________
>> > dtn-interest mailing list
>> > [email-masked]
>> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: "Burleigh, Scott C" <[email-masked]>
To: "'dtn interest'" <[email-masked]>
Date: Tue, 17 Mar 2009 09:08:17 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Late Binding examples

> -----Original Message-----
> From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2009 8:20 AM
> To: [email-masked]; Burleigh, Scott C; 'dtn interest'
> Subject: RE: [dtn-interest] Late Binding examples
> 
> -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On
> > Behalf Of Jason Redi
> > Sent: Tuesday, March 17, 2009 7:55 AM
> > To: 'Burleigh, Scott C'; 'dtn interest'
> > Subject: Re: [dtn-interest] Late Binding examples
> >
> > Scott,
> > Sorry -- but I don't understand how that is late-binding from
> > your description.  That sounds like regular old packet
> > forwarding except that you are breaking the choice of link
> > (CLA) from the nexthop decision.  But I don't see naming or
> > addressing decisions involved anywhere.
> >
> > Jason
> 
> I agree that Scott's example is not what I consider late binding but rather
> DTN routing.  In fact, the way contact graph routing works, I believe you
> actually have early  binding.  You have to know pretty much where every
> node will be at all times to generate a contact graph.  That is early
> binding.  If you were sending to rove-24 on the moon and so you forwarded
> the message to the moon and then the moon gateway figured out the rest,
> that would be late binding - at least as I understand it.

In case it's helpful, here's what section 3.3.2 of RFC 4838 says:

   Binding means interpreting the SSP of an EID for the purpose of
   carrying an associated message towards a destination.  For example,
   binding might require mapping an EID to a next-hop EID or to a lower-
   layer address for transmission.  "Late binding" means that the
   binding of a bundle's destination to a particular set of destination
   identifiers or addresses does not necessarily happen at the bundle
   source.  Because the destination EID is potentially re-interpreted at
   each hop, the binding may occur at the source, during transit, or
   possibly at the destination(s).  This contrasts with the name-to-
   address binding of Internet communications where a DNS lookup at the
   source fixes the IP address of the destination node before data is
   sent.  Such a circumstance would be considered "early binding"
   because the name-to-address translation is performed prior to data
   being sent into the network.

Scott

> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:dtn-
> > > [email-masked]] On Behalf Of
> > Burleigh,
> > > Scott C
> > > Sent: Tuesday, March 17, 2009 2:45 AM
> > > To: dtn interest
> > > Subject: Re: [dtn-interest] Late Binding examples
> > >
> > > ION certainly uses late binding routinely.  At every hop on the
> > > end-to-end path, the routing algorithm selects a neighboring node to
> > > transmit to and then determines what convergence-layer endpoint (e.g.,
> > > UDP port number, LTP span, etc.) to transmit to in order to get the
> > > bundle to that node.  The routing is really orthogonal -- and
> > > complementary -- to late binding, which is a very late step
> > in the forwarding procedure.

From: "Cole, Robert G." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2009 11:28:53 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] dtn-interest Digest, Vol 18, Issue 27

I'll have to get it off of my army laptop tonight.

Bob
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, March 17, 2009 10:56 AM
To: [email-masked]
Subject: dtn-interest Digest, Vol 18, Issue 27

Send dtn-interest mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        http://maillists.intel-research.net/mailman/listinfo/dtn-interest
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dtn-interest digest..."

Today's Topics:

   1. Re: Naming and Addressing (Elwyn Davies)
   2. Re: Late Binding examples (Jason Redi)
   3. Re: Bundle Security Protocol - EID Ref  List (Peter Lovell)
   4. Re: Late Binding examples (Prithwish Basu)
   5. Re: Bundle Security Protocol - EID Ref  List (Symington, Susan F.)

----------------------------------------------------------------------

Message: 1
Date: Tue, 17 Mar 2009 11:11:59 +0000
From: Elwyn Davies <[email-masked]>
Subject: Re: [dtn-interest] Naming and Addressing
To: "Burleigh, Scott C" <[email-masked]>
Cc: dtn interest <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Burleigh, Scott C wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Ivancic,
>> William D. (GRC-RHN0)
>> Sent: Monday, March 16, 2009 9:27 PM
>> To: dtn interest
>> Subject: [dtn-interest] Naming and Addressing
>>
>> Naming and addressing is one of the points of technical discussion for the
>> DTNRG meetings March 19 and 20.  I thought I could get some discussion
>> started here.
>>
>> This discussion started on a NASA internal list, but we can bound the
>> problem there as Space is, in many ways, much simpler due to the size of
>> the network and the predictability of the network (at least for a space-
>> base backbone).
>>
>> The current DTN Bundling Architecture (not the bundling framework, rather
>> the architecture) really does not have a common lower layer address space.
>> At least that is the way it looks to me.  The bundle agent connects
>> directly to convergence layers with no DTN addressing scheme.
>>
>
> I would say you are right, Will: the DTN architecture doesn't have any notion of addresses that I am aware of.  Routing of a bundle is done on the basis of the *name* of its destination, not the address (which may well not be known to the sender or any relay point, because the destination node may be locally mobile).  "Late binding" in DTN is, essentially, the resolution of name to address at the last possible moment, in recognition of the significant chance that this resolution will change over the course of the bundle's progress from its source to its destination..
>
One way of expressing this is that the DTN name doesn't define the path
in advance.

Because of the overloading of IP addresses as both identifier and
locator, the choice of addresses at the source in IP effectively binds
the packet to a path through the IP network before the packet sets off.
One can quibble about the details (like load spreading across multiple
paths in the core, backup paths coming into play, rerouting) but for the
vast majority of packets the routing fate of the packet is known at the
time of  despatch. Originally just the destination address mattered.
Now the source and possibly some QoS bits may come into play but this
doesn't really change the situation. In IP the per-packet routing
'decision' at each router is not really a decision at all but a lookup.
The decision has been made previously by the control plane routing
protocol and the packet is tied to that path.  [Aside: The IP world has
come to be wedded to the path predestination 'principle' (dogma?).
Multipath routing is being considered in the research community but is
not mainstream.  Most, if not all, of the proposed fixes for the
multihoming problem and providing an id/locator split still cling to the
predestined path, although it may be a bit disguised.]

In DTN, particularly with the more opportunist encounter type of
network, there is a real decision to be made and this can be influenced
by aspects of the bundle, although I think that apart from size and
possibly custody requirements this hasn't had much effect as yet.
>
>> To me, it
>> would be desirable to have some type of topological and hierarchical
>> addressing scheme to aid in routing and security (something similar to IP-
>> tables).
>>
>
> That would clearly be one, very familiar way to support routing and security, but in my understanding of DTN it would not be the DTN way.
>
IMO it would be highly undesirable to take us down the path of a totally
hierarchical system.  Although it looks promising as a scaling
mechanism, the existing IP routing system shows that you have to be very
careful about what happens when it gets very big.  Also the notion of a
single authority that tends to be the follow on to a hierarchy doesn't
chime well with DTN.
>
>> However, because there is no common addressing scheme, a
>> multitude of DTN bundle agents looks like a flat network because I think
>> what we really have is  application-layer store and forward gateways that
>> can be graphically connected.  So in the strictest definition of a network
>> being related to graph theory, you sort of have a network.  But when one
>> looks at what one would expect from a network (things like a common
>> addressing scheme), it is not currently present.
>>
>
> Right, the network is different from IP in that routing is done on the basis of name, as far as possible, rather than on the basis of address.  This is one of the significant ways in which DTN differs from IP.
>
>
>> Wes Eddy pointed out the following:
>>
>> "The typical approach is to enable the split by setting up 2 sub-layers,
>> one with locators below and one with identifiers above.  In DTN, we have a
>> different approach.  An EID could be either a locator or an identifier
>> depending on how the EID scheme and forwarding on it are defined.  Inside a
>> bundle agent though, EIDs and next-hops have to map to convergence layer
>> addresses, which may or may not be locators themselves, but are definitely
>> the locators from a bundle agent's point-of-view as they basically specify
>> network coordinates at some specific time.
>>
>> So ... I'd say that an EID *can* be an address, though you don't often want
>> it to be one, but a set of convergence layer parameters is the real address
>> in the DTN architecture."
>>
>
> Right, there are no addresses in use at what serves as the "network protocol" within DTN (the Bundle Protocol), but there are addresses in use within the underlying convergence-layer protocols.  These are the addresses that are computed by "late binding".
>
And they are really only of point-to-point significance in one
forwarding hop.  On a multihop path, the convergence layer parameters
(essentially a token to send a bundle along a particular active link)
are a local mapping at each node that are not relevant once the bundle
has moved to the next node.
>
>> ---> Back to my thoughts <---
>>
>> I believe BBN is looking at running DTN as the network directly over a
>> meshed wireless ad hoc network.  Thus DTN is the upper layer network.
>> There is not IP network.  In this case, I believe they are using the radio
>> MAC and the Endpoint Identifier and realize this does not scale.  Also I am
>> not sure if this is a multi-radio system with one MAC address or something
>> else.  But it has been proven that naming the end system by the interface
>> is bad for multihoming.
>>
>
> If I understand you right, Will, I agree.  I think the way you get multihoming in DTN is by having multiple convergence-layer service access points (for, most likely, multiple convergence-layer protocols) at a single node.
>
I think there is some confusion here (as there often is in IP
discussions of multihoming) between the logical multihoming (typically a
service agreement between the end network and a service provider)  and
physical multihoming (having multiple independent network interfaces
available simultaneously).  In DTN networks a node may have multiple
physical interfaces (quite possibly using different  convergence-layer
protocols) but it can also have multiple logical links over a single
convergence layer (e.g., simultaneous ad hoc Wi-Fi connections).   And
there is the additional dimension that these links (unlike the usual IP
case) are not necessarily simultaneously active/available.  So, yes it
is probably not generally clever to identify a node with a single
interface, but that doesn't necessarily prevent it being multihomed if
the single interface is a wireless interface that can support multiple
ad hoc connections at once.

In most of the IP multihoming discussions we are talking about a hard
wired mapping between the administrative connections of a logically
multihomed node and the physical connections. IP early binding then
ought to tie a packet with given addresses to a path through one or
other of the links.  For a large proportion of DTN networks these
concepts are irrelevant, although gateways will generally have different
associations on either side.
>
>> I think we should address multi-homing and mobility at the onset.  Late-
>> binding might help us here.  Ignoring the problem in the past has resulted
>> in poor band-aid approaches to trying to get something to work later.
>>
>
> I agree that we should take multi-homing and mobility into account right from the beginning.
>
Absolutely.  Dealing (as I do) with 'data mule' type networks many of
the nodes are mobile, but early thinking only made them physically
mobile, keeping them essentially within one 'association'  (we aren't
allowed to call it a region  but  for the purposes of understanding
history, we were originally talking about nodes only encountering nodes
that live in a common area and have some common purpose making it useful
for them to talk to one another). We now have to allow at least some
nodes to be very mobile, associating with several other groups of DTN
nodes and occasionally migrating back into the (legacy) Internet.

I think the notion of association is a useful structuring mechanism, but
nodes need to be allowed to be members of multiple associations.
Associations could be recursive, but I don't want to go down the path of
a single hierarchy.

>
>> Perhaps the bundle agent identity does not have to be a URI, but some
>> unique identifier that can be bound to various URI's (aliased).  This might
>> help security.
>>
>
> In ION we address this by drawing a firm distinction between DTN endpoints and underlying convergence-layer protocol "ducts", with a managed mapping between the two.  The former are necessarily URIs, but the latter are not.
>
>
>> If we don't have a heretical addressing structure, perhaps we can develop a
>> hierarchical naming structure.
>>
>
> I think there are good reasons for not doing that in all cases, though.  Hierarchies are convenient, but they also tend to be inflexible and difficult to revise.
>
>
+1
>> Without some form or hierarchy, will DTNs be simple edge network gateways
>> do to an inability to scale the network?
>>
>
> I don't think so.  In some ways I think a flat namespace is actually more robust than a hierarchical address space.
>
I have been thinking about a hybrid (Scott saw some of this at Dagstuhl)
using the concept of associations to tie together nodes that have names
taken from a flat space so that routing can keep some sort of
prioritisation on information about nodes that it maintains and unknown
nodes can be routed via gateways. Nodes could have multiple associations
so that the mapping between associations and nodes is a directed graph
rather than a tree, and does not have a single root.

Regards,
Elwyn
> Scott
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

------------------------------

Message: 2
Date: Tue, 17 Mar 2009 07:54:55 -0400
From: "Jason Redi" <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples
To: "'Burleigh, Scott C'" <[email-masked]>,      "'dtn
        interest'" <[email-masked]>
Message-ID: <024901c9a6f7$33d30490$9b790db0$@com>
Content-Type: text/plain;       charset="us-ascii"

Scott,
Sorry -- but I don't understand how that is late-binding from your
description.  That sounds like regular old packet forwarding except that you
are breaking the choice of link (CLA) from the nexthop decision.  But I
don't see naming or addressing decisions involved anywhere.

Jason

---
 Dr. Jason K. Redi
 BBN Technologies
 10 Moulton St., Cambridge, MA, 02138
 [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Burleigh,
> Scott C
> Sent: Tuesday, March 17, 2009 2:45 AM
> To: dtn interest
> Subject: Re: [dtn-interest] Late Binding examples
>
> ION certainly uses late binding routinely.  At every hop on the end-to-
> end path, the routing algorithm selects a neighboring node to transmit
> to and then determines what convergence-layer endpoint (e.g., UDP port
> number, LTP span, etc.) to transmit to in order to get the bundle to
> that node.  The routing is really orthogonal -- and complementary -- to
> late binding, which is a very late step in the forwarding procedure.
>
> Scott
>
> > -----Original Message-----
> > From: [email-masked] [mailto:dtn-
> > [email-masked]] On Behalf Of Ivancic,
> > William D. (GRC-RHN0)
> > Sent: Monday, March 16, 2009 9:27 PM
> > To: dtn interest
> > Subject: [dtn-interest] Late Binding examples
> >
> >
> > One sort-of feature of DTN is late binding.  Has anyone implemented
> late-
> > binding (not to be confused with content-base routing/delivery)?  If
> so,
> > can you point me to some examples and what addressing scheme was
> used? I
> > ask because I am unaware of any implemented routing schemes that
> really do
> > late-binding.  This all is in relation to naming and addressing.  It
> seems
> > to me that late binding requires distributed name resolvers.
> >
> > Thanks,
> >
> >
> > /Will
> >
> >
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------------------------------

Message: 3
Date: Tue, 17 Mar 2009 08:13:54 -0400
From: Peter Lovell <[email-masked]>
Subject: Re: [dtn-interest] Bundle Security Protocol - EID Ref  List
To: "William D. (GRC-RCN0) Ivancic" <[email-masked]>,       dtn
        interest <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 16, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>
>I reread the BSP spec on the plane.  This is a very complicated spec and
>as such, interoperability testing should be interesting.
>
>Question,  Does the Source in the BSP EID reference list have to be the
>source or is it really the Identifier used to determine what Public Key
>or Shared Key to use for encryption / signing verification.  I am
>assuming this "source" EID has to be unique but I think this is more
>implied than actually stated as a MUST.  I raise the question when
>considering something like secure multicast in a DTN (non-source
>specific multicast).  Also, I may want to aliases my source name with
>one for security and another for routing, domain, or whatever.  As such,
>perhaps the source does not have to be a URI (actually I am not sure it
>states the EID has to be a URI here - it may just be implied).
>
>Likewise, can the Destination EID be a wild-carded destination (secure
>multicast)?
>
>
>/Will

Hi Will,

I certainly won't dispute the "complicated" part!

The EIDs in the EID list are references to actual EIDs. The EID text
itself is stored in the dictionary in the primary block, along with text
for the various other EIDs in the bundle.

I suppose the security-source would be unique, although BSP spec doesn't
require it. I can't presently think of a scenario where it would not be,
though. The security-destination could be wildcard of some sort - secure
multicast has been suggested and BSP will support that.

The rules etc for security-source and security-destination are the same
as for bundle-source and -destination, and the same naming rules apply.

To the other part of your question -- the key used for encrypt/decrypt/
sign/verify is specified in the "key information" item of security-
parameters. The latest version of the spec has added some additional
detail here (see section 2.7 on "Key Transport"). The idea is that the
ciphersuite packages the various things needed into this item, asn.1-
encoded as specified in CMS. Using PIB as an example, this might specify
a certificate (issuer and serial) containing an RSA public key to be
used to verify the payload signature. For PCB, the item might contain
both a certificate specification and the ephemeral key encrypted under
the RSA key.

In some scenarios you won't need the info about which key to use because
that will be implied by the security-source and/or security-destination.

Cheers.....Peter

------------------------------

Message: 4
Date: Tue, 17 Mar 2009 18:25:36 +0530
From: Prithwish Basu <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: dtn interest <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Will,

We have considered two flavors of "late binding" in the past, which I
thought I should summarize:

1) The next hop is specified is merely the EID of the node and not the
exact link over which the bundle will be forwarded. (Jason Redi's latest
email alludes to this as being a variant of the usual forwarding
mechanism). Indeed this may be more interesting in a scheduled link
scenario (say UAV flyover or a satellite rendezvous) where only the
remote EID may be known but not the CLA when this link is scheduled.
Routing decisions can be made using only the remote EID and perhaps some
approximate link cost information but the actual forwarding is
just-in-time and in some sense that is late binding. However the naming
scheme using for the remote EID doesn't have any CLA information and
that "binding" is internal to the DTN node.

2) Descriptive naming: (Maybe you're referring to this as content-based
delivery? I will describe this anyway) here the EID namespace can be
potentially complex (hence non-scalable) and there is an issue of
binding this name to the space of canonical EIDs (which using the rough
Internet analogy are the IP addresses of DTN, whereas the descriptive
names are DNS names). Hence there is a need for distributed name
resolvers. Here the scalability problems are twofold, one of namespace
management of the descriptive EIDs and the other of scalable routing
between canonical EIDs. So far we have considered flat namespaces for
the canonical EID routing, and a pseudo hierarchical descriptive
namespace (with geographic and non-geographic attributes). I realize
that this cannot be generally extended to all EIDs but is a use case.
You can find details of such names and some general description of the
distributed name resolver architecture, integrated name resolution and
routing etc. in the following paper:

Prithwish Basu, Rajesh Krishnan, and Daniel Brown, "Persistent Delivery
with Deferred Binding to Descriptively Named Destinations", in
Proceedings of MILCOM 2008. URL:
http://www.ir.bbn.com/~pbasu/pubs/milcom08.pdf

While the above architecture is general, the namescheme management may
not be scalable like arbitrarily hierarchical names. The latter can be
scalable with lack of mobility (or very little mobility) but once you
allow moderate to high mobility, things go haywire.

I believe (without proof:) that a certain fraction of nodes necessarily
have to be "fixed points" for a DTN routing scheme to be scalable for
arbitrary names and under arbitrary levels/patterns of mobility. (When I
say scalable here, I mean scalability as in IP single-homing).

-Prithwish

Ivancic, William D. (GRC-RHN0) wrote:
> One sort-of feature of DTN is late binding.  Has anyone implemented late-binding (not to be confused with content-base routing/delivery)?  If so, can you point me to some examples and what addressing scheme was used? I ask because I am unaware of any implemented routing schemes that really do late-binding.  This all is in relation to naming and addressing.  It seems to me that late binding requires distributed name resolvers.
>
> Thanks,
>
>
> /Will
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

------------------------------

Message: 5
Date: Tue, 17 Mar 2009 10:35:56 -0400
From: "Symington, Susan F." <[email-masked]>
Subject: Re: [dtn-interest] Bundle Security Protocol - EID Ref  List
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, dtn
        interest <[email-masked]>
Message-ID:
        <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Will,

I am assuming that when you refer to the "Source" in the BSP EID reference list" you really mean the "security source", and likewise, in your last sentence when you say "destination EID", you mean "security destination EID".

The security-source field in a BAB, if present, must identify the forwarder of the bundle. The security-source of the PIB, if present, must identify the node that inserted the PIB. The security-source of the PCB, if present, must identify the node that inserted the PCB. The security-source of the ESB, if present, must identify the node that inserted the ESB. The security-destination field in each of these blocks, if present identifies the node that is intended to validate/decrypt the security result in that block.

Each security block has space for ciphersuite parameters such as key information. The ciphersuite parameter that are used/required depend on the ciphersuite being used. When sending a bundle using the standard ciphersuite defined for the BAB, for example, key information can be included in the BAB to inform the receiver of what key to use. If key information is not included, however, the receiver is expected to be able to find the correct key to use based on the sender of the bundle (which is identified in the security-source field, if present). Likewise with the standard ciphersuite defined for the PIB.

So, I think the answer to the first part of your question is that the security source must identify the node that inserted the block, and it may also serve to identify the key used in the block, but it doesn't necessarily identify the key.

I am not sure I understand what you mean when you speculate as to whether there is a requirement that the security source be "unique".  Perhaps by a "unique" endpoint you mean an endpoint that never contains more than one node (a "singleton" endpoint) as opposed to an endpoint that may contain more than one node.  If this is your question, then the answer is that there is no restriction that the endpoint ID used to identify a security source or security destination must identify a singleton endpoint; these EIDs may identify an endpoint that contains more than one node.

Or do you mean that if a node identifies itself using a given endpoint ID then it will never use a different endpoint ID to identify itself?  If this is your question, then the answer is that a node may be a member of different endpoints and thus use different EIDs to identify itself.

The security source and security destination, if present, are found in the dictionary and as such they must be EIDs (and therefore they must take the form of URIs).

I hope this answers your questions.

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Ivancic,
>William D. (GRC-RHN0)
>Sent: Tuesday, March 17, 2009 12:27 AM
>To: dtn interest
>Subject: [dtn-interest] Bundle Security Protocol - EID Ref List
>
>
>I reread the BSP spec on the plane.  This is a very complicated spec and
>as such, interoperability testing should be interesting.
>
>Question,  Does the Source in the BSP EID reference list have to be the
>source or is it really the Identifier used to determine what Public Key
>or Shared Key to use for encryption / signing verification.  I am
>assuming this "source" EID has to be unique but I think this is more
>implied than actually stated as a MUST.  I raise the question when
>considering something like secure multicast in a DTN (non-source
>specific multicast).  Also, I may want to aliases my source name with
>one for security and another for routing, domain, or whatever.  As such,
>perhaps the source does not have to be a URI (actually I am not sure it
>states the EID has to be a URI here - it may just be implied).
>
>Likewise, can the Destination EID be a wild-carded destination (secure
>multicast)?
>
>
>
>
>
>
>/Will
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------------------------------

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

End of dtn-interest Digest, Vol 18, Issue 27
********************************************

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Burleigh, Scott C'" <[email-masked]>, "'dtn interest'" <[email-masked]>
Date: Tue, 17 Mar 2009 10:19:46 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Late Binding examples

-----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Jason Redi
> Sent: Tuesday, March 17, 2009 7:55 AM
> To: 'Burleigh, Scott C'; 'dtn interest'
> Subject: Re: [dtn-interest] Late Binding examples
> 
> Scott,
> Sorry -- but I don't understand how that is late-binding from 
> your description.  That sounds like regular old packet 
> forwarding except that you are breaking the choice of link 
> (CLA) from the nexthop decision.  But I don't see naming or 
> addressing decisions involved anywhere.
> 
> Jason
>

I agree that Scott's example is not what I consider late binding but rather DTN routing.  In fact, the way contact graph routing works, I believe you actually have early  binding.  You have to know pretty much where every node will be at all times to generate a contact graph.  That is early binding.  If you were sending to rove-24 on the moon and so you forwarded the message to the moon and then the moon gateway figured out the rest, that would be late binding - at least as I understand it.

Will

> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:dtn- 
> > [email-masked]] On Behalf Of 
> Burleigh, 
> > Scott C
> > Sent: Tuesday, March 17, 2009 2:45 AM
> > To: dtn interest
> > Subject: Re: [dtn-interest] Late Binding examples
> > 
> > ION certainly uses late binding routinely.  At every hop on the 
> > end-to- end path, the routing algorithm selects a 
> neighboring node to 
> > transmit to and then determines what convergence-layer 
> endpoint (e.g., 
> > UDP port number, LTP span, etc.) to transmit to in order to get the 
> > bundle to that node.  The routing is really orthogonal -- and 
> > complementary -- to late binding, which is a very late step 
> in the forwarding procedure.
> > 
> > Scott
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:dtn- 
> > > [email-masked]] On Behalf 
> Of Ivancic, 
> > > William D. (GRC-RHN0)
> > > Sent: Monday, March 16, 2009 9:27 PM
> > > To: dtn interest
> > > Subject: [dtn-interest] Late Binding examples
> > >
> > >
> > > One sort-of feature of DTN is late binding.  Has anyone 
> implemented
> > late-
> > > binding (not to be confused with content-base 
> routing/delivery)?  If
> > so,
> > > can you point me to some examples and what addressing scheme was
> > used? I
> > > ask because I am unaware of any implemented routing schemes that
> > really do
> > > late-binding.  This all is in relation to naming and 
> addressing.  It
> > seems
> > > to me that late binding requires distributed name resolvers.
> > >
> > > Thanks,
> > >
> > >
> > > /Will
> > >
> > >
> > >
> > > _______________________________________________
> > > dtn-interest mailing list
> > > [email-masked]
> > > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> > 
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Burleigh, Scott C" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'dtn interest'" <[email-masked]>
Date: Tue, 17 Mar 2009 08:12:26 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Late Binding examples

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jason Redi
> Sent: Tuesday, March 17, 2009 4:55 AM
> To: Burleigh, Scott C; 'dtn interest'
> Subject: RE: [dtn-interest] Late Binding examples
> 
> Scott,
> Sorry -- but I don't understand how that is late-binding from your
> description.  That sounds like regular old packet forwarding except that you
> are breaking the choice of link (CLA) from the nexthop decision.  But I
> don't see naming or addressing decisions involved anywhere.

Let me amplify.  My understanding of "late binding" is that we look up the final destination address at the last possible moment, i.e., we use the final destination's name -- rather than its address -- as the basis for route computation.  That's what ION does: at each node on the end-to-end path, the final destination endpoint name is used as the basis for selecting the next neighbor node (again identified by name, not address) to transmit to, and then that transmission is accomplished by mapping that next-neighbor name to an "outduct" -- which might be to an IP address or might be to some other sort of service access point such as an LTP engine ID.

Scott

> ---
>  Dr. Jason K. Redi
>  BBN Technologies
>  10 Moulton St., Cambridge, MA, 02138
>  [email-masked]
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:dtn-
> > [email-masked]] On Behalf Of Burleigh,
> > Scott C
> > Sent: Tuesday, March 17, 2009 2:45 AM
> > To: dtn interest
> > Subject: Re: [dtn-interest] Late Binding examples
> >
> > ION certainly uses late binding routinely.  At every hop on the end-to-
> > end path, the routing algorithm selects a neighboring node to transmit
> > to and then determines what convergence-layer endpoint (e.g., UDP port
> > number, LTP span, etc.) to transmit to in order to get the bundle to
> > that node.  The routing is really orthogonal -- and complementary -- to
> > late binding, which is a very late step in the forwarding procedure.
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:dtn-
> > > [email-masked]] On Behalf Of Ivancic,
> > > William D. (GRC-RHN0)
> > > Sent: Monday, March 16, 2009 9:27 PM
> > > To: dtn interest
> > > Subject: [dtn-interest] Late Binding examples
> > >
> > >
> > > One sort-of feature of DTN is late binding.  Has anyone implemented
> > late-
> > > binding (not to be confused with content-base routing/delivery)?  If
> > so,
> > > can you point me to some examples and what addressing scheme was
> > used? I
> > > ask because I am unaware of any implemented routing schemes that
> > really do
> > > late-binding.  This all is in relation to naming and addressing.  It
> > seems
> > > to me that late binding requires distributed name resolvers.
> > >
> > > Thanks,
> > >
> > >
> > > /Will
> > >
> > >
> > >
> > > _______________________________________________
> > > dtn-interest mailing list
> > > [email-masked]
> > > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Symington, Susan F." <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 10:35:56 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Bundle Security Protocol - EID Ref  List

Will,

I am assuming that when you refer to the "Source" in the BSP EID reference list" you really mean the "security source", and likewise, in your last sentence when you say "destination EID", you mean "security destination EID".

The security-source field in a BAB, if present, must identify the forwarder of the bundle. The security-source of the PIB, if present, must identify the node that inserted the PIB. The security-source of the PCB, if present, must identify the node that inserted the PCB. The security-source of the ESB, if present, must identify the node that inserted the ESB. The security-destination field in each of these blocks, if present identifies the node that is intended to validate/decrypt the security result in that block. 

Each security block has space for ciphersuite parameters such as key information. The ciphersuite parameter that are used/required depend on the ciphersuite being used. When sending a bundle using the standard ciphersuite defined for the BAB, for example, key information can be included in the BAB to inform the receiver of what key to use. If key information is not included, however, the receiver is expected to be able to find the correct key to use based on the sender of the bundle (which is identified in the security-source field, if present). Likewise with the standard ciphersuite defined for the PIB.

So, I think the answer to the first part of your question is that the security source must identify the node that inserted the block, and it may also serve to identify the key used in the block, but it doesn't necessarily identify the key.

I am not sure I understand what you mean when you speculate as to whether there is a requirement that the security source be "unique".  Perhaps by a "unique" endpoint you mean an endpoint that never contains more than one node (a "singleton" endpoint) as opposed to an endpoint that may contain more than one node.  If this is your question, then the answer is that there is no restriction that the endpoint ID used to identify a security source or security destination must identify a singleton endpoint; these EIDs may identify an endpoint that contains more than one node. 

Or do you mean that if a node identifies itself using a given endpoint ID then it will never use a different endpoint ID to identify itself?  If this is your question, then the answer is that a node may be a member of different endpoints and thus use different EIDs to identify itself.  

The security source and security destination, if present, are found in the dictionary and as such they must be EIDs (and therefore they must take the form of URIs).

I hope this answers your questions.

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Ivancic,
>William D. (GRC-RHN0)
>Sent: Tuesday, March 17, 2009 12:27 AM
>To: dtn interest
>Subject: [dtn-interest] Bundle Security Protocol - EID Ref List
>
>
>I reread the BSP spec on the plane.  This is a very complicated spec and
>as such, interoperability testing should be interesting.
>
>Question,  Does the Source in the BSP EID reference list have to be the
>source or is it really the Identifier used to determine what Public Key
>or Shared Key to use for encryption / signing verification.  I am
>assuming this "source" EID has to be unique but I think this is more
>implied than actually stated as a MUST.  I raise the question when
>considering something like secure multicast in a DTN (non-source
>specific multicast).  Also, I may want to aliases my source name with
>one for security and another for routing, domain, or whatever.  As such,
>perhaps the source does not have to be a URI (actually I am not sure it
>states the EID has to be a URI here - it may just be implied).
>
>Likewise, can the Destination EID be a wild-carded destination (secure
>multicast)?
>
>
>
>
>
>
>/Will
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 17 Mar 2009 18:25:36 +0530
From: Prithwish Basu <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples

Hi Will,

We have considered two flavors of "late binding" in the past, which I 
thought I should summarize:

1) The next hop is specified is merely the EID of the node and not the 
exact link over which the bundle will be forwarded. (Jason Redi's latest 
email alludes to this as being a variant of the usual forwarding 
mechanism). Indeed this may be more interesting in a scheduled link 
scenario (say UAV flyover or a satellite rendezvous) where only the 
remote EID may be known but not the CLA when this link is scheduled. 
Routing decisions can be made using only the remote EID and perhaps some 
approximate link cost information but the actual forwarding is 
just-in-time and in some sense that is late binding. However the naming 
scheme using for the remote EID doesn't have any CLA information and 
that "binding" is internal to the DTN node.

2) Descriptive naming: (Maybe you're referring to this as content-based 
delivery? I will describe this anyway) here the EID namespace can be 
potentially complex (hence non-scalable) and there is an issue of 
binding this name to the space of canonical EIDs (which using the rough 
Internet analogy are the IP addresses of DTN, whereas the descriptive 
names are DNS names). Hence there is a need for distributed name 
resolvers. Here the scalability problems are twofold, one of namespace 
management of the descriptive EIDs and the other of scalable routing 
between canonical EIDs. So far we have considered flat namespaces for 
the canonical EID routing, and a pseudo hierarchical descriptive 
namespace (with geographic and non-geographic attributes). I realize 
that this cannot be generally extended to all EIDs but is a use case. 
You can find details of such names and some general description of the 
distributed name resolver architecture, integrated name resolution and 
routing etc. in the following paper:

Prithwish Basu, Rajesh Krishnan, and Daniel Brown, "Persistent Delivery 
with Deferred Binding to Descriptively Named Destinations", in 
Proceedings of MILCOM 2008. URL: 
http://www.ir.bbn.com/~pbasu/pubs/milcom08.pdf

While the above architecture is general, the namescheme management may 
not be scalable like arbitrarily hierarchical names. The latter can be 
scalable with lack of mobility (or very little mobility) but once you 
allow moderate to high mobility, things go haywire.

I believe (without proof:) that a certain fraction of nodes necessarily 
have to be "fixed points" for a DTN routing scheme to be scalable for 
arbitrary names and under arbitrary levels/patterns of mobility. (When I 
say scalable here, I mean scalability as in IP single-homing).

-Prithwish

Ivancic, William D. (GRC-RHN0) wrote:
> One sort-of feature of DTN is late binding.  Has anyone implemented late-binding (not to be confused with content-base routing/delivery)?  If so, can you point me to some examples and what addressing scheme was used? I ask because I am unaware of any implemented routing schemes that really do late-binding.  This all is in relation to naming and addressing.  It seems to me that late binding requires distributed name resolvers.   
>
> Thanks,
>
>
> /Will
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>   

From: Peter Lovell <[email-masked]>
To: "William D. (GRC-RCN0) Ivancic" <[email-masked]>, dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 08:13:54 -0400
Subject: Re: [dtn-interest] Bundle Security Protocol - EID Ref  List

On Mon, Mar 16, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>
>I reread the BSP spec on the plane.  This is a very complicated spec and
>as such, interoperability testing should be interesting.
>
>Question,  Does the Source in the BSP EID reference list have to be the
>source or is it really the Identifier used to determine what Public Key
>or Shared Key to use for encryption / signing verification.  I am
>assuming this "source" EID has to be unique but I think this is more
>implied than actually stated as a MUST.  I raise the question when
>considering something like secure multicast in a DTN (non-source
>specific multicast).  Also, I may want to aliases my source name with
>one for security and another for routing, domain, or whatever.  As such,
>perhaps the source does not have to be a URI (actually I am not sure it
>states the EID has to be a URI here - it may just be implied).
>
>Likewise, can the Destination EID be a wild-carded destination (secure
>multicast)?
>
>
>/Will

Hi Will,

I certainly won't dispute the "complicated" part!

The EIDs in the EID list are references to actual EIDs. The EID text
itself is stored in the dictionary in the primary block, along with text
for the various other EIDs in the bundle.

I suppose the security-source would be unique, although BSP spec doesn't
require it. I can't presently think of a scenario where it would not be,
though. The security-destination could be wildcard of some sort - secure
multicast has been suggested and BSP will support that.

The rules etc for security-source and security-destination are the same
as for bundle-source and -destination, and the same naming rules apply.

To the other part of your question -- the key used for encrypt/decrypt/
sign/verify is specified in the "key information" item of security-
parameters. The latest version of the spec has added some additional
detail here (see section 2.7 on "Key Transport"). The idea is that the
ciphersuite packages the various things needed into this item, asn.1-
encoded as specified in CMS. Using PIB as an example, this might specify
a certificate (issuer and serial) containing an RSA public key to be
used to verify the payload signature. For PCB, the item might contain
both a certificate specification and the ephemeral key encrypted under
the RSA key.

In some scenarios you won't need the info about which key to use because
that will be implied by the security-source and/or security-destination.

Cheers.....Peter

From: "Jason Redi" <[email-masked]>
To: "'Burleigh, Scott C'" <[email-masked]>, "'dtn interest'" <[email-masked]>
Date: Tue, 17 Mar 2009 07:54:55 -0400
Organization: BBN Technologies
Sender: [email-masked]
Subject: Re: [dtn-interest] Late Binding examples
Reply-To: [email-masked]

Scott,
Sorry -- but I don't understand how that is late-binding from your
description.  That sounds like regular old packet forwarding except that you
are breaking the choice of link (CLA) from the nexthop decision.  But I
don't see naming or addressing decisions involved anywhere.

Jason

---
 Dr. Jason K. Redi
 BBN Technologies                               
 10 Moulton St., Cambridge, MA, 02138
 [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Burleigh,
> Scott C
> Sent: Tuesday, March 17, 2009 2:45 AM
> To: dtn interest
> Subject: Re: [dtn-interest] Late Binding examples
> 
> ION certainly uses late binding routinely.  At every hop on the end-to-
> end path, the routing algorithm selects a neighboring node to transmit
> to and then determines what convergence-layer endpoint (e.g., UDP port
> number, LTP span, etc.) to transmit to in order to get the bundle to
> that node.  The routing is really orthogonal -- and complementary -- to
> late binding, which is a very late step in the forwarding procedure.
> 
> Scott
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:dtn-
> > [email-masked]] On Behalf Of Ivancic,
> > William D. (GRC-RHN0)
> > Sent: Monday, March 16, 2009 9:27 PM
> > To: dtn interest
> > Subject: [dtn-interest] Late Binding examples
> >
> >
> > One sort-of feature of DTN is late binding.  Has anyone implemented
> late-
> > binding (not to be confused with content-base routing/delivery)?  If
> so,
> > can you point me to some examples and what addressing scheme was
> used? I
> > ask because I am unaware of any implemented routing schemes that
> really do
> > late-binding.  This all is in relation to naming and addressing.  It
> seems
> > to me that late binding requires distributed name resolvers.
> >
> > Thanks,
> >
> >
> > /Will
> >
> >
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 17 Mar 2009 11:11:59 +0000
From: Elwyn Davies <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Naming and Addressing

Burleigh, Scott C wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Ivancic,
>> William D. (GRC-RHN0)
>> Sent: Monday, March 16, 2009 9:27 PM
>> To: dtn interest
>> Subject: [dtn-interest] Naming and Addressing
>>
>> Naming and addressing is one of the points of technical discussion for the
>> DTNRG meetings March 19 and 20.  I thought I could get some discussion
>> started here.
>>
>> This discussion started on a NASA internal list, but we can bound the
>> problem there as Space is, in many ways, much simpler due to the size of
>> the network and the predictability of the network (at least for a space-
>> base backbone).
>>
>> The current DTN Bundling Architecture (not the bundling framework, rather
>> the architecture) really does not have a common lower layer address space.
>> At least that is the way it looks to me.  The bundle agent connects
>> directly to convergence layers with no DTN addressing scheme.
>>     
>
> I would say you are right, Will: the DTN architecture doesn't have any notion of addresses that I am aware of.  Routing of a bundle is done on the basis of the *name* of its destination, not the address (which may well not be known to the sender or any relay point, because the destination node may be locally mobile).  "Late binding" in DTN is, essentially, the resolution of name to address at the last possible moment, in recognition of the significant chance that this resolution will change over the course of the bundle's progress from its source to its destination..
>   
One way of expressing this is that the DTN name doesn't define the path 
in advance.

Because of the overloading of IP addresses as both identifier and 
locator, the choice of addresses at the source in IP effectively binds 
the packet to a path through the IP network before the packet sets off.  
One can quibble about the details (like load spreading across multiple 
paths in the core, backup paths coming into play, rerouting) but for the 
vast majority of packets the routing fate of the packet is known at the 
time of  despatch. Originally just the destination address mattered.  
Now the source and possibly some QoS bits may come into play but this 
doesn't really change the situation. In IP the per-packet routing 
'decision' at each router is not really a decision at all but a lookup.  
The decision has been made previously by the control plane routing 
protocol and the packet is tied to that path.  [Aside: The IP world has 
come to be wedded to the path predestination 'principle' (dogma?).  
Multipath routing is being considered in the research community but is 
not mainstream.  Most, if not all, of the proposed fixes for the 
multihoming problem and providing an id/locator split still cling to the 
predestined path, although it may be a bit disguised.]

In DTN, particularly with the more opportunist encounter type of 
network, there is a real decision to be made and this can be influenced 
by aspects of the bundle, although I think that apart from size and 
possibly custody requirements this hasn't had much effect as yet.
>   
>> To me, it
>> would be desirable to have some type of topological and hierarchical
>> addressing scheme to aid in routing and security (something similar to IP-
>> tables).
>>     
>
> That would clearly be one, very familiar way to support routing and security, but in my understanding of DTN it would not be the DTN way.
>   
IMO it would be highly undesirable to take us down the path of a totally 
hierarchical system.  Although it looks promising as a scaling 
mechanism, the existing IP routing system shows that you have to be very 
careful about what happens when it gets very big.  Also the notion of a 
single authority that tends to be the follow on to a hierarchy doesn't 
chime well with DTN.
>   
>> However, because there is no common addressing scheme, a
>> multitude of DTN bundle agents looks like a flat network because I think
>> what we really have is  application-layer store and forward gateways that
>> can be graphically connected.  So in the strictest definition of a network
>> being related to graph theory, you sort of have a network.  But when one
>> looks at what one would expect from a network (things like a common
>> addressing scheme), it is not currently present.
>>     
>
> Right, the network is different from IP in that routing is done on the basis of name, as far as possible, rather than on the basis of address.  This is one of the significant ways in which DTN differs from IP.
>
>   
>> Wes Eddy pointed out the following:
>>
>> "The typical approach is to enable the split by setting up 2 sub-layers,
>> one with locators below and one with identifiers above.  In DTN, we have a
>> different approach.  An EID could be either a locator or an identifier
>> depending on how the EID scheme and forwarding on it are defined.  Inside a
>> bundle agent though, EIDs and next-hops have to map to convergence layer
>> addresses, which may or may not be locators themselves, but are definitely
>> the locators from a bundle agent's point-of-view as they basically specify
>> network coordinates at some specific time.
>>
>> So ... I'd say that an EID *can* be an address, though you don't often want
>> it to be one, but a set of convergence layer parameters is the real address
>> in the DTN architecture."
>>     
>
> Right, there are no addresses in use at what serves as the "network protocol" within DTN (the Bundle Protocol), but there are addresses in use within the underlying convergence-layer protocols.  These are the addresses that are computed by "late binding".
>   
And they are really only of point-to-point significance in one 
forwarding hop.  On a multihop path, the convergence layer parameters 
(essentially a token to send a bundle along a particular active link) 
are a local mapping at each node that are not relevant once the bundle 
has moved to the next node.
>   
>> ---> Back to my thoughts <---
>>
>> I believe BBN is looking at running DTN as the network directly over a
>> meshed wireless ad hoc network.  Thus DTN is the upper layer network.
>> There is not IP network.  In this case, I believe they are using the radio
>> MAC and the Endpoint Identifier and realize this does not scale.  Also I am
>> not sure if this is a multi-radio system with one MAC address or something
>> else.  But it has been proven that naming the end system by the interface
>> is bad for multihoming.
>>     
>
> If I understand you right, Will, I agree.  I think the way you get multihoming in DTN is by having multiple convergence-layer service access points (for, most likely, multiple convergence-layer protocols) at a single node.
>   
I think there is some confusion here (as there often is in IP 
discussions of multihoming) between the logical multihoming (typically a 
service agreement between the end network and a service provider)  and 
physical multihoming (having multiple independent network interfaces 
available simultaneously).  In DTN networks a node may have multiple 
physical interfaces (quite possibly using different  convergence-layer 
protocols) but it can also have multiple logical links over a single 
convergence layer (e.g., simultaneous ad hoc Wi-Fi connections).   And 
there is the additional dimension that these links (unlike the usual IP 
case) are not necessarily simultaneously active/available.  So, yes it 
is probably not generally clever to identify a node with a single 
interface, but that doesn't necessarily prevent it being multihomed if 
the single interface is a wireless interface that can support multiple 
ad hoc connections at once.

In most of the IP multihoming discussions we are talking about a hard 
wired mapping between the administrative connections of a logically 
multihomed node and the physical connections. IP early binding then 
ought to tie a packet with given addresses to a path through one or 
other of the links.  For a large proportion of DTN networks these 
concepts are irrelevant, although gateways will generally have different 
associations on either side.
>   
>> I think we should address multi-homing and mobility at the onset.  Late-
>> binding might help us here.  Ignoring the problem in the past has resulted
>> in poor band-aid approaches to trying to get something to work later.
>>     
>
> I agree that we should take multi-homing and mobility into account right from the beginning.
>   
Absolutely.  Dealing (as I do) with 'data mule' type networks many of 
the nodes are mobile, but early thinking only made them physically 
mobile, keeping them essentially within one 'association'  (we aren't 
allowed to call it a region  but  for the purposes of understanding 
history, we were originally talking about nodes only encountering nodes 
that live in a common area and have some common purpose making it useful 
for them to talk to one another). We now have to allow at least some 
nodes to be very mobile, associating with several other groups of DTN 
nodes and occasionally migrating back into the (legacy) Internet.

I think the notion of association is a useful structuring mechanism, but 
nodes need to be allowed to be members of multiple associations.  
Associations could be recursive, but I don't want to go down the path of 
a single hierarchy.

>   
>> Perhaps the bundle agent identity does not have to be a URI, but some
>> unique identifier that can be bound to various URI's (aliased).  This might
>> help security.
>>     
>
> In ION we address this by drawing a firm distinction between DTN endpoints and underlying convergence-layer protocol "ducts", with a managed mapping between the two.  The former are necessarily URIs, but the latter are not.
>
>   
>> If we don't have a heretical addressing structure, perhaps we can develop a
>> hierarchical naming structure.
>>     
>
> I think there are good reasons for not doing that in all cases, though.  Hierarchies are convenient, but they also tend to be inflexible and difficult to revise.
>
>   
+1
>> Without some form or hierarchy, will DTNs be simple edge network gateways
>> do to an inability to scale the network?
>>     
>
> I don't think so.  In some ways I think a flat namespace is actually more robust than a hierarchical address space.
>   
I have been thinking about a hybrid (Scott saw some of this at Dagstuhl) 
using the concept of associations to tie together nodes that have names 
taken from a flat space so that routing can keep some sort of 
prioritisation on information about nodes that it maintains and unknown 
nodes can be routed via gateways. Nodes could have multiple associations 
so that the mapping between associations and nodes is a directed graph 
rather than a tree, and does not have a single root.

Regards,
Elwyn
> Scott
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

Date: Tue, 17 Mar 2009 09:53:07 +0000
From: Elwyn Davies <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Late Binding examples

I believe that a much earlier, IP related example, was the Nimrod 
routing and addressing scheme championed by No�l Chiappa in the early 
1990's.  This was in the 'long list' for IPng (later known as IPv6) but 
was rejected as 'still too researchy' when the short list was formed.  
This was a map based scheme whereby packets were forwarded towards their 
destination based on a 'low resolution' map that identified a gateway 
where a higher resolution map could be used to produce more closely 
focussed identification.  This process could be repeated as many times 
as required.  Considerable progress was made both theoretically and 
towards an implementation, but work was eventually abandoned before 
completion after Nimrod was rejected as an IPng candidate. I believe 
this is a form of late binding. The routing decision process was 
intended to be based on abstract maps exchanged between nodes.

The Nimrod ideas were also fed into the PNNI protocol designed for ATM 
networks.  This was implemented fully but has never been seriously 
deployed because large scale ATM never came to pass.  It used long names 
and an abstract map exchange based approach. 

There are more details and references in sections 3.3 and 3.4 of 
http://tools.ietf.org/html/draft-irtf-routing-history-10.

PNNI in particular was (IMO) flawed because it ultimately relied (as 
does the IP routing system) on a single top level authority in some form 
- there is a single tree structure at least in the 
authorization/authentication of the maps.  In a future DTN network that 
should not be the case.  I don't believe that Nimrod was intended to go 
that way either.

Joel Halpern who is still around the IETF was closely involved in the 
design and implementation of PNNI.  I have talked with him briefly about 
PNNI from an historical perspective but he may have some additional 
insights that could be instructive.

Regards,
Elwyn

Burleigh, Scott C wrote:
> ION certainly uses late binding routinely.  At every hop on the end-to-end path, the routing algorithm selects a neighboring node to transmit to and then determines what convergence-layer endpoint (e.g., UDP port number, LTP span, etc.) to transmit to in order to get the bundle to that node.  The routing is really orthogonal -- and complementary -- to late binding, which is a very late step in the forwarding procedure.
>
> Scott
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Ivancic,
>> William D. (GRC-RHN0)
>> Sent: Monday, March 16, 2009 9:27 PM
>> To: dtn interest
>> Subject: [dtn-interest] Late Binding examples
>>
>>
>> One sort-of feature of DTN is late binding.  Has anyone implemented late-
>> binding (not to be confused with content-base routing/delivery)?  If so,
>> can you point me to some examples and what addressing scheme was used? I
>> ask because I am unaware of any implemented routing schemes that really do
>> late-binding.  This all is in relation to naming and addressing.  It seems
>> to me that late binding requires distributed name resolvers.
>>
>> Thanks,
>>
>>
>> /Will
>>
>>     

From: "Burleigh, Scott C" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Tue, 17 Mar 2009 00:12:43 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Naming and Addressing

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Ivancic,
> William D. (GRC-RHN0)
> Sent: Monday, March 16, 2009 9:27 PM
> To: dtn interest
> Subject: [dtn-interest] Naming and Addressing
> 
> Naming and addressing is one of the points of technical discussion for the
> DTNRG meetings March 19 and 20.  I thought I could get some discussion
> started here.
> 
> This discussion started on a NASA internal list, but we can bound the
> problem there as Space is, in many ways, much simpler due to the size of
> the network and the predictability of the network (at least for a space-
> base backbone).
> 
> The current DTN Bundling Architecture (not the bundling framework, rather
> the architecture) really does not have a common lower layer address space.
> At least that is the way it looks to me.  The bundle agent connects
> directly to convergence layers with no DTN addressing scheme.

I would say you are right, Will: the DTN architecture doesn't have any notion of addresses that I am aware of.  Routing of a bundle is done on the basis of the *name* of its destination, not the address (which may well not be known to the sender or any relay point, because the destination node may be locally mobile).  "Late binding" in DTN is, essentially, the resolution of name to address at the last possible moment, in recognition of the significant chance that this resolution will change over the course of the bundle's progress from its source to its destination..

> To me, it
> would be desirable to have some type of topological and hierarchical
> addressing scheme to aid in routing and security (something similar to IP-
> tables).

That would clearly be one, very familiar way to support routing and security, but in my understanding of DTN it would not be the DTN way.

> However, because there is no common addressing scheme, a
> multitude of DTN bundle agents looks like a flat network because I think
> what we really have is  application-layer store and forward gateways that
> can be graphically connected.  So in the strictest definition of a network
> being related to graph theory, you sort of have a network.  But when one
> looks at what one would expect from a network (things like a common
> addressing scheme), it is not currently present.

Right, the network is different from IP in that routing is done on the basis of name, as far as possible, rather than on the basis of address.  This is one of the significant ways in which DTN differs from IP.

> Wes Eddy pointed out the following:
> 
> "The typical approach is to enable the split by setting up 2 sub-layers,
> one with locators below and one with identifiers above.  In DTN, we have a
> different approach.  An EID could be either a locator or an identifier
> depending on how the EID scheme and forwarding on it are defined.  Inside a
> bundle agent though, EIDs and next-hops have to map to convergence layer
> addresses, which may or may not be locators themselves, but are definitely
> the locators from a bundle agent's point-of-view as they basically specify
> network coordinates at some specific time.
> 
> So ... I'd say that an EID *can* be an address, though you don't often want
> it to be one, but a set of convergence layer parameters is the real address
> in the DTN architecture."

Right, there are no addresses in use at what serves as the "network protocol" within DTN (the Bundle Protocol), but there are addresses in use within the underlying convergence-layer protocols.  These are the addresses that are computed by "late binding".

> ---> Back to my thoughts <---
> 
> I believe BBN is looking at running DTN as the network directly over a
> meshed wireless ad hoc network.  Thus DTN is the upper layer network.
> There is not IP network.  In this case, I believe they are using the radio
> MAC and the Endpoint Identifier and realize this does not scale.  Also I am
> not sure if this is a multi-radio system with one MAC address or something
> else.  But it has been proven that naming the end system by the interface
> is bad for multihoming.

If I understand you right, Will, I agree.  I think the way you get multihoming in DTN is by having multiple convergence-layer service access points (for, most likely, multiple convergence-layer protocols) at a single node.

> I think we should address multi-homing and mobility at the onset.  Late-
> binding might help us here.  Ignoring the problem in the past has resulted
> in poor band-aid approaches to trying to get something to work later.

I agree that we should take multi-homing and mobility into account right from the beginning.

> Perhaps the bundle agent identity does not have to be a URI, but some
> unique identifier that can be bound to various URI's (aliased).  This might
> help security.

In ION we address this by drawing a firm distinction between DTN endpoints and underlying convergence-layer protocol "ducts", with a managed mapping between the two.  The former are necessarily URIs, but the latter are not.

> If we don't have a heretical addressing structure, perhaps we can develop a
> hierarchical naming structure.

I think there are good reasons for not doing that in all cases, though.  Hierarchies are convenient, but they also tend to be inflexible and difficult to revise.

> Without some form or hierarchy, will DTNs be simple edge network gateways
> do to an inability to scale the network?

I don't think so.  In some ways I think a flat namespace is actually more robust than a hierarchical address space.

Scott

From: "Burleigh, Scott C" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Mon, 16 Mar 2009 23:44:54 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Late Binding examples

ION certainly uses late binding routinely.  At every hop on the end-to-end path, the routing algorithm selects a neighboring node to transmit to and then determines what convergence-layer endpoint (e.g., UDP port number, LTP span, etc.) to transmit to in order to get the bundle to that node.  The routing is really orthogonal -- and complementary -- to late binding, which is a very late step in the forwarding procedure.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Ivancic,
> William D. (GRC-RHN0)
> Sent: Monday, March 16, 2009 9:27 PM
> To: dtn interest
> Subject: [dtn-interest] Late Binding examples
> 
> 
> One sort-of feature of DTN is late binding.  Has anyone implemented late-
> binding (not to be confused with content-base routing/delivery)?  If so,
> can you point me to some examples and what addressing scheme was used? I
> ask because I am unaware of any implemented routing schemes that really do
> late-binding.  This all is in relation to naming and addressing.  It seems
> to me that late binding requires distributed name resolvers.
> 
> Thanks,
> 
> 
> /Will
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Mon, 16 Mar 2009 23:26:37 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Naming and Addressing

Naming and addressing is one of the points of technical discussion for the DTNRG meetings March 19 and 20.  I thought I could get some discussion started here.

This discussion started on a NASA internal list, but we can bound the problem there as Space is, in many ways, much simpler due to the size of the network and the predictability of the network (at least for a space-base backbone).

The current DTN Bundling Architecture (not the bundling framework, rather the architecture) really does not have a common lower layer address space.  At least that is the way it looks to me.  The bundle agent connects directly to convergence layers with no DTN addressing scheme.  To me, it would be desirable to have some type of topological and hierarchical addressing scheme to aid in routing and security (something similar to IP-tables).  However, because there is no common addressing scheme, a multitude of DTN bundle agents looks like a flat network because I think what we really have is  application-layer store and forward gateways that can be graphically connected.  So in the strictest definition of a network being related to graph theory, you sort of have a network.  But when one looks at what one would expect from a network (things like a common addressing scheme), it is not currently present. 

Wes Eddy pointed out the following:

"The typical approach is to enable the split by setting up 2 sub-layers, one with locators below and one with identifiers above.  In DTN, we have a different approach.  An EID could be either a locator or an identifier depending on how the EID scheme and forwarding on it are defined.  Inside a bundle agent though, EIDs and next-hops have to map to convergence layer addresses, which may or may not be locators themselves, but are definitely the locators from a bundle agent's point-of-view as they basically specify network coordinates at some specific time.

So ... I'd say that an EID *can* be an address, though you don't often want it to be one, but a set of convergence layer parameters is the real address in the DTN architecture."

---> Back to my thoughts <---

I believe BBN is looking at running DTN as the network directly over a meshed wireless ad hoc network.  Thus DTN is the upper layer network.  There is not IP network.  In this case, I believe they are using the radio MAC and the Endpoint Identifier and realize this does not scale.  Also I am not sure if this is a multi-radio system with one MAC address or something else.  But it has been proven that naming the end system by the interface is bad for multihoming.

I think we should address multi-homing and mobility at the onset.  Late-binding might help us here.  Ignoring the problem in the past has resulted in poor band-aid approaches to trying to get something to work later.

Perhaps the bundle agent identity does not have to be a URI, but some unique identifier that can be bound to various URI's (aliased).  This might help security.  

If we don't have a heretical addressing structure, perhaps we can develop a hierarchical naming structure.

Without some form or hierarchy, will DTNs be simple edge network gateways do to an inability to scale the network?

/Will

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Mon, 16 Mar 2009 23:26:35 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Bundle Security Protocol - EID Ref  List

I reread the BSP spec on the plane.  This is a very complicated spec and as such, interoperability testing should be interesting.

Question,  Does the Source in the BSP EID reference list have to be the source or is it really the Identifier used to determine what Public Key or Shared Key to use for encryption / signing verification.  I am assuming this "source" EID has to be unique but I think this is more implied than actually stated as a MUST.  I raise the question when considering something like secure multicast in a DTN (non-source specific multicast).  Also, I may want to aliases my source name with one for security and another for routing, domain, or whatever.  As such, perhaps the source does not have to be a URI (actually I am not sure it states the EID has to be a URI here - it may just be implied).

Likewise, can the Destination EID be a wild-carded destination (secure multicast)?

/Will

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Mon, 16 Mar 2009 23:26:36 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Late Binding examples

One sort-of feature of DTN is late binding.  Has anyone implemented late-binding (not to be confused with content-base routing/delivery)?  If so, can you point me to some examples and what addressing scheme was used? I ask because I am unaware of any implemented routing schemes that really do late-binding.  This all is in relation to naming and addressing.  It seems to me that late binding requires distributed name resolvers.   

Thanks,

/Will

Date: Mon, 16 Mar 2009 20:26:58 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Doodle poll

Folks,

I've created a Doodle poll [1] for the drafts in last call.
Please read the instructions and fill in your choices.

Thanks,
Stephen.

PS: This is a bit of an experiment and we can discuss it
in Mountain View.

[1] http://www.doodle.com/snhsmxk4icx39p8k

Date: Mon, 16 Mar 2009 14:50:46 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-checksum

This is a multi-part message in MIME format.
--------------060407040605080403030104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

My comments on the first part (up to the end of section 3, I ran
out of time since there was so much that needed comment) are
attached. This is not ready IMO, I'd guess a couple more
revs are needed before it'd be done.

Stephen.

--------------060407040605080403030104
Content-Type: text/plain;
 name="checksum-cmt.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="checksum-cmt.txt"

SF comments on draft-irtf-dtnrg-checksum

20090312

General

#0 There are many editorial changes required. There are numerous erroneous,
imprecise or misleading statements that should be removed (examples below).
There are also many sections of text that appear to be discussing "DTN history
before checksums." While such text might be interesting for some it doesn't IMO
belong in an experimental RFC unless it is beneficial for implementers (again,
examples below). Basically what should be a useful specification is sometimes
almost a rant which is inappropriate. (In addition to my opinion on this, the
IRSG review specifically aims to ensure that the content is as suitable as
journal content, so this kind of change will be needed later anyway its not
just me being a pain)

#1 I think a lot of the motivation stuff could be removed and that that'd
improve the document. Simpler/shorter is better. 

#2 The BSP has the concept of end-to-end-ishness where e.g. the security source
might not be the actual source. That's mainly to cater for less capable nodes
at the edges, and is probably not needed here, but worth asking anyway. Are
there any cases where it'd make sense to add a checksum in the middle of a path
or to strip one in the middle of a path?

#3 A lot of the discussion about integrity only applies for accidental
integrity violations. There should be a statement up front saying that this
draft doesn't consider deliberate integrity violations and that those are
address by other ciphersuites, e.g. in the BSP spec.

#4 I'm totally unclear as to why there need to be three ciphersuites.  Is
there a real justification for anything other than min and max here?

#5 origin authentication is not non-repudiation (if such exists as a network
service) as any security primer would tell you

#6 MD5 is not a checksum algorithm, it is a digest alg. which is a different
beast (second pre-image resistance etc.)

#7 You're probably better off removing the downref to my expired key mgmt draft
(draft-farrell-dtnrg-km) since someone starting over on that might not base on
that draft, which'd leave the eventual RFC with a bad pointer.

#8 If you want to make the claim that using the PIB is problematic for some
reason, you need to justify that. Just saying "not designed for." (which is
ungrammatic as used) is not sufficient.

#9 (sigh) The use of the term private key seems to indicate a lack of
familiarity with crypto mechanisms. Public keys are used to verify signatures.
"3rd party intermediate nodes that do not possess that private key..." is a
crypto-101 error.

#10 The RSA/SHA256 ciphersuite is criticised for some odd reason. That adds
nothing and should be deleted. (The sentence includes the terms "excessive" and
"disadvantageous.") If you are arguing that keyed ciphersuites are not what you
need then such points are superflous and would only serve to confuse a reader.

#11 What is a "NULL key pair"? As far as I'm aware this is the first time
anyone's suggested using a known key for RSA ever. (No one else has becuase
it'd be silly, a known symmetric key is similar strength and far easier.) I
don't believe anyone has ever suggested re-using an existing ciphersuite with a
known key, all previous cases invent a new ciphersuite. There is really no
point in discussing obviously silly design choices that could have been made by
someone not skilled in the art.  (Actually, just deleting that entire paragraph
is best.)

#12 BAB-HMAC discussion. I'm not sure if its a good idea to opine here on
changes that "could" be made to the BP, but if that remains, it should at least
say "a future version of the BP." Noting that the BP doesn't mandate the BSP is
fine, but the future looking stuff might confuse a reader, so I'd leave it out.
Saying that some "path" seems to be desirable is also needlessly confusing,
this document should just specify and explain the new ciphersuites and not be
as argumentative.

#13 Mention of your "previous proposal" adds nothing and exposes an apparent
minsunderstanding on the author's part of compliance. This spec can and should
define new PIB ciphersuites. There is no reason why conforming implementations
should also have to implement other ciphersuites as well.  (And again
"heavyweight" is purely pejorative so remove that.) 

#14 The "insecure ciphersuites might give a false impression of security"
argument seems to me to be bogus. Have there ever been any cases where IPsec or
TLS equivalents were accidentally used? This could be a security cconsideration
to point out to coders that they shouldn't confuse administrators in user
interfaces, but is not a real issue in terms of the bits on the wire..  (I do
like the idea of naming these ciphersuites INSECURE or something, but that
doesn't mean there's a real issue here.)

#15 "SHOULD subjective ensure" is very odd.

#16 I don't follow why logging output is significant enough for a MUST NOT?

#17 The requirement that any future similar ciphersuite be called "INSECURE" is
broken. Just say that these ciphersuites are called that and you're done. Also
PIBs using these are not indistinguishable from those with secure ciphersuites
- that's the whole point of the ciphersuite types. You're confusing the name of
the ciphersuites (that might appear in GUIs) with the bits on the wire where
no such confusion arises.

#18 You seem to contradict yourself when you say that things MUST be called
INSECURE_* but then say that PIB-HMAC with NULL keys is ok. I think one or the
other is ok, but not both. I think that PIB-HMAC if its useful (and it could
be) ought be in a different document (probably BSP) and the NULL key version
should be here as its own ciphersuite. (Or just omitted, I'm not sure who wants
PIB-HMAC-WITH-NULL?)

#19 Talking about what BP implementations MUST support is missing the point.
This spec should talk about what implementations doing this spec MUST support
and not others.

#20 Mutable c14n is defined in the BSP and not in appendix A.1 The PIB wire
format is defined in the BSP and not in appendix A.2. As-is, both inaccurate
statements would mislead implementers.

#21 Using a zero KeyID as the indicator of a NULL ciphersuite is a bad
choice IMO. (It should be a separate ciphersuite as explained above.) The
problem is that there are times when shared secrets are used without
KeyIDs (which is bad practice, but happens). A zero KeyID is too easy 
for a coder to mistake as a missing KeyID so its better to either have
the same semantic or none.

#22 end of p12, I don't get what "the later two EIDs" means? Needs some
clarification I guess. (Maybe just a type s/EID/SDNV/?) 

#23 What makes you think an 80-bit MAC is less good at error detection
than a (known weak) 128 bit digest? Such statements are better deleted
(or else justified with references). 

#24 "Although the BSP was intended..." again the authors appear confused
about compliance - this document does not UPDATE 5050 (not sure what
that'd mean for an experimental RFC anyway) so discussion of things 
that are "needed" by BP implementations is off base. This is even
clearer in the next paragraph where the spec tries to impose requirements
on 5050 implementations doing custody stuff.

#25 "...private keys shared only..." Private keys are never shared in
any DTN ciphersuite. Another crypto-101 error.

#26 You have a SHOULD on dropping when checks fail. What about fragmentation?

#27 "...end-to-end private key" crypto-101 Entire paragraphs needs fixing.

------------

Editorial changes in the early pages. (I stopped separatng them
after a while since there are so many.)

Abstract:

#1 the BP does not include a checksum, yet it *is* possible to do verification,
if the BSP is used. The statement is misleading.

#2 "Without assurance...cannot" is wrong. "may not" would be correct.

#3 sometimes errored bundle forwarding is desired, suggest replacing "instead
of..." with "where it may have been better to..."`

#4 "address the situation" implies that this is correcting a serious unexpected
fault which is disputed

#5 "Formerly called" adds no value

#6 "Regardless of" clause adds no value

#7 "Divorcing" clause seems odd - I think you mean to say there's no need for
keys but I don't see any papers being served.

#8 "necessary detail" why would you include unnecessary detail? delete
necessary

#9 Overall an abstrct like the following would be much better:

The Delay-Tolerant Networking Bundle Protocol includes a custody transfer
mechanism to provide acknowledgements of receipt for particular bundles.  The
bundle protocol does not define a checksum that allows verification of
error-free forwarding at any hop on the path. This document defines new
"keyless" data integrity ciphersuites for use with the Bundle Security
Protocol's Payload Integrity Block that can be used to increase reliability in
many situations.

Section 1:

#0 this entire section could be deleted, or almost all

#1 2nd para: "does not take bundle inegrity into account" is misleading; the BP
asssumes that CLs do that which is different.

#2 something that's not always sufficient is not always insufficient to talking
about "the insufficiency" is a mistatement

#3 s/painstakingly// it adds nothing but pique

#4 delivering errored content does not require that "all underlying layers pass
through and accept errors", only perhaps that the layers in use when the error
occurs support that, and with bugs, memory or file system errors not even that

#5 the claim that the "ability to provide a check" is primary to "overall
strength" needs a reference or should be deleted

#6 last para of p7:s/much more important/potentially much more important/

#7 same para as #6, everything from "the bundle protocol..does neither..." down
to"...Internet traffic." should be deleted. Its only purpose seems to be to try
make the bundle protocol look bad?

#8 last para: delete the paragraph I guess it just vituperative, hard to
understand how it ever got added

section 2:

#1 there are currently 4 block types in BSP but I don't think there's any need
to discuss that, just say we're re-using PIB. There is no reason to discuss
BAB, PCB or, now ESB at all.

#2 delete the sentence that says "truly suitable" - actually an entire page or
so can best be deleted here, incl. the "what's a MAC" part.

#3 The "in fact, several popular" sentence gets it wrong, some digest algs are
used for MACs

--------------060407040605080403030104--

Date: Fri, 13 Mar 2009 14:05:20 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

On Tue, Mar 10, 2009 at 05:03:51PM -0700, Burleigh, Scott C wrote:

> If some other DTN user community wanted to adopt CBHE for its
> private purposes, cool, it could certainly be its own node number
> allocation authority even without registering a CBHE-like spec based
> on a different authority ID.
> 
> If we wanted those two user communities to interoperate, though,
> they would have to agree on a common node number allocation
> authority structure, maybe one that's federated in some way.  In
> order to have the two communities interoperate using CBHE when one
> of them uses "cbhe.ccsds.org" as authority ID and the other uses
> "your.domain.net" as authority ID, we would have to change the
> definition of CBHE.  As the I-D is written, if your authority ID
> isn't "cbhe.ccsds.org" you're not CBHE conformant -- there isn't any
> way to decompress back to the correct authority ID string, because
> neither that string nor any compressed representation of it is
> carried anywhere in the compressed bundle.

It seems to me that if such a case crops up, a new document specifying
some kind of registration rules will be necessary, no?  I sure
interpreted the cbhe.ccsds.org (b) form to be a promise of some sort
of registration authority at that point, to avoid collisions.  If it's
_not_ such a commitment, then that seems to me to be something that
will need addressing, even if just by a single sentence in the
document saying, "No promises about uniqueness here." 

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Date: Fri, 13 Mar 2009 13:56:15 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

On Thu, Mar 05, 2009 at 06:54:03PM +0000, Stephen Farrell wrote:
> 
> This message starts the "last call" on the Compressed
> Bundle Header Encoding draft. [1]

Dear colleagues,

I have read draft-irtf-dtnrg-cbhe-01.  I have some minor comments.

I note that the draft includes the RFC 2119 language specification,
but that it doesn't actually use the 2119 forms.  There are some
places in the draft where I think the 2119 language could be used, but
if it isn't to be, the boilerplate might as well be dropped.

In §3, the draft notes that CBHE is opaque to bundle processing but
affects interoperation of convergence layer adaptation
implementations.  I think I have convinced myself it's safe because of
the rules in §2.1, but is there any risk that a CBHE-unaware
convergence layer adaptation implementation will see CBHE stuff due to
endpoint form (a)?  I haven't been able to figure out how it would be
possible, but I thought I'd ask just in case.

I think this draft is ready to be published as an experimental RFC,
even without either of the above two points addressed.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Date: Fri, 13 Mar 2009 13:28:40 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] FW: RG "last call" on	draft-irtf-dtnrg-bundle-retrans-block

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Thu, Mar 12, 2009 at 04:41:48PM -0400, Symington, Susan F. wrote:

> Attached is a new draft of the DTN Retransmission Block I-D (now
> version 05) that has been revised to address Stephen's comments. I
> am including both a .txt and a Word version.

Dear colleagues,

I enclose comments I prepared on version -04 of the draft.  My major
concerns are addressed by -05.  In particular, I think the
re-organization has made the risks of poor configuration much clearer.

I did note one nit in the -05, which is a missing space in §2.4 where
it refers to §5.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-retrans-block-04-20090310ajs.txt"
Content-Transfer-Encoding: 8bit

Dear colleagues,

I have read draft-irtf-dtnrg-bundle-retrans-block-04.  I enclose my
comments below.

Before I start, I see the utility of the block, and I think the
document specifies it completely enough for publication with
experimental status.

I get the point of this block, but I'm a little worred about its
potential effects on the reliability of the overall protocol.  In
particular, §3 notes that one possible policy could result in deleting
all legitimate retransmissions.  That seems like a pretty big
foot-gun.  (More on this below.)

It also seems to me like a vector for a different DoS attack.  It
seems that an unco-operative node could use this mechanism to foil
traffic flows from another node that sometimes retransmits
legitimately.  I suppose one might argue in response that, if one has
such a bad actor on the network, one is in trouble; but we are already
defending against such an actor because we're trying to foil someone
who can retransmit arbitrary packets (as a DoS measure).

§4 provides a number of possible ways to avoid deleting legitmately
looping bundles, but it does not provide a recommendation of any
strategy.  I also don't see a reference to a standard way to detect
and not delete these bundles.  It'd be nice if there were a mandatory
way to handle this.

The limitation in §3 is addressed in the ramifications outlined in §5.
I wonder whether an implementer might be better served by moving the
discussion in §5 to §3 instead, thereby increasing the odds that the
ramifications will be read together with the description of what to
do.

The main reason I'm worried about this is because it is the node's own
security policy that determines whether a retransmitted block will be
deleted.  Especially in the opportunistic cases noted at the end of
§4, I think this all may mean that a node that happens to cause a lot
of retransmissions innocently may find the network less reliable than
it otherwise might.  Moreover, there's no guarantee that such a node
will learn what's up, because the local policy of the deleting node
also determines whether a bundle deletion status report is generated
(see §3).  I'd really prefer that a stronger recommendation for the
deletion status report  -- a SHOULD.

All of the above said, I see the utility of the block, and I think the
document specifies it completely enough for publication with
experimental status.  

I did find one nit: s/in tact/intact in §8.

Best regards,

Andrew

--mYCpIKhGyMATD0i+--

Date: Fri, 13 Mar 2009 14:24:05 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Logistics etc

Hi All,

I'm travelling at the moment so if you can keep helping one
another out wrt this stuff that'd be great. I'll do an updated
agenda with Kevin on Monday hopefully so feel free in the
meantime to ask us (off list is better) if there's a slot you'd
like to talk on, or lead the discussion on.

Stephen.

Date: Fri, 13 Mar 2009 09:15:36 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] Final Call for Papers: MobiArch 2009 (co-located with ACM MobiSys)

                         Call for Papers

          The 4th ACM International Workshop on Mobility
       in the Evolving Internet Architecture (MobiArch 2009)
       -----------------------------------------------------

      Co-located with MobiSys, 22 June 2009, Krakow, Poland
     http://user.informatik.uni-goettingen.de/~mobiarch/2009/

With the recent development of technologies in wireless access and
mobile devices, user, terminal, and network mobility has become an
indispensable component of today's Internet vision, and it is likely to
continue in the near future, while affecting the whole architectural
design of the future Internet. Yet, issues like efficient mobility
management and optimization, locator-identifier split, multi-homing,
security, wireless access and related operational/deployment concerns
are still in their early stages of development. Moreover, the Internet
architecture, its end-to-end principles, and business models will
require rethinking due to the massive penetration of mobility into the
Internet. For instance, an appropriate system that allows communicating
with a mobile host requires addressing several fundamental issues with
the Internet architecture, such as ability to locate the mobile
host/service, preserving ongoing communications upon changes of
locations, as well as efficient and secure handover management. As
another example, the emerging wireless technologies may pose additional
challenges to the Internet architecture since they introduce design
principles different from the original Internet.

MobiArch 2009 welcomes submissions, from both researchers and
practitioners, in exploration of recent advances in architectures,
protocols, and experiences with emerging technologies on various
mobility issues over the Internet, with an emphasis on wireless
infrastructures and mobility patterns for mobility support, new mobility
protocols, service discovery, routing and location management, mobile
network performance evaluation and modelling, multi-homing, security,
architectural impacts and deployment considerations. Furthermore, the
potential of usability of mobility services for connecting people and
devices in developing regions of the world into the Internet
infrastructure will be also explored.

Topics of MobiArch 2009 cover all aspects of architectural issues and
system support for mobility in the Internet, including but not limited to:

* Impacts of new wireless technologies/services, networking
   technologies, and mobility patterns on the Internet architecture
* Architectures and protocols for mobility support in the Internet,
   ranging from approaches in link, network, transport to
   session/application layers and cross-layer design
* Location management, routing, locator/identifier split, multi-homing
   and load sharing issues
* Security and privacy issues in mobility networks and impacts to
   Internet architecture
* Architectures and mechanisms for wireless/mobile connectivity in
   extreme environments (e.g., remote areas, developing countries)
* Performance issues with mobility in the Internet
* QoS and middlebox issues in mobility networks and impacts to Internet
   architecture
* Economic and deployment issues of mobility solutions (infrastructure
   and devices)
* Impact of social aspects on mobility architectures, mobile application
   and protocol design
* Technologies for mobile wireless access and interactions

Submissions must present original results. Selected papers will be
forward-looking, describe their relationship to existing work, and have
impact and implications for ongoing or future research.
Submitted papers must be no more than 6 pages long, two columns, with no
characters in smaller than 10 point fonts, and must fit properly on US
"Letter"-sized paper (8.5x11 inches). Margins must be of 1 inch on all
edges (top, bottom, left, and right) of each page. All paper submission
will be handled via EDAS (http://edas.info/7188). Papers will be
reviewed single blind.

Important Dates:

     Submission Deadline:      15 March 2009 (extended)
     Acceptance Notification:  31 March 2009
     Camera Ready Due:         15 April 2009
     Workshop Date:            22 June 2009

TPC Chairs:

     Joerg Ott   Helsinki University of Technology (TKK)
     Kun Tan     Microsoft Research Asia

For more information, contact workshop co-chairs at
[email-masked].

From: "Symington, Susan F." <[email-masked]>
To: DTN <[email-masked]>
Date: Thu, 12 Mar 2009 16:41:48 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] FW: RG "last call" on draft-irtf-dtnrg-bundle-retrans-block

--_004_F5830D8920D7BA4DB8BCFE1DC57164AC02288C50D1IMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached is a new draft of the DTN Retransmission Block I-D (now version 05=
) that has been revised to address Stephen's comments. I am including both =
a .txt and a Word version.

Note that the I-D Submission tool will not allow me to formally submit this=
 new draft until the tool reopens at midnight on March 23.=20

-susan

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

>-----Original Message-----
>From: Symington, Susan F.
>Sent: Monday, March 09, 2009 3:29 PM
>To: 'Stephen Farrell'
>Cc: DTN
>Subject: RE: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-
>retrans-block
>
>Stephen,
>
>I will reorganize the draft as you suggest with an applicability
>statement up front that makes clear that use of the BAB along every hop
>is needed and that routing loops won't be tolerated if replays are being
>suppressed. Attached are your comments along with a response indicating
>how I plan to address each.
>
>-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: Friday, March 06, 2009 11:42 AM
>>To: Symington, Susan F.
>>Cc: DTN
>>Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-
>>retrans-block
>>
>>
>>Hi Susan,
>>
>>The attached are my comments on this. I guess the
>>main one is: "#0, I think that overall this one's not
>>really ready as-is."
>>
>>Stephen.
>>
>>
>>

--_004_F5830D8920D7BA4DB8BCFE1DC57164AC02288C50D1IMCMBX2MITREO_
Content-Type: text/plain; name="retran-block-comments-sf-response.txt"
Content-Description: retran-block-comments-sf-response.txt
Content-Disposition: attachment;
	filename="retran-block-comments-sf-response.txt"; size=9072;
	creation-date="Mon, 09 Mar 2009 15:28:11 GMT";
	modification-date="Mon, 09 Mar 2009 15:28:11 GMT"
Content-Transfer-Encoding: base64

--_004_F5830D8920D7BA4DB8BCFE1DC57164AC02288C50D1IMCMBX2MITREO_
Content-Type: text/plain; name="draft-irtf-dtnrg-bundle-retrans-block-05.txt"
Content-Description: draft-irtf-dtnrg-bundle-retrans-block-05.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-retrans-block-05.txt"; size=28630;
	creation-date="Tue, 10 Mar 2009 15:13:33 GMT";
	modification-date="Thu, 12 Mar 2009 16:27:21 GMT"
Content-Transfer-Encoding: base64

--_004_F5830D8920D7BA4DB8BCFE1DC57164AC02288C50D1IMCMBX2MITREO_
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
	name="draft-irtf-dtnrg-bundle-retrans-block-05.docx"
Content-Description: draft-irtf-dtnrg-bundle-retrans-block-05.docx
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-retrans-block-05.docx"; size=29145;
	creation-date="Wed, 11 Mar 2009 16:31:06 GMT";
	modification-date="Thu, 12 Mar 2009 16:41:48 GMT"
Content-Transfer-Encoding: base64

--_004_F5830D8920D7BA4DB8BCFE1DC57164AC02288C50D1IMCMBX2MITREO_--

From: "Henry B. Hotz" <[email-masked]>
To: Stephen Farrell <[email-masked]>, dtn interest <[email-masked]>
Date: Thu, 12 Mar 2009 11:28:41 -0700
Cc: Peter Lovell <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

Officially the fact that this is an experimental RFC from a research  
group, not a working group should matter.  I suspect there are many  
people who look at final RFC's and don't check there status as  
"standards track" though.

1) Let me make the also-heretical suggestion that it doesn't matter if  
this draft is finalized, as long as there is consensus as to where we  
go from here.  The reason I say that is that something like draft 31  
of the PKINIT standard was finalized as RFC 4556, and is seeing  
significant deployment.  HOWEVER the long-expired draft 9 is still  
important because that's what Microsoft implemented in W2003.  I'm not  
saying that's preferred, but it's better than most of the realistic  
alternatives would have been.

In other words a perfectly reasonable decision would be:  "we want to  
experiment with draft x of BSP before we finalize anything because we  
need to understand y and z better."

2) Overview vice BSP is a chicken-and-egg problem.  It's not blocking  
unless there are issues that need resolving.  One way to resolve them  
is to explicitly note they are not addressed, as is done with key  
management.

3) I agree with the comment that the name should reflect the actual  
scope of the document, which does not cover the entire scope of  
security issues.  (This is not a criticism!)
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

Date: Thu, 12 Mar 2009 11:08:09 -0400
To: Elwyn Davies <[email-masked]>
From: "Adrian J. Hooke" <[email-masked]>
Cc: DTN <[email-masked]>, "Denise Reed <[email-masked]>.  Carla LaFever" <[email-masked]>
Subject: Re: [dtn-interest] March 19-20 Logistics/Agenda

--=====================_96679843==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 08:49 AM 3/12/2009, Elwyn Davies wrote:
>I will be arriving at Google's  gates by car and would like to be able
>to park on or close to the site if at all possible.  I imagine there is
>vistors' parking but I guess it would be polite, and possibly essential,
>to give prior notice of arrival.  Do you have a local contact at Google
>who I can notify and/or can give me the lowdown/directions to the
>appropriate entrance.please?

The Google contact is Denise Reed <[email-masked]>. Vint's Chief 
of Staff in Washington is Carla LaFever <[email-masked]>

We have a private NASA meeting in the same room on Tuesday and 
Wednesday and I had asked for it to be set up with a teleconference 
set, laptop projector, screen, flip-charts/pens and a white-board, 
which I expect will still be there when NASA turns it over to the 
DTNRG. I'm sure that there will be guest wireless available.

I believe that the NASA and DTNRG meetings are both in the 'Bodega 
Bay Tech Talk Room' in Building 1950, 1950 Charleston Road.  Just 
arrive and check in with the receptionist.

Best regards
Adrian

--=====================_96679843==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<font color="#0000FF">At 08:49 AM 3/12/2009, Elwyn Davies wrote:<br>
<blockquote type=cite class=cite cite="">I will be arriving at
Google's&nbsp; gates by car and would like to be able <br>
to park on or close to the site if at all possible.&nbsp; I imagine there
is <br>
vistors' parking but I guess it would be polite, and possibly essential,
<br>
to give prior notice of arrival.&nbsp; Do you have a local contact at
Google <br>
who I can notify and/or can give me the lowdown/directions to the <br>
appropriate entrance.please?</font></blockquote><br>
The Google contact is Denise Reed &lt;[email-masked]&gt;. Vint's Chief
of Staff in Washington is Carla LaFever
&lt;[email-masked]&gt;<br><br>
We have a private NASA meeting in the same room on Tuesday and Wednesday
and I had asked for it to be set up with a teleconference set, laptop
projector, screen, flip-charts/pens and a white-board, which I expect
will still be there when NASA turns it over to the DTNRG. I'm sure that
there will be guest wireless available.<br><br>
I believe that the NASA and DTNRG meetings are both in the 'Bodega Bay
Tech Talk Room' in Building 1950, 1950 Charleston Road.&nbsp; Just arrive
and check in with the receptionist. <br><br>
Best regards<br>
Adrian<br>
</body>
</html>

--=====================_96679843==.ALT--

Date: Thu, 12 Mar 2009 10:36:27 -0400
From: David Young <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] March 19-20 Logistics/Agenda

Do we have much of an idea about infrastructure available?  Should
someone be packing hubs to this thing?  I'm thinking about the interop
in particular.  I get the feeling this has been asked before, but with
all the last-calls, I've lost track.

On Mon, Feb 23, 2009 at 1:55 PM, Stephen Farrell
<[email-masked]> wrote:
>
> Hi All,
>
> I've finally gotten around to posting logistics and agenda. [1]
>
> Mail changes/additions/suggestions to Kevin and I, or the list,
> as appropriate.
>
> Regards,
> Stephen.
>
> [1] http://down.dsg.cs.tcd.ie/dtnrg-at-google/
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
David Young

From: Marshall Eubanks <[email-masked]>
To: Elwyn Davies <[email-masked]>
Date: Thu, 12 Mar 2009 09:00:38 -0400
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] March 19-20 Logistics/Agenda

On Mar 12, 2009, at 8:49 AM, Elwyn Davies wrote:

> Hi, Stephen.
>
> I will be arriving at Google's  gates by car and would like to be able
> to park on or close to the site if at all possible.  I imagine there  
> is
> vistors' parking but I guess it would be polite, and possibly  
> essential,
> to give prior notice of arrival.  Do you have a local contact at  
> Google
> who I can notify and/or can give me the lowdown/directions to the
> appropriate entrance.please?
>
> I am staying in SF city (Haight-Ashury area) and I expect to have a
> couple of free places in the car if anybody else needs a ride to
> Mountain View each day

I will be in the same boat (er, convenance), and could also offer a  
ride from the city (or, depending,
maybe I would take you up on your offer).

Regards
Marshall

>
>
> Regards,
> Elwyn
>
>
> Stephen Farrell wrote:
>> Hi All,
>>
>> I've finally gotten around to posting logistics and agenda. [1]
>>
>> Mail changes/additions/suggestions to Kevin and I, or the list,
>> as appropriate.
>>
>> Regards,
>> Stephen.
>>
>> [1] http://down.dsg.cs.tcd.ie/dtnrg-at-google/
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 12 Mar 2009 12:49:20 +0000
From: Elwyn Davies <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] March 19-20 Logistics/Agenda

Hi, Stephen.

I will be arriving at Google's  gates by car and would like to be able 
to park on or close to the site if at all possible.  I imagine there is 
vistors' parking but I guess it would be polite, and possibly essential, 
to give prior notice of arrival.  Do you have a local contact at Google 
who I can notify and/or can give me the lowdown/directions to the 
appropriate entrance.please?

I am staying in SF city (Haight-Ashury area) and I expect to have a 
couple of free places in the car if anybody else needs a ride to 
Mountain View each day

Regards,
Elwyn

Stephen Farrell wrote:
> Hi All,
>
> I've finally gotten around to posting logistics and agenda. [1]
>
> Mail changes/additions/suggestions to Kevin and I, or the list,
> as appropriate.
>
> Regards,
> Stephen.
>
> [1] http://down.dsg.cs.tcd.ie/dtnrg-at-google/
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

Date: Wed, 11 Mar 2009 23:28:39 -0400 (EDT)
From: "Balasubramaniyan, Vijay A" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP NPSec 2009

Dear colleagues,
Please consider submitting to the 5th workshop on Secure Network Protocols (NPSec 2009). The website is:
http://www.gtisc.gatech.edu/npsec09/

Thanks,
Vijay A. Balasubramaniyan
NPSec 2009 web and publicity chair
[Apologies if you receive multiple copies of this CFP]

                              CALL FOR PAPERS
                                NPSec 2009
                 5th Workshop on Secure Network Protocols
                      In conjunction with ICNP 2009
                             October 13, 2009
                        Princeton, New Jersey, USA
                   http://www.gtisc.gatech.edu/npsec09/

Scope:
The 5th workshop on Secure Network Protocols (NPSec) is a one-day event 
held in conjunction with the 17th IEEE International Conference on 
Network Protocols (ICNP 2009). NPSec focuses on two general areas.  
The first focus is on the development and analysis of secure or hardened 
protocols for the operation (establishment and maintenance) of network 
infrastructure, including such targets as secure multidomain, ad hoc, sensor 
or overlay networks, or other related target areas.  This can include new 
protocols, enhancements to existing protocols, protocol analysis, and new 
attacks on existing protocols.  The second focus is on employing such secure 
network protocols to create or enhance network applications. Examples include 
collaborative firewalls, incentive strategies for multiparty networks, and 
deployment strategies to enable secure applications.   

NPSec 2009 particularly welcomes new ideas on security in the context of 
future Internet design, such as architectural considerations for future 
Internet security and new primitives for supporting secure network protocol 
and application design.  

Topics of interest include but are not limited to:
1. security in future Internet architectures
 - role of security in future architectures
 - integrating security into future protocols and applications
2. secure and/or resilient network protocols, e.g.:
- internetworking/routing 
- MANETs
- LANs and WLANs 
- mobile/cellular data networks
- p2p and other overlay networks
- federated trust systems
- sensor networks
3. vulnerabilities of existing protocols and applications (both theoretical and case studies), including attacks
4. key distribution/management
5. intrusion detection and response
6. incentive systems for p2p systems and MANETs routing
7. secure protocol configuration and deployment

Important Dates:
Abstract submission: May 15, 2009
Paper submission: May 29, 2009
Notification of acceptance: July 15, 2009
Camera ready version: August 5, 2009

NPSEC Steering Committee:
Sonia Fahmy, Purdue University (chair)
George Kesidis, Penn State University
Cristina Nita-Rotaru, Purdue University
Gene Tsudik, UC Irvine

Program Co-Chairs:
Jelena Mirkovic, USC/ISI
Xiaowei Yang, Duke University

Web and Proceedings Chair:
Vijay A. Balasubramaniyan, Georgia Tech.

Technical Program Committee:
Daniel Massey, Colorado State University
Jun Li, University of Oregon
Peter Reiher, UCLA
Beichuan Zhang, University of Arizona
Young Cho, USC/ISI
Mukesh Singhal, University of Kentucky
Minseok Kwon, Rochester Institute of Technology
Lan Wang, University of Memphis
Y. Charlie Hu, Purdue University
Minaxi Gupta, Indiana University
Dan Pei, AT\&T Research
Bogdan Carbunar, Motorola Research
Ted Faber, USC/ISI
Jia Wang, AT\&T Research
Landon Cox, Duke University
Jean-Pierre Hubaux, EPFL
Stephan Bohacek, University of Delaware
Reza Curtmola, New Jersey Institute of Technology
Brent Kang, University of North Carolina
Bryan Ford, Max Planck Institute for Software Systems

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Wed, 11 Mar 2009 17:02:51 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, March 10, 2009 4:26 PM
> To: Stephen Farrell
> Cc: DTN
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> 
> My comments on this one. Sorry if they overlap with earlier ones, S.
> 
> General:

#0, I guess I'm left wondering if this is the only spec needed to implement a
CL for space DTNs? If so, cool. If not, would it be better if it were?

		This has come up in a couple of posts.  On some reflection, I still think the best way to think of CBHE is as a compression convention that multiple CL adapters might conform to; as Teemu suggests, you could easily have a CBHE-conformant implementation of TCPCL.  (In fact, the ION implementation of TCPCL will indeed be CBHE-conformant.)  I wouldn't want to try to turn CBHE into the spec for the CL for space DTNs because, as Lloyd points out, there will be several such CLs: a "CL" really has to be a stack, all the way down to layer 1, in order to work, and if nothing else we know that multiple link-layer protocols will be used in space DTNs.

#1, The spec as-is only compresses certain EIDs and not general headers so the
title is, for me, misleading. The actual compression is also space-specific (via
ccsds.org) so I think a better name might be "Space DTN EID Compression" or
something like that.

		I'd rather not spend a lot of energy re-engineering the name at this point if we don't absolutely have to.  CBHE does compress the "header" of a bundle (which isn't really defined anywhere; notionally it's all the blocks preceding the payload) in that the "header" ends up smaller than it started.  And it's not necessarily space-specific, especially if we take Wes's advice and change the authority-name string to "cbhe.dtnrg.org."

#2, Just wondering...Have CCSDS agreed to sort-of delegate the cbhe.ccsds.org
DNS sub-domain for this purpose? If so, a reference would be great. (Even if to
a mail or web page.) If that's a prooblem, maybe replacing that with a nasa.gov
sub-domain might do? If neither, we can probably get some domain dedicated to
this that'd not be likely to disappear anytime soon. I'd not be surprised if we
get asked by the IRSG, IESG or IANA about this so having the answer up front
would be good.

		CCSDS isn't involved at all, at this point.  I agree with what you're saying, which I think is another good reason to use "cbhe.dtnrg.org".

#3, section 2.1, 2nd para and after: I think *this* is the specification for
dtn://cbhe.ccsds.org/* EIDs since its nowhere else.

		I thought we were supposed to publish an overall scheme specification RFC for the "dtn" scheme, something like http://www.rfc-editor.org/rfc/rfc3966.txt.  I would expect that to be where we say, for example, that all "dtn" URIs have got authority components and that the path component of a dtn URI must conform to the specification for the indicated dtn authority.  But you're right, we wouldn't expect an exhaustive list of all dtn authorities to be in that RFC; I'll modify the CBHE spec to align with this concept and not worry about when the parent RFC gets published.

#4, I don't understand why service number zero is needed for admin stuff when
there're flags for that in the header?

		A darned good question.  The intent was to have a CBHE equivalent for the dtn2-style endpoint IDs that have a zero-length demux token, but I can't think of any reason why it's really needed.  I'll remove the text about reserving service number zero.  (Which means the 8th SDNV is no longer a constant zero; it's needed.)

#5, the list at the end of 2.1 seems to require exactly 4 EIDs to be present in
a certain order. I'm not sure that's right.

		That's the structure of the BP primary header: 8 SDNVs.  Some of them may contain zero, indicating "dtn:none" -- i.e., they are omitted.

#6, 3.1, what should a compliant CL do when presented with a bundle that
doesn't match this spec? send it or /dev/null or what?

		I figure this is an implementation issue.  I don't want to try to dictate here; it doesn't affect interoperability.

Similarly, for 3.2 if a decoder get a non compressed (but otherwise correct) bundle encoding then what?

		The spec just imposes requirements on "the convergence layer adapter", not on a decoder, and those requirements are strictly in addition to -- and consistent with -- the requirements stated in RFC 5050.  So I don't think the spec needs to prescribe anything in this case.  Since the condition stated in 3.2 doesn't hold, it doesn't decompress; since all other requirements from 5050 are still in effect, it just passes the bundle up to BP as is.

#7 sec. cons. (there's always one:-) If ccsds.org changes ownership this spec
might be in trouble:-) And the BSP needs a reference.

		But no problem if we use cbhe.dtnrg.org, right?  And I thought RFCs were specifically prohibited from referencing I-Ds....

#8, some examples would make a nice appendix if they could be easily done

		Yes, they would.

Nits:

#1, section 1, 2nd para: s/contains four BP endpoint identifiers/contains four
or more BP endpoint identifiers/, although the report-to and custodian EIDs are
also optional so its "2 or more" really?

		No, every bundle always contains all four of the EIDs listed.  Some of them may be "dtn:none", and two or more of them may be identical, but all four are always there: if you dereference any of the four pairs of offsets you always end up with an EID.  You're right that there could be more than four, though; how about if I change "four" to "at least the following four"?

#2, s/natural number/positive integer/ is better for coders IMO and that
conflicts (ok only slightly) with the next para where its defined as an integer
within a range.

		Okay.

Scott

From: "Henry B. Hotz" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Wed, 11 Mar 2009 14:26:16 -0700
Cc: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

I haven't spent enough time studying the spec to comment in detail.  I  
can offer some general comments based on experience with the evolution  
of other specifications.  Interpret them as you will.

Clarification

1) You need to have a clear division between the protocol framework  
and the crypto algorithms because you will want to evolve them at  
different times for different reasons.

2) You don't need to have separate documents, though that does enforce  
the "clear division".

New points

3) You MUST have a mandatory-to-implement algorithm if you want to  
guarantee interoperability.  Interoperability is usually the reason  
you publish a standard, while a non-standards-track RFC is appropriate  
for a research effort.  Is this RFC supporting a research project, or  
a permanent deployment?

4) You SHOULD have multiple mandatory-to-implement algorithms so you  
can decommission one if a weakness is discovered, but still preserve  
interoperability with legacy deployments.  (SSH is struggling with  
this right now, I believe.  Can anyone on this list really tell me  
what the UK MOD is complaining about?)

5) The list of mandatory-to-implement algorithms will change with time.

On Mar 11, 2009, at 12:50 PM, Ivancic, William D. (GRC-RHN0) wrote:

> It seems like the lesson learned from the past is that it is nice to  
> split the protocol from the algorithms as that allows the two to  
> progress and change at different rates.  Thus, I would think it  
> would actually save effort over the long term if we split the  
> protocol functions from the ciphersuites.
>
> /Will
>
> ******************************
>
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On
>> Behalf Of Henry B. Hotz
>> Sent: Wednesday, March 11, 2009 12:34 PM
>> To: dtn interest
>> Subject: Re: [dtn-interest] "last call" comments on the latest BSP
>>
>>
>> On Mar 11, 2009, at 6:20 AM, Durst, Robert C. wrote:
>>
>>> I concur with the notion of having separate conformance
>> statements for
>>> the protocol functions and the ciphersuites.
>>
>>
>> I note that Kerberos has RFC 3961 defining some algorithms and
>> profiles for new algorithms (like AES, defined in RFC 3962).  That's
>> separate from RFC 4120 defining the protocol.  The pair of them
>> obsoleted RFC 1510, which defined both algorithms and protocol.
>>
>> OTOH I don't believe TLS has split yet.  It's been around about 10
>> years and has added algorithms.
>> ------------------------------------------------------
>> The opinions expressed in this message are mine,
>> not those of Caltech, JPL, NASA, or the US Government.
>> [email-masked], or [email-masked]
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 15:59:34 -0400
Cc: DTN <[email-masked]>
Subject: [dtn-interest] Re(2): RG "last call" on draft-irtf-dtnrg-bundle-security

Hi Stephen,

On Wed, Mar 11, 2009, Stephen Farrell <[email-masked]> wrote:

>
>So my comments on this are attached. As Susan said I think
>you did a fine job and we're nearly there, but I reckon that
>the ESB stuff does need a bit more work in another rev. before
>we're finally done. Let's try take some time in Mountain View
>to go over it if we can.
>
>Cheers,
>Stephen.
>
>#1 I'd get rid of the references to the sec. overview entirely now that
>that'll not be finished for a while.

Fair enough. It shouldn't bottleneck BSP being done.

>#2 1.2 still introduces a requirement that's not in 5050, that 
>forwarding nodes MUST transmit blocks in the same order as they
>were received. I think I recall we debated that before and 
>concluded we needed it, but it'd be better in a section of its
>own called something like "General Requirements for nodes
>in DTNs using the BSP" or something. As it is, its kinda buried
>in the "terminology" section.

Actually we *did* get that into 5050. Have a look at second para of step
5, top of page 28. 

This is not to argue against your suggestion of a "requirements" section
- I think that's a good one.

>#3 I'd rather we not use metadata as the example of the use of
>ESB. Suggestions for a better example welcome.

I couldn't think of a better one either. I just used this since it was
the genesis for the whole thing.

>#4 IANA stuff again. We should decide what we'd like IANA to
>do with ciphersuite IDs even if we don't yet want a registry.
>(The text below Figure 2 might then change.)

I don't have any experience dealing with IANA so let's decide in
Mountain View.

>#5, section 2.4: " If the ciphersuite doesn't specify this, then the node is
>free to encrypt whichever blocks it wishes." Just wondering if we're
sure that
>doing that never causes a problem. Something to think through.

This is old language. My preference would be to say that the ciphersuite
must specify (some way or other) what blocks are and are not to be
encrypted. It might be by type, or placement, or something else but it
has to be determinate. Otherwise it's an error.

>#6, section 2.4, last para: "salt, IV and key values" are those
>well-defined at this point in the spec?

I guess I need to add a forward reference to "Parameters and Result Fields"

>#7 section 2.5, ESB:  I think I need to think this through some
>more before we're done. E.g. ESB may need a mention in 2.8, are
>we happy that failure to decrypt an ESB means the bundle MUST
>be discarded? (3.6), ESB should be mentioned in section 5 etc.

Maybe ESB needs a mention in 2.8 but it would just be to exclude it from
the PIB/PCB combos. But we should do so explicitly.

I don't know about proper consequences for ESB failure - there are
arguments for and against each way.

>#8, section 2.7: I don't (or no longer;-) understand  the last
>paragraph.

As an example, the ephemeral key might be encrypted using RSA key. So
"key information" would contain, say, a certificate number and issuer to
indicate the RSA key that was used, and it also has the encrypted
ephemeral key.

This paragraph is saying that these two things could be packed into a
single "key information" item, in dtn-speak. Or they could be sent as
two items, one with certificate number and issuer, and another item
instance with the encrypted ephemeral key.

>#9, p48 the "[tbd]" reference to the key mgmt spec should be
>deleted.

OK

>#10, examples would be nice if we have any

True.

>#11, Wes' suggestion to change the name of the document isn't
>a bad one. Maybe "Bundle Encryption and Integrity Mechansim"
>or some such?

That will create terrible "BEIM me up, Scotty" jokes.

>Nits:
>
>#1 p16, s/If super-encryption if/If super-encrypion of/

Susan got that for me already, and several others besides. Several old
references to "PS' instead of "PI" too.

>#2, 2.5, ESB: s/payload/block/ in "A typical ESB ciphersuite will encrypt the
>payload" ?

Yep - that's what cloning does. I keep catching more. Thanks.

>#3 section 3 refers to e.g. "PC block" and not PCB a few times. I think
>I'd rather we always say PCB etc.

That would be better but doesn't always flow. I want to avoid "PCB
block" as that doesn't make sense. I'll work on it.

Thanks.....Peter

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Henry B. Hotz" <[email-masked]>, dtn interest <[email-masked]>
Date: Wed, 11 Mar 2009 14:50:21 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

It seems like the lesson learned from the past is that it is nice to split the protocol from the algorithms as that allows the two to progress and change at different rates.  Thus, I would think it would actually save effort over the long term if we split the protocol functions from the ciphersuites.

/Will

******************************

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Henry B. Hotz
> Sent: Wednesday, March 11, 2009 12:34 PM
> To: dtn interest
> Subject: Re: [dtn-interest] "last call" comments on the latest BSP
> 
> 
> On Mar 11, 2009, at 6:20 AM, Durst, Robert C. wrote:
> 
> > I concur with the notion of having separate conformance 
> statements for 
> > the protocol functions and the ciphersuites.
> 
> 
> I note that Kerberos has RFC 3961 defining some algorithms and  
> profiles for new algorithms (like AES, defined in RFC 3962).  That's  
> separate from RFC 4120 defining the protocol.  The pair of them  
> obsoleted RFC 1510, which defined both algorithms and protocol.
> 
> OTOH I don't believe TLS has split yet.  It's been around about 10  
> years and has added algorithms.
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> [email-masked], or [email-masked]
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Wed, 11 Mar 2009 18:52:44 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

This is a multi-part message in MIME format.
--------------070808050600070203060101
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

So my comments on this are attached. As Susan said I think
you did a fine job and we're nearly there, but I reckon that
the ESB stuff does need a bit more work in another rev. before
we're finally done. Let's try take some time in Mountain View
to go over it if we can.

Cheers,
Stephen.

--------------070808050600070203060101
Content-Type: text/plain;
 name="bsp--07-comments.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="bsp--07-comments.txt"

#1 I'd get rid of the references to the sec. overview entirely now that
that'll not be finished for a while.

#2 1.2 still introduces a requirement that's not in 5050, that 
forwarding nodes MUST transmit blocks in the same order as they
were received. I think I recall we debated that before and 
concluded we needed it, but it'd be better in a section of its
own called something like "General Requirements for nodes
in DTNs using the BSP" or something. As it is, its kinda buried
in the "terminology" section.

#3 I'd rather we not use metadata as the example of the use of
ESB. Suggestions for a better example welcome.

#4 IANA stuff again. We should decide what we'd like IANA to
do with ciphersuite IDs even if we don't yet want a registry.
(The text below Figure 2 might then change.)

#5, section 2.4: " If the ciphersuite doesn't specify this, then the node is
free to encrypt whichever blocks it wishes." Just wondering if we're sure that
doing that never causes a problem. Something to think through.

#6, section 2.4, last para: "salt, IV and key values" are those
well-defined at this point in the spec?

#7 section 2.5, ESB:  I think I need to think this through some
more before we're done. E.g. ESB may need a mention in 2.8, are
we happy that failure to decrypt an ESB means the bundle MUST
be discarded? (3.6), ESB should be mentioned in section 5 etc.

#8, section 2.7: I don't (or no longer;-) understand  the last
paragraph.

#9, p48 the "[tbd]" reference to the key mgmt spec should be
deleted.

#10, examples would be nice if we have any

#11, Wes' suggestion to change the name of the document isn't
a bad one. Maybe "Bundle Encryption and Integrity Mechansim"
or some such?

Nits:

#1 p16, s/If super-encryption if/If super-encrypion of/

#2, 2.5, ESB: s/payload/block/ in "A typical ESB ciphersuite will encrypt the
payload" ?

#3 section 3 refers to e.g. "PC block" and not PCB a few times. I think
I'd rather we always say PCB etc.

--------------070808050600070203060101--

Date: Wed, 11 Mar 2009 18:16:20 +0000
From: Stephen Farrell <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

In this case, as a co-author, I'm not wearing a chair-like
hat. Sorry if that wasn't clear.

(And incidentally, since RG "last calls" are not IETF WG last
calls, there's no formal "chairs establish rough consensus"
requirement so all of my comments on all of the drafts are
"as participant.")

Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]] 
>> Sent: Wednesday, March 11, 2009 1:18 PM
>>
>> Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>>> Analogies suck though ... discussion should be on the real points
>>> and not on analogies used to season them!
>> That would be welcome. Feel free to start doing it.
> 
> and
> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]] 
>> Sent: Wednesday, March 11, 2009 1:39 PM
>>
>> Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>>
>>> Why is finishing the sec-overview draft so controversial?
>> It is not. Asking for the overview to be on a supposedly
>> critical path before the BSP and checksum drafts, and with
>> no technical critique of the BSP spec as the basis for the
>> request, is where you're basically wrong I think.
>>
>> And the controversy (for me) arises from the style of your
>> non-review of the BSP which I characterised as FUD.
>>
> 
> 
> Email is so much worse than face-to-face ... 

True. Especially in cases like this.

> I also don't understand how given that there are archived
> mail-list threads based on my comments towards the BSP
> (e.g.
> http://maillists.intel-research.net/pipermail/dtn-interest/2007-August/002866.html
> http://maillists.intel-research.net/pipermail/dtn-interest/2007-October/002921.html)
> how you can seriously ask me if I've read it and claim that
> I've not reviewed it by 

I know you've read it. I didn't assert that you hadn't.
(If I did, sorry, and I'm happy to take that back but I
don't believe I made any such assertion.)

What I said was that your "wait until an architecture is
finished" combined with "please last call checksum" was
puzzling. Its puzzling because I know you've read BSP and
you know that checksum depends on BSP. I remain puzzled
by that combination. Had you not been familiar with BSP
that would have explained the situation, but absent that
explanation...puzzled.

> labelling my input as a "non-review"?

I didn't see you make any reference to content within the
document at all. Hence "non-review."

I did see "very dangerous," "bolt-on," "very premature"
etc. Later you said "rubber stamp." That, combined
with the lack of content/non-review => FUD IMO.

> "FUD" is a pretty harsh label to give so quickly, 

Yes it is harsh. But see just above.

Perhaps you don't really think this document is a
very dangerous, premature, bolt-on that we're
attempting to rubber stamp? If so, saying so would
be good.

I would welcome your substantive review of the
document. (I'm in the process of doing my own at
the moment as it happens.)

Stephen.

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 12:51:11 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Wednesday, March 11, 2009 1:18 PM
>
>Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>> Analogies suck though ... discussion should be on the real points
>> and not on analogies used to season them!
>
>That would be welcome. Feel free to start doing it.

and

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Wednesday, March 11, 2009 1:39 PM
>
>Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>
>> Why is finishing the sec-overview draft so controversial?
>
>It is not. Asking for the overview to be on a supposedly
>critical path before the BSP and checksum drafts, and with
>no technical critique of the BSP spec as the basis for the
>request, is where you're basically wrong I think.
>
>And the controversy (for me) arises from the style of your
>non-review of the BSP which I characterised as FUD.
>

Email is so much worse than face-to-face ... Stephen - are
you saying in a DTNRG chair position that nothing in the last
call inputs I've submitted was substantive and that they're
not being considered, or are you saying as an individual that
you simply don't understand or don't agree with them?

Only one analogy was made within 3 lines among the several
dozen lines in the mails I sent, so I'm truly puzzled why the
input is being colored this way.

I also don't understand how given that there are archived
mail-list threads based on my comments towards the BSP
(e.g.
http://maillists.intel-research.net/pipermail/dtn-interest/2007-August/002866.html
http://maillists.intel-research.net/pipermail/dtn-interest/2007-October/002921.html)
how you can seriously ask me if I've read it and claim that
I've not reviewed it by labelling my input as a "non-review"?

"FUD" is a pretty harsh label to give so quickly, and I
don't understand if that's spoken as a chair running the
process or as an individual within the RG.  I'm happy to
be shouted down or simply counted as being outside the
rough consensus, if that's the case, but can you clarify
what hat you're wearing when you do so?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

Date: Wed, 11 Mar 2009 17:38:42 +0000
From: Stephen Farrell <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:

> I never said BSP was far from ready.

Does the phrase rubber-stamp ring a bell? I can't see what
else you could have meant. Maybe you mis-spoke in that
case?

> Why is finishing the sec-overview draft so controversial?

It is not. Asking for the overview to be on a supposedly
critical path before the BSP and checksum drafts, and with
no technical critique of the BSP spec as the basis for the
request, is where you're basically wrong I think.

And the controversy (for me) arises from the style of your
non-review of the BSP which I characterised as FUD.

S.

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 12:26:15 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Wednesday, March 11, 2009 1:16 PM
>To: Eddy, Wesley M. (GRC-RCN0)[Verizon]
>
>>> Lastly, I'm puzzled by the fact that you asked for last call on
>>> the checksum draft which would therefore be similarly held up.
>>> Did you not really want last call?
>> 
>> 
>> I have no problem with that document being held in the RG pending
>> the BSP.  Typically things leave last call with some set of
>> requested changes and proposed resolutions ... I see the checksum
>> draft as capable of passing last call with the caveat that it's
>> held until BSP passes in order to make sure the field usage and
>> other points remain consistent.  That seems pretty natural and
>> not out of the ordinary to me.
>
>We may disagree as to that as well, but are you saying that
>you hadn't read the BSP until now and so didn't realise that
>the checksum draft would be held like that or something? Its
>puzzling otherwise that'd you'd want to last call it given your
>opinion that the BSP is so far from ready and the fact that
>it was clear that the overview wasn't going to be last called
>this time around.

I've read and commented on the mailing list about the BSP several
times in the past, as well as discussed it with you and others
in-person.  Mulitple portions of the BSP draft directly reflect
my contributions ... of course I've read it.

I never said BSP was far from ready.  I think since Peter
has been working on it that it's really improved a lot and
I also think that a published RFC of it will look a lot like
it does now ... what I said is that we should hold it until
the context it fits within is ready so that it can be properly
scoped and understood for the purposes it's fit for.  That *is*
significant for people outside the DTNRG clique.

Why is finishing the sec-overview draft so controversial?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

Date: Wed, 11 Mar 2009 17:17:39 +0000
From: Stephen Farrell <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
> Analogies suck though ... discussion should be on the real points
> and not on analogies used to season them!

That would be welcome. Feel free to start doing it.

Stephen.

Content-class: urn:content-classes:message
Date: Wed, 11 Mar 2009 13:15:45 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Eddy, Wesley M. \(GRC-RCN0\)[Verizon]" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

But what we have is a document that specifies security mechanisms.  The
"how you use this stuff" is separate and not dependent.  Just because I
buy a hammer to drive nails doesn't mean that I can't also use it to
smash pumpkins.  The BSP specifies the tool - the reader can utilize
them in many different ways - including the ways illustrated in other
documents.

howie

-----Original Message-----
From: Eddy, Wesley M. (GRC-RCN0)[Verizon]
[mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 13:01
To: Weiss, Howard; Stephen Farrell
Cc: DTN
Subject: RE: [dtn-interest] RG "last call" on
draft-irtf-dtnrg-bundle-security

Howie, we know what cars look like and have roads to drive them
on already.  We don't know what DTN network operations and
management looks like and we don't have BP-based DTNs yet to run
security protocols over.

Analogies suck though ... discussion should be on the real points
and not on analogies used to season them!

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: Weiss, Howard [mailto:[email-masked]] 
>Sent: Wednesday, March 11, 2009 12:53 PM
>To: Eddy, Wesley M. (GRC-RCN0)[Verizon]; Stephen Farrell
>Cc: DTN
>Subject: RE: [dtn-interest] RG "last call" on 
>draft-irtf-dtnrg-bundle-security
>
>Wes
>
>Taking your approach, the Internet would never have been built.  We'd
>still be waiting for the grand, overarching internet architecture that
>included all the services.  And using your car engine analogy is just
>bad - it works against your argument since engines are designed and the
>cars built around them.  Sometimes they even grease 'em up really good
>and shoe-horn them into whatever vehicle they feel like.  Just like the
>cars where you had to jack up the engine to get to the spark plugs!  
>
>howie weiss
>

Date: Wed, 11 Mar 2009 17:15:35 +0000
From: Stephen Farrell <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]] 
>> Sent: Wednesday, March 11, 2009 11:16 AM
>> To: Eddy, Wesley M. (GRC-RCN0)[Verizon]
>>
>> Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>>> I'm not going to win any popularity contest today ...
>> Correct! I'm sorry to say that all I see in your mail is
>> essentially FUD.

So now I see 99% FUD, but that's a 1% improvement.

> Ok; I'm not sure whether you mean that the last call is
> not a good time to express concerns, or whether you just
> don't share those concerns.  

It is a good time to express concerns. But they should
IMO have some content. I didn't see any real content in
your mail other than just "yikes, we don't know if
something bad might happen so let's do nothing" type
statements.

> If you don't share them, it
> just means we don't have consensus at this time ...

And of course that's not needed in an RG. Nor in an IETF
WG where "rough consensus" is the goal.

> I disagree with all of your points below.

We have that in common at least:-) (Though there is
that 1% agreement below in fact.)

> 
> 
>>> I think this draft should be HELD by the RG for now, and publication
>>> postponed until some other pieces and reviews come along.  I believe
>>> it's mostly an okay document, but that it's very premature within the
>>> rest of the DTN security architecture development for us to 
>> be putting
>>> it out.
>> What "rest of the DTN security architecture development" do you mean?
>> Who's doing that? When will they be finished? Are you volunteering
>> for something?
> 
> 
> Exactly; the fact that so many of the related security
> puzzle pieces are unfinished (or unstarted) is the entire
> point.  I'm not volunteering for anything here, I'm just
> raising this as concern that we don't have sufficient
> context to evaluate the technical protocol against any
> requirements or operations concepts during the last call.

Disagree. We have a long history of knowing that protocols
can make use of authentication and confidentiality
services.

> 
> We have a very bold name "Bundle Security" on the draft
> and protocol, and then we only answer to a subset of the
> concerns that we know and agree exist ... is this *the*
> Bundle Security Protocol, or just a piece of it?  The
> name implies that it's somehow a singular solution that
> targets all bundle security woes, which is in stark
> contrast to its actual functionality.

Actually, I'd have no problem renaming the spec. It is
a bit broad. Thanks for the editorial comment. A suggested
alternative would have been welcome though.

"Very bold" and "stark contrast" are purely argumentative.

> Let's finish the sec-overview and make it incredibly clear
> there which things within it that the BSP answers to and
> which things it isn't useful for or intended for at the
> moment.  The sec-overview being completed in the sense of
> laying out the problems and giving some hint at a roadmap
> for solving them is crucial to doing the rest of the
> security work, including BSP.  I understand that some
> people have this roadmap (or at least part of it) in their
> heads, but it's not on paper in our RG docs.

Unnecessary delay for no good purpose and nowhere near
being crucial. More mere overstatement IMO.

>>> The context for the BSP strongly depends on another document
>>> (draft-irtf-dtnrg-sec-overview), which has plenty of open issues that
>>> haven't been approached yet by the RG.  Without that context, it's
>>> not possible to understand what the requirements or needed ops and
>>> management features of the BSP are.
>> Disagree. I specifically believe that BSP is fine to proceed without
>> the sec-overview. And there's lots of precedent for that elsewhere,
>> e.g. in DKIM, rfc4871 is published and in use and the overview doc
>> is still in last call more than a year later. That's actually been
>> useful as it allowed some experience to be fed back into the overview
>> (which is I agree a good bit away from being ready). I think you've
>> got that relationship backwards.
> 
> 
> Be certain that I have a very good understanding of the
> concurrent development of requirements, conops, and design.
> You can't confidently stamp a design as done and validated
> until the other pieces are present.  There are plenty of
> systems engineering texts available if you think I'm making
> this up.

You ignore the point I make wrt rfc4871 and raise a red
herring about design processes.

>>> When the sec-overview is ready, THEN the BSP can be reviewed for its
>>> adequacy to meet some portion of the security concerns, and the realm
>>> of its applicability towards those concerns can be understood and
>>> evaluated.  
>> See above.
> 
> 
> I infer you think it's fine to build a car engine without qualifying
> the gearbox, throttle mechanism, or chassis frame that it has to work
> with and within.

Pointless distracting analogies? No thanks.

There are many examples of successful security protocols that
have been deployed before everything was worked out.

And many contrary examples where spending years turned out
to be pointless time wasting.

Indeed, deploying security is generally more important than
being perfect as shown by WEP, SSL/TLS, DKIM and others and
the perfectionist (ok now I'm being argumentative;-) approach
of DNSSEC/IPsec/SMIME etc hasn't been nearly as successful.

>>> Until then, we have no idea if BSP is either necessary or
>> Its not necessary. Its optional.
>>
>>> sufficient; 
>> For what? If you have some use-cases that'd be interesting,
>> and content-ful.
> 
> 
> "Necessary and sufficient" was in regards to meeting the needs of
> "DTN Security".

You've not specified a single relevant thing that the BSP
can't do or does wrong. If you have some "needs of DTN security"
in mind, you need to be more specific. If you just don't know
what that might mean, then perhaps you're the wrong person
to comment.

> 
> 
>>> it's just bolt-on crypto, 
>> TBBA is not a good criticism.
> 
> 
> I have no idea what this means ... Tampa Bay Builders Association?
> Texas Bangus Breeders Association?  Google was no help.

Scroll down a bit. [1] Its the one where it says "fallacious
argument technique"

   [1] http://acronyms.thefreedictionary.com/TBBA

> 
> 
>>> and there's not yet a "total
>>> package" security solution that we can see how it fits within or
>>> relates to (e.g. no KMP).
>> Disagree. DTN key management is not going to be done for quite
>> a while IMO. (I see no reason to hold up our ESP equivalent while
>> we await an ISAKMP/IKE/... bun fight to complete;-)
>>
>> Seriously, if we want there to be a DTN key management solution
>> then I think we need to do experiments with BSP to see how
>> different proposals work. That is much easier if BSP is stable
>> and implemented and an *experimental* RFC.
> 
> 
> It can be a standing I-D and that's just as easy to implement and
> experiment with ... there's no practical advantage to having an
> RFC.  And since an RFC can't be changed, it's not a good idea to
> publish if you expect changes may be needed.  

IMO: Nonsense. Getting done and an RFC published is a great
benefit in terms of getting folks to do experiments, maintaining
momentum in the RG, getting multiple implementations and all
of the other obvious good reasons we ever produce RFCs which
though they don't change can easily be obsoleted. You know
all that. The fact that you argue to the contrary is really
puzzling.

> As we've seen with
> regards to the dictionary, changes (significant ones) are being
> suggested already.

A bunch of the documents being last called now will need
to be revved as a result, including this one. That's good
and totally different from saying that we'll just hold onto
this one until someone's boiled the ocean for us which is
what you are requesting (without a single technical
justification).

>>> Furthermore, I think it's very dangerous for us to publish a security
>>> spec as an RFC without having a few eyes from the SECDIR actually
>>> verify that we've done something reasonable and confirm that we've
>>> understood our own problem space.  The fact that it's an RFC (without
>>> regard to it being Experimental or IRTF-stream rather than IETF)
>>> means that other people will see it, pick it up, and assume that it's
>>> okay, and if it's not okay, then we'll be doing a major disservice.
>>From the process p-o-v, we absolutely should not get secdir review
>> involved. It already took ages to get the IRTF stream up and (sort of)
>> running, and the IETF/IESG/directorates shouldn't be part of that
>> process other than to prevent end-runs. I've no problem if we get
>> some more security review, but I don't want that getting embedded
>> in the process. Feel free to send links to your favorite security
>> types, but don't ask DTNRG to wait for that for documents that've
>> been drafts for a number of years already. (And I say all that as
>> a secdir member.)
>>
>> Secondly, delaying on the basis of some possible unspecified
>> "major disservice" seems to me plain silly. If you've some specifics
>> then what are they? How could we finish anything on the basis
>> of such content-free criticism?
> 
> 
> The normal IETF RFC stream involves SECDIR review which results
> in DISCUSS blocks from the IESG on any documents with security
> concerns (even minor wording-related ones).  The IRTF stream
> has no such IESG review gate for technical content, only for
> verifying non-overlap with IETF work.  RFCs are very typically
> misunderstood as being IETF work, in fact the DTN RFCs are
> cited in a few published papers and articles as IETF work.  Due
> to this misconception and the permanence of RFC publication, we
> need to be sure some outside security experts verify that we've
> done a reasonable job.  

That's wrong in many ways.

IRTF documents are deliberately not subject to the usual IETF
review process and properly so.

We don't work to anyone's "typical misunderstanding" and nor
should we. Nor does the IETF for that matter.

Your argument above would apply to everything from the IRTF
(that's how secdir operates, not selectively, same for other
directorates) so please take that argument to the IRSG list
if you really want full IETF LC for all IRTF documents.

Again, go find an "outside security expert" if you like. Such
a real review would be welcome.

> Are we so eager to rubber-stamp a document
> as an RFC rather than an I-D that we can't wait a couple of months
> for some DTN-outsiders to read it?

Anyone who wants can read it. The suggestion of rubber-stamping
is frankly annoying and simply more FUD.

>> Lastly, I'm puzzled by the fact that you asked for last call on
>> the checksum draft which would therefore be similarly held up.
>> Did you not really want last call?
> 
> 
> I have no problem with that document being held in the RG pending
> the BSP.  Typically things leave last call with some set of
> requested changes and proposed resolutions ... I see the checksum
> draft as capable of passing last call with the caveat that it's
> held until BSP passes in order to make sure the field usage and
> other points remain consistent.  That seems pretty natural and
> not out of the ordinary to me.

We may disagree as to that as well, but are you saying that
you hadn't read the BSP until now and so didn't realise that
the checksum draft would be held like that or something? Its
puzzling otherwise that'd you'd want to last call it given your
opinion that the BSP is so far from ready and the fact that
it was clear that the overview wasn't going to be last called
this time around.

Stephen.

> 
> 
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>  

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: "Weiss, Howard (JSC-ZF)" <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 12:00:40 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

Howie, we know what cars look like and have roads to drive them
on already.  We don't know what DTN network operations and
management looks like and we don't have BP-based DTNs yet to run
security protocols over.

Analogies suck though ... discussion should be on the real points
and not on analogies used to season them!

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: Weiss, Howard [mailto:[email-masked]] 
>Sent: Wednesday, March 11, 2009 12:53 PM
>To: Eddy, Wesley M. (GRC-RCN0)[Verizon]; Stephen Farrell
>Cc: DTN
>Subject: RE: [dtn-interest] RG "last call" on 
>draft-irtf-dtnrg-bundle-security
>
>Wes
>
>Taking your approach, the Internet would never have been built.  We'd
>still be waiting for the grand, overarching internet architecture that
>included all the services.  And using your car engine analogy is just
>bad - it works against your argument since engines are designed and the
>cars built around them.  Sometimes they even grease 'em up really good
>and shoe-horn them into whatever vehicle they feel like.  Just like the
>cars where you had to jack up the engine to get to the spark plugs!  
>
>howie weiss
>

Date: Wed, 11 Mar 2009 18:53:24 +0200
From: Teemu <[email-masked]>
To: Stephen Farrell <[email-masked]>, "Burleigh, Scott C" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

I would view CBHE as a mechanism that a CL designer could reuse. I can
imagine designing a CL, based on the TCPCL for example, that incorporates
the compression. In such a case I could signal the authority that should be
used for decompression prior to sending any bundles, similarly to how most
existing header compression mechanisms start out by signaling a compression
context. Or if nothing is signaled default to "cbhe.dtnrg.org". Allowing
this would require text like "the default authority component is
'cbhe.dtnrg.org' but MAY be determined through an external mechanism" or
somesuch.

This makes sense if multiple bundles are sent across the CL connection (all
of which have EIDs from the same authority) as the cost of transmitting the
authority string is spread across all the bundles. Even if contacts are
short, I could store this 'context' and reuse it whenever I meet the same
node.

Now, this does not solve interoperability where a bundle could contain EIDs
from different authorities. However, it would solve the scenario where I
have one node forwarding traffic for two DTNs with different authorities. To
solve interoperability would require a more elaborate context that could
include mappings for multiple EIDs, which would be encoded as SDNVs in the
bundle headers.

I understand this spec is designed to solve a very specific problem in a
specific domain in as lightweight way as possible, and as such it's
perfectly fine by me. I was just thinking about whether I could use this
mechanism in the types of scenarios that we work with (human mobile ad hoc
networks). Perhaps a more generic header compression mechanism could be
designed to compress not only the EIDs, but other fields as well. Such
mechanism would of course be completely orthogonal to this spec.

Cheers,
-Teemu

On 11.3.2009 17.51, "Stephen Farrell" <[email-masked]> wrote:

> 
> Total hack so feel free to ignore this even if its not
> broken:-)
> 
> CBHE is a CL. Therefore its fair to assume a receiver
> knows something about the previous-hop BA.
> 
> In particular for non-IP CLs, we could just assume the
> receiver "knows" the right authority-part to put back
> into a decompressed EID. (So I suspect the space case
> would be covered.)
> 
> For an IP-based CL, if the receiver doesn't already know
> based on the sending IP address, (or IPsec SA, whatever),
> a well-connected receiver could do a reverse DNS lookup
> of some sort, or a look-up analogous to a mail blocklist
> check, and its just uses the relevant DNS name. (Oops,
> then CBHE has a potential dependency on DNSSEC;-)
> 
> I dunno how a USB stick'd work though, but presumably
> CBHE isn't really needed there.
> 
> I dunno how an only-locally connected IP-based CL would
> work. (Where DNS is unavailable.) Maybe have an optional
> authority part in the encoding? But again, is CBHE
> really needed for such CLs?
> 
> If all else fails, use "cbhe.dtnrg.org" (or whatever
> we pick)
> 
> Would something like that work?
> S.
> 
> Burleigh, Scott C wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Eddy, Wesley M.
>>> (GRC-RCN0)[Verizon]
>>> Sent: Wednesday, March 11, 2009 7:17 AM
>>> To: Stephen Farrell; DTN
>>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>>> 
>>> 
>>> I believe this is "ready to publish" aside from one facet
>>> that's nearly editorial.
>>> 
>>> Instead of "dtn://cbhe.ccsds.org/9.37" (as an example),I
>>> think it would more appropriately be:
>>> dtn://cbhe.dtnrg/ccsds/9.37
>>> 
>>> or more generically:
>>> dtn://cbhe.dtnrg/<BODY-GOVERNING-NODE-NUMBERS>/<NODE-NUMBER>.<SERVICE-
>>> NUMBER>
>>> 
>>> The reason I suggest replacing the "ccsds.org" string with
>>> "dtnrg" is that it seems very inappropriate for us to write
>>> a spec in DTNRG using another body's name without any kind
>>> of formal liason.  Wouldn't we be torqued if WiMax Forum or
>>> some other SDO started defining specs with "dtnrg" strings
>>> embedded in them that we'd never seen or agreed to formally?
>>> 
>>> Instead, I suggest adding the BODY-GOVERNING-NODE-NUMBERS
>>> field to the URI so that we can differentiate between CCSDS
>>> use of spacecraft IDs, or other numbering authorities that
>>> may have their own registries used to generate node numbers.
>> 
>> Wes, I think there are two points here.
>> 
>> First, I see what you're saying about defining a DTNRG spec in terms of
>> another organization's name, and I would certainly be fine with changing from
>> "cbhe.ccsds.org" to "cbhe.dtnrg.org".
>> 
>> But the problem with adding the name of the node number assignment
>> organization to the CBHE-style URI is that we have no way of recovering it
>> during decompression.  I wrote about this in an earlier email on this thread,
>> posted yesterday a little after 5 PM my time, responding to a comment from
>> Stephen: as CBHE is currently written, there's no way to carry that name in
>> either compressed or uncompressed form.
>> 
>> Adding this little bit of hierarchical structure is of course a very
>> reasonable thing to propose -- we do it all the time -- but in this case I
>> think it would weaken the spec.  It would bloat the compressed bundle
>> somewhat, and in the event that we find we need to accommodate multiple node
>> number allocation authorities there are other (admittedly less elegant) ways
>> to do it.  The cost of this change being assured and the benefit being kind
>> of speculative, I think it's not a good bet.
>> 
>>> Other than that ... it looks like a solid draft to me and I
>>> think it should go forward.
>> 
>> Thanks.
>> 
>> Scott
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Date: Wed, 11 Mar 2009 12:52:32 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Eddy, Wesley M. \(GRC-RCN0\)[Verizon]" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

Wes

Taking your approach, the Internet would never have been built.  We'd
still be waiting for the grand, overarching internet architecture that
included all the services.  And using your car engine analogy is just
bad - it works against your argument since engines are designed and the
cars built around them.  Sometimes they even grease 'em up really good
and shoe-horn them into whatever vehicle they feel like.  Just like the
cars where you had to jack up the engine to get to the spark plugs!  

howie weiss

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Eddy, Wesley M. (GRC-RCN0)[Verizon]
Sent: Wednesday, March 11, 2009 12:38
To: Stephen Farrell
Cc: DTN
Subject: Re: [dtn-interest] RG "last call" on
draft-irtf-dtnrg-bundle-security

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Wednesday, March 11, 2009 11:16 AM
>To: Eddy, Wesley M. (GRC-RCN0)[Verizon]
>
>Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>> 
>> I'm not going to win any popularity contest today ...
>
>Correct! I'm sorry to say that all I see in your mail is
>essentially FUD.

Ok; I'm not sure whether you mean that the last call is
not a good time to express concerns, or whether you just
don't share those concerns.  If you don't share them, it
just means we don't have consensus at this time ...

I disagree with all of your points below.

>> I think this draft should be HELD by the RG for now, and publication
>> postponed until some other pieces and reviews come along.  I believe
>> it's mostly an okay document, but that it's very premature within the
>> rest of the DTN security architecture development for us to 
>be putting
>> it out.
>
>What "rest of the DTN security architecture development" do you mean?
>Who's doing that? When will they be finished? Are you volunteering
>for something?

Exactly; the fact that so many of the related security
puzzle pieces are unfinished (or unstarted) is the entire
point.  I'm not volunteering for anything here, I'm just
raising this as concern that we don't have sufficient
context to evaluate the technical protocol against any
requirements or operations concepts during the last call.

We have a very bold name "Bundle Security" on the draft
and protocol, and then we only answer to a subset of the
concerns that we know and agree exist ... is this *the*
Bundle Security Protocol, or just a piece of it?  The
name implies that it's somehow a singular solution that
targets all bundle security woes, which is in stark
contrast to its actual functionality.

Let's finish the sec-overview and make it incredibly clear
there which things within it that the BSP answers to and
which things it isn't useful for or intended for at the
moment.  The sec-overview being completed in the sense of
laying out the problems and giving some hint at a roadmap
for solving them is crucial to doing the rest of the
security work, including BSP.  I understand that some
people have this roadmap (or at least part of it) in their
heads, but it's not on paper in our RG docs.

>> The context for the BSP strongly depends on another document
>> (draft-irtf-dtnrg-sec-overview), which has plenty of open issues that
>> haven't been approached yet by the RG.  Without that context, it's
>> not possible to understand what the requirements or needed ops and
>> management features of the BSP are.
>
>Disagree. I specifically believe that BSP is fine to proceed without
>the sec-overview. And there's lots of precedent for that elsewhere,
>e.g. in DKIM, rfc4871 is published and in use and the overview doc
>is still in last call more than a year later. That's actually been
>useful as it allowed some experience to be fed back into the overview
>(which is I agree a good bit away from being ready). I think you've
>got that relationship backwards.

Be certain that I have a very good understanding of the
concurrent development of requirements, conops, and design.
You can't confidently stamp a design as done and validated
until the other pieces are present.  There are plenty of
systems engineering texts available if you think I'm making
this up.

>> When the sec-overview is ready, THEN the BSP can be reviewed for its
>> adequacy to meet some portion of the security concerns, and the realm
>> of its applicability towards those concerns can be understood and
>> evaluated.  
>
>See above.

I infer you think it's fine to build a car engine without qualifying
the gearbox, throttle mechanism, or chassis frame that it has to work
with and within.

>> Until then, we have no idea if BSP is either necessary or
>
>Its not necessary. Its optional.
>
>> sufficient; 
>
>For what? If you have some use-cases that'd be interesting,
>and content-ful.

"Necessary and sufficient" was in regards to meeting the needs of
"DTN Security".

>> it's just bolt-on crypto, 
>
>TBBA is not a good criticism.

I have no idea what this means ... Tampa Bay Builders Association?
Texas Bangus Breeders Association?  Google was no help.

>> and there's not yet a "total
>> package" security solution that we can see how it fits within or
>> relates to (e.g. no KMP).
>
>Disagree. DTN key management is not going to be done for quite
>a while IMO. (I see no reason to hold up our ESP equivalent while
>we await an ISAKMP/IKE/... bun fight to complete;-)
>
>Seriously, if we want there to be a DTN key management solution
>then I think we need to do experiments with BSP to see how
>different proposals work. That is much easier if BSP is stable
>and implemented and an *experimental* RFC.

It can be a standing I-D and that's just as easy to implement and
experiment with ... there's no practical advantage to having an
RFC.  And since an RFC can't be changed, it's not a good idea to
publish if you expect changes may be needed.  As we've seen with
regards to the dictionary, changes (significant ones) are being
suggested already.

>> Furthermore, I think it's very dangerous for us to publish a security
>> spec as an RFC without having a few eyes from the SECDIR actually
>> verify that we've done something reasonable and confirm that we've
>> understood our own problem space.  The fact that it's an RFC (without
>> regard to it being Experimental or IRTF-stream rather than IETF)
>> means that other people will see it, pick it up, and assume that it's
>> okay, and if it's not okay, then we'll be doing a major disservice.
>
>From the process p-o-v, we absolutely should not get secdir review
>involved. It already took ages to get the IRTF stream up and (sort of)
>running, and the IETF/IESG/directorates shouldn't be part of that
>process other than to prevent end-runs. I've no problem if we get
>some more security review, but I don't want that getting embedded
>in the process. Feel free to send links to your favorite security
>types, but don't ask DTNRG to wait for that for documents that've
>been drafts for a number of years already. (And I say all that as
>a secdir member.)
>
>Secondly, delaying on the basis of some possible unspecified
>"major disservice" seems to me plain silly. If you've some specifics
>then what are they? How could we finish anything on the basis
>of such content-free criticism?

The normal IETF RFC stream involves SECDIR review which results
in DISCUSS blocks from the IESG on any documents with security
concerns (even minor wording-related ones).  The IRTF stream
has no such IESG review gate for technical content, only for
verifying non-overlap with IETF work.  RFCs are very typically
misunderstood as being IETF work, in fact the DTN RFCs are
cited in a few published papers and articles as IETF work.  Due
to this misconception and the permanence of RFC publication, we
need to be sure some outside security experts verify that we've
done a reasonable job.  Are we so eager to rubber-stamp a document
as an RFC rather than an I-D that we can't wait a couple of months
for some DTN-outsiders to read it?

>Lastly, I'm puzzled by the fact that you asked for last call on
>the checksum draft which would therefore be similarly held up.
>Did you not really want last call?

I have no problem with that document being held in the RG pending
the BSP.  Typically things leave last call with some set of
requested changes and proposed resolutions ... I see the checksum
draft as capable of passing last call with the caveat that it's
held until BSP passes in order to make sure the field usage and
other points remain consistent.  That seems pretty natural and
not out of the ordinary to me.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------
 
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 11:38:01 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Wednesday, March 11, 2009 11:16 AM
>To: Eddy, Wesley M. (GRC-RCN0)[Verizon]
>
>Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>> 
>> I'm not going to win any popularity contest today ...
>
>Correct! I'm sorry to say that all I see in your mail is
>essentially FUD.

Ok; I'm not sure whether you mean that the last call is
not a good time to express concerns, or whether you just
don't share those concerns.  If you don't share them, it
just means we don't have consensus at this time ...

I disagree with all of your points below.

>> I think this draft should be HELD by the RG for now, and publication
>> postponed until some other pieces and reviews come along.  I believe
>> it's mostly an okay document, but that it's very premature within the
>> rest of the DTN security architecture development for us to 
>be putting
>> it out.
>
>What "rest of the DTN security architecture development" do you mean?
>Who's doing that? When will they be finished? Are you volunteering
>for something?

Exactly; the fact that so many of the related security
puzzle pieces are unfinished (or unstarted) is the entire
point.  I'm not volunteering for anything here, I'm just
raising this as concern that we don't have sufficient
context to evaluate the technical protocol against any
requirements or operations concepts during the last call.

We have a very bold name "Bundle Security" on the draft
and protocol, and then we only answer to a subset of the
concerns that we know and agree exist ... is this *the*
Bundle Security Protocol, or just a piece of it?  The
name implies that it's somehow a singular solution that
targets all bundle security woes, which is in stark
contrast to its actual functionality.

Let's finish the sec-overview and make it incredibly clear
there which things within it that the BSP answers to and
which things it isn't useful for or intended for at the
moment.  The sec-overview being completed in the sense of
laying out the problems and giving some hint at a roadmap
for solving them is crucial to doing the rest of the
security work, including BSP.  I understand that some
people have this roadmap (or at least part of it) in their
heads, but it's not on paper in our RG docs.

>> The context for the BSP strongly depends on another document
>> (draft-irtf-dtnrg-sec-overview), which has plenty of open issues that
>> haven't been approached yet by the RG.  Without that context, it's
>> not possible to understand what the requirements or needed ops and
>> management features of the BSP are.
>
>Disagree. I specifically believe that BSP is fine to proceed without
>the sec-overview. And there's lots of precedent for that elsewhere,
>e.g. in DKIM, rfc4871 is published and in use and the overview doc
>is still in last call more than a year later. That's actually been
>useful as it allowed some experience to be fed back into the overview
>(which is I agree a good bit away from being ready). I think you've
>got that relationship backwards.

Be certain that I have a very good understanding of the
concurrent development of requirements, conops, and design.
You can't confidently stamp a design as done and validated
until the other pieces are present.  There are plenty of
systems engineering texts available if you think I'm making
this up.

>> When the sec-overview is ready, THEN the BSP can be reviewed for its
>> adequacy to meet some portion of the security concerns, and the realm
>> of its applicability towards those concerns can be understood and
>> evaluated.  
>
>See above.

I infer you think it's fine to build a car engine without qualifying
the gearbox, throttle mechanism, or chassis frame that it has to work
with and within.

>> Until then, we have no idea if BSP is either necessary or
>
>Its not necessary. Its optional.
>
>> sufficient; 
>
>For what? If you have some use-cases that'd be interesting,
>and content-ful.

"Necessary and sufficient" was in regards to meeting the needs of
"DTN Security".

>> it's just bolt-on crypto, 
>
>TBBA is not a good criticism.

I have no idea what this means ... Tampa Bay Builders Association?
Texas Bangus Breeders Association?  Google was no help.

>> and there's not yet a "total
>> package" security solution that we can see how it fits within or
>> relates to (e.g. no KMP).
>
>Disagree. DTN key management is not going to be done for quite
>a while IMO. (I see no reason to hold up our ESP equivalent while
>we await an ISAKMP/IKE/... bun fight to complete;-)
>
>Seriously, if we want there to be a DTN key management solution
>then I think we need to do experiments with BSP to see how
>different proposals work. That is much easier if BSP is stable
>and implemented and an *experimental* RFC.

It can be a standing I-D and that's just as easy to implement and
experiment with ... there's no practical advantage to having an
RFC.  And since an RFC can't be changed, it's not a good idea to
publish if you expect changes may be needed.  As we've seen with
regards to the dictionary, changes (significant ones) are being
suggested already.

>> Furthermore, I think it's very dangerous for us to publish a security
>> spec as an RFC without having a few eyes from the SECDIR actually
>> verify that we've done something reasonable and confirm that we've
>> understood our own problem space.  The fact that it's an RFC (without
>> regard to it being Experimental or IRTF-stream rather than IETF)
>> means that other people will see it, pick it up, and assume that it's
>> okay, and if it's not okay, then we'll be doing a major disservice.
>
>From the process p-o-v, we absolutely should not get secdir review
>involved. It already took ages to get the IRTF stream up and (sort of)
>running, and the IETF/IESG/directorates shouldn't be part of that
>process other than to prevent end-runs. I've no problem if we get
>some more security review, but I don't want that getting embedded
>in the process. Feel free to send links to your favorite security
>types, but don't ask DTNRG to wait for that for documents that've
>been drafts for a number of years already. (And I say all that as
>a secdir member.)
>
>Secondly, delaying on the basis of some possible unspecified
>"major disservice" seems to me plain silly. If you've some specifics
>then what are they? How could we finish anything on the basis
>of such content-free criticism?

The normal IETF RFC stream involves SECDIR review which results
in DISCUSS blocks from the IESG on any documents with security
concerns (even minor wording-related ones).  The IRTF stream
has no such IESG review gate for technical content, only for
verifying non-overlap with IETF work.  RFCs are very typically
misunderstood as being IETF work, in fact the DTN RFCs are
cited in a few published papers and articles as IETF work.  Due
to this misconception and the permanence of RFC publication, we
need to be sure some outside security experts verify that we've
done a reasonable job.  Are we so eager to rubber-stamp a document
as an RFC rather than an I-D that we can't wait a couple of months
for some DTN-outsiders to read it?

>Lastly, I'm puzzled by the fact that you asked for last call on
>the checksum draft which would therefore be similarly held up.
>Did you not really want last call?

I have no problem with that document being held in the RG pending
the BSP.  Typically things leave last call with some set of
requested changes and proposed resolutions ... I see the checksum
draft as capable of passing last call with the caveat that it's
held until BSP passes in order to make sure the field usage and
other points remain consistent.  That seems pretty natural and
not out of the ordinary to me.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Wed, 11 Mar 2009 09:36:31 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: David Young [mailto:[email-masked]]
> Sent: Wednesday, March 11, 2009 9:16 AM
> To: Burleigh, Scott C
> Cc: DTN
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> This isn't an elegant solution either, but you could use that 8th SDNV
> (which is always zero, as it is the reserved administration service
> number) to identify the authority.

Yes, it's always appealing to try to find something useful to do with that 8th SDNV.

> I say less elegant because you'd
> need a lookup table of number:authority.  Start with 0:cbhe.dtnrg.org
> (or 0:cbhe.ccsds.org or 0:dtnrg.org/cbhe).  Since CBHE has to be
> negotiated/configured between the endpoints of the CL anyways, why not
> just define a lookup table while you're at it.  It could be optional
> (2 endpoints could agree they are using cbhe.dtnrg.org only, and pass
> only 0's).

Having a lookup table doesn't bother me that much in itself; those numbers would likely be no more dynamic than assigned protocol numbers and port numbers.  But...

> This solution has limited utility, as all of the 4
> addresses must use the same authority.

Right, that's the real problem with this idea.  If you know all four EIDs are subject to the same authority, how much value does that authority ID really add?

> It does allow a private
> network to use CBHE internally without worrying about overriding
> ccsds/dtnrg.

But I think a private network can already do that, if it's truly private.

> I think that a network homogenous enough to include
> different authorities would probably be on the terrestrial internet,
> where shaving bytes off the dictionary isn't so important.

Yes, that's one reason I haven't felt a lot of urgency about addressing this.

Scott

From: "Henry B. Hotz" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Wed, 11 Mar 2009 09:33:51 -0700
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

On Mar 11, 2009, at 6:20 AM, Durst, Robert C. wrote:

> I concur with the notion of having separate conformance statements  
> for the protocol functions and the ciphersuites.

I note that Kerberos has RFC 3961 defining some algorithms and  
profiles for new algorithms (like AES, defined in RFC 3962).  That's  
separate from RFC 4120 defining the protocol.  The pair of them  
obsoleted RFC 1510, which defined both algorithms and protocol.

OTOH I don't believe TLS has split yet.  It's been around about 10  
years and has added algorithms.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Stephen Farrell <[email-masked]>, "Burleigh, Scott C" <[email-masked]>
Date: Wed, 11 Mar 2009 11:33:49 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

A similar idea occurred to me ... I'm interested to hear
what Scott thinks :).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Stephen Farrell
>Sent: Wednesday, March 11, 2009 11:51 AM
>To: Burleigh, Scott C
>Cc: DTN
>Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>
>
>Total hack so feel free to ignore this even if its not
>broken:-)
>
>CBHE is a CL. Therefore its fair to assume a receiver
>knows something about the previous-hop BA.
>
>In particular for non-IP CLs, we could just assume the
>receiver "knows" the right authority-part to put back
>into a decompressed EID. (So I suspect the space case
>would be covered.)
>
>For an IP-based CL, if the receiver doesn't already know
>based on the sending IP address, (or IPsec SA, whatever),
>a well-connected receiver could do a reverse DNS lookup
>of some sort, or a look-up analogous to a mail blocklist
>check, and its just uses the relevant DNS name. (Oops,
>then CBHE has a potential dependency on DNSSEC;-)
>
>I dunno how a USB stick'd work though, but presumably
>CBHE isn't really needed there.
>
>I dunno how an only-locally connected IP-based CL would
>work. (Where DNS is unavailable.) Maybe have an optional
>authority part in the encoding? But again, is CBHE
>really needed for such CLs?
>
>If all else fails, use "cbhe.dtnrg.org" (or whatever
>we pick)
>
>Would something like that work?
>S.
>
>Burleigh, Scott C wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of 
>Eddy, Wesley M.
>>> (GRC-RCN0)[Verizon]
>>> Sent: Wednesday, March 11, 2009 7:17 AM
>>> To: Stephen Farrell; DTN
>>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>>>
>>>
>>> I believe this is "ready to publish" aside from one facet
>>> that's nearly editorial.
>>>
>>> Instead of "dtn://cbhe.ccsds.org/9.37" (as an example),I
>>> think it would more appropriately be:
>>> dtn://cbhe.dtnrg/ccsds/9.37
>>>
>>> or more generically:
>>> 
>dtn://cbhe.dtnrg/<BODY-GOVERNING-NODE-NUMBERS>/<NODE-NUMBER>.<SERVICE-
>>> NUMBER>
>>>
>>> The reason I suggest replacing the "ccsds.org" string with
>>> "dtnrg" is that it seems very inappropriate for us to write
>>> a spec in DTNRG using another body's name without any kind
>>> of formal liason.  Wouldn't we be torqued if WiMax Forum or
>>> some other SDO started defining specs with "dtnrg" strings
>>> embedded in them that we'd never seen or agreed to formally?
>>>
>>> Instead, I suggest adding the BODY-GOVERNING-NODE-NUMBERS
>>> field to the URI so that we can differentiate between CCSDS
>>> use of spacecraft IDs, or other numbering authorities that
>>> may have their own registries used to generate node numbers.
>> 
>> Wes, I think there are two points here.
>> 
>> First, I see what you're saying about defining a DTNRG spec 
>in terms of another organization's name, and I would certainly 
>be fine with changing from "cbhe.ccsds.org" to "cbhe.dtnrg.org".
>> 
>> But the problem with adding the name of the node number 
>assignment organization to the CBHE-style URI is that we have 
>no way of recovering it during decompression.  I wrote about 
>this in an earlier email on this thread, posted yesterday a 
>little after 5 PM my time, responding to a comment from 
>Stephen: as CBHE is currently written, there's no way to carry 
>that name in either compressed or uncompressed form.  
>> 
>> Adding this little bit of hierarchical structure is of 
>course a very reasonable thing to propose -- we do it all the 
>time -- but in this case I think it would weaken the spec.  It 
>would bloat the compressed bundle somewhat, and in the event 
>that we find we need to accommodate multiple node number 
>allocation authorities there are other (admittedly less 
>elegant) ways to do it.  The cost of this change being assured 
>and the benefit being kind of speculative, I think it's not a good bet.
>> 
>>> Other than that ... it looks like a solid draft to me and I
>>> think it should go forward.
>> 
>> Thanks.
>> 
>> Scott
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Wed, 11 Mar 2009 09:26:25 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, March 11, 2009 8:51 AM
> To: Burleigh, Scott C
> Cc: DTN
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> 
> Total hack so feel free to ignore this even if its not
> broken:-)
> 
> CBHE is a CL.

Interesting.  I think of CBHE as simply a compression convention that multiple CL adapters might conform to.  But since any CL adapter is actually a complete stack all the way down to layer 1 (if it's not, you don't have interoperability between BP neighbors), I guess one could think of CBHE as an extremely thin top layer that might be common to any number of CL adapter stacks.  Since that top layer is what BP talks to, I guess CBHE might very well look like "the CL" to BP.

> Therefore it's fair to assume a receiver
> knows something about the previous-hop BA.
> 
> In particular for non-IP CLs, we could just assume the
> receiver "knows" the right authority-part to put back
> into a decompressed EID. (So I suspect the space case
> would be covered.)
> 
> For an IP-based CL, if the receiver doesn't already know
> based on the sending IP address, (or IPsec SA, whatever),
> a well-connected receiver could do a reverse DNS lookup
> of some sort, or a look-up analogous to a mail blocklist
> check, and its just uses the relevant DNS name. (Oops,
> then CBHE has a potential dependency on DNSSEC;-)
> 
> I dunno how a USB stick'd work though, but presumably
> CBHE isn't really needed there.
> 
> I dunno how an only-locally connected IP-based CL would
> work. (Where DNS is unavailable.) Maybe have an optional
> authority part in the encoding? But again, is CBHE
> really needed for such CLs?
> 
> If all else fails, use "cbhe.dtnrg.org" (or whatever
> we pick)
> 
> Would something like that work?

I think it could be made to work, Stephen, but I hesitate to base an RFC on it.

These are experimental RFCs anyway, right?  If people end up loving CBHE and wanting to use it broadly in a large-scale DTN where accommodation of multiple node number assignment authorities becomes an issue, I would be glad to revisit this issue then and revise the spec as necessary before putting it on the standards track.

But as desirable as flexibility always is, you always pay a price for it.  At this point, the benefit of the flexibility we're talking about is still awfully speculative.  For now I'd prefer to stick to something that's dead simple and extremely efficient even if it's maybe not powerful enough to scale up to a global DTN -- optimizing for the known current need rather than for the possible future need.

Scott

> Burleigh, Scott C wrote:
> >> -----Original Message-----
> >> From: [email-masked] [mailto:dtn-
> >> [email-masked]] On Behalf Of Eddy, Wesley
> M.
> >> (GRC-RCN0)[Verizon]
> >> Sent: Wednesday, March 11, 2009 7:17 AM
> >> To: Stephen Farrell; DTN
> >> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> >>
> >>
> >> I believe this is "ready to publish" aside from one facet
> >> that's nearly editorial.
> >>
> >> Instead of "dtn://cbhe.ccsds.org/9.37" (as an example),I
> >> think it would more appropriately be:
> >> dtn://cbhe.dtnrg/ccsds/9.37
> >>
> >> or more generically:
> >> dtn://cbhe.dtnrg/<BODY-GOVERNING-NODE-NUMBERS>/<NODE-NUMBER>.<SERVICE-
> >> NUMBER>
> >>
> >> The reason I suggest replacing the "ccsds.org" string with
> >> "dtnrg" is that it seems very inappropriate for us to write
> >> a spec in DTNRG using another body's name without any kind
> >> of formal liason.  Wouldn't we be torqued if WiMax Forum or
> >> some other SDO started defining specs with "dtnrg" strings
> >> embedded in them that we'd never seen or agreed to formally?
> >>
> >> Instead, I suggest adding the BODY-GOVERNING-NODE-NUMBERS
> >> field to the URI so that we can differentiate between CCSDS
> >> use of spacecraft IDs, or other numbering authorities that
> >> may have their own registries used to generate node numbers.
> >
> > Wes, I think there are two points here.
> >
> > First, I see what you're saying about defining a DTNRG spec in terms of
> another organization's name, and I would certainly be fine with changing
> from "cbhe.ccsds.org" to "cbhe.dtnrg.org".
> >
> > But the problem with adding the name of the node number assignment
> organization to the CBHE-style URI is that we have no way of recovering it
> during decompression.  I wrote about this in an earlier email on this
> thread, posted yesterday a little after 5 PM my time, responding to a
> comment from Stephen: as CBHE is currently written, there's no way to carry
> that name in either compressed or uncompressed form.
> >
> > Adding this little bit of hierarchical structure is of course a very
> reasonable thing to propose -- we do it all the time -- but in this case I
> think it would weaken the spec.  It would bloat the compressed bundle
> somewhat, and in the event that we find we need to accommodate multiple
> node number allocation authorities there are other (admittedly less
> elegant) ways to do it.  The cost of this change being assured and the
> benefit being kind of speculative, I think it's not a good bet.

Date: Wed, 11 Mar 2009 12:15:39 -0400
From: David Young <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

This isn't an elegant solution either, but you could use that 8th SDNV
(which is always zero, as it is the reserved administration service
number) to identify the authority.  I say less elegant because you'd
need a lookup table of number:authority.  Start with 0:cbhe.dtnrg.org
(or 0:cbhe.ccsds.org or 0:dtnrg.org/cbhe).  Since CBHE has to be
negotiated/configured between the endpoints of the CL anyways, why not
just define a lookup table while you're at it.  It could be optional
(2 endpoints could agree they are using cbhe.dtnrg.org only, and pass
only 0's).  This solution has limited utility, as all of the 4
addresses must use the same authority.  It does allow a private
network to use CBHE internally without worrying about overriding
ccsds/dtnrg.  I think that a network homogenous enough to include
different authorities would probably be on the terrestrial internet,
where shaving bytes off the dictionary isn't so important.

> Adding this little bit of hierarchical structure is of course a very reasonable thing to propose -- we do it all the time -- but in this case I think it would weaken the spec. �It would bloat the compressed bundle somewhat, and in the event that we find we need to accommodate multiple node number allocation authorities there are other (admittedly less elegant) ways to do it. �The cost of this change being assured and the benefit being kind of speculative, I think it's not a good bet.

-- 
David Young

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, "Robert C. Durst" <[email-masked]>
Date: Wed, 11 Mar 2009 12:13:09 -0400
Cc: dtn interest <[email-masked]>
Subject: [dtn-interest] Re(2):  "last call" comments on the latest BSP

Hi all,

sorry if my intent wasn't clear enough.

I'm NOT advocating any new docs, just change and clarification within
BSP spec.

The change would be that:-
1. there are two levels of compliance. For lack of better names I had
referred to these as "limited" and "full". I really would welcome better
suggestions.
2. "limited" means implementing BSP, and reserves ciphersuite numbers 1,
2, 3 and 4.
3. the ciphersuites labeled today as "mandatory" would be labeled
instead as "standard", and would include ESB (to Susan's point). If you
implement ciphersuites BA1, PI2, PC3 and ES4 then you must follow the
standard - you can't create your own variants

In addition, there is some advantage to having BSP even in the absence
of specific ciphersuites. The "limited" BSP knows about BAB, PIB, PCB
and ESB even though it can't act as source or destination, i.e. no crypto. 

Cheers.....Peter

On Wed, Mar 11, 2009, Stephen Farrell <[email-masked]> wrote:

>
>Hi Bob,
>
>Durst, Robert C. wrote:
>> Stephen,
>> 
>> I didn't (or at least didn't intend to) suggest creating new
>documents.  Peter suggested, and Wes and I supported, the notion of
>revising the conformance requirements.  When Peter mentioned "splitting"
>the document, I interpreted it to mean an organizational change within
>the existing document to coalesce those sections that would constitute
>protocol conformance and those that would constitute ciphersuite
>conformance.  So I don't really interpret this as something that
>requires creating new documents.
>
>Ah, that's different. Would have to think about it, but shuffling text
>is fine by me if that improves things. Concrete suggestions as to what
>to put where would be appreciated. (Originally, that's how we structured
>the doc, or at least what we tried to do.)
>
>> 
>> I agree with you that I also have not heard anyone say that they'd
>like to implement the BSP with different ciphersuites.  But I have heard
>people say that they don't feel like they can implement the BSP with
>THESE ciphersuites.  I've ported DTN to a gumstix processor, and while
>it fit, it wasn't very peppy.  I have sympathy for those folks who want
>to be very selective about the computational complexity of the
>algorithms that they choose, and yet wish to maintain conformance to the
>BSP protocol itself. 
>
>Right. So they write an I-D with their favorite ciphersuites in it.
>Just like the checksum thing. I don't see a problem with doing that
>with BSP as-is, but again, specific suggested changes would be
>welcome.
>
>> 
>> I share the concern that if we allow conformance without mandating at
>least some ciphersuite(s) we run the risk of non-interoperability, and
>so I think that the protocol operations would be a MUST and the
>ciphersuites could be a SHOULD, with the burden placed on the
>implementer to document why the ciphersuites in the (single) spec aren't
>implemented.
>
>I don't follow. Without a ciphersuite, there are no crypto'd-bundles
>and hence no interop. Again, maybe specific suggestions would clarify.
>
>> 
>> So if this were simply a conformance statement change to the current
>draft could you support it?
>
>Possibly:-) But definitely more likely if it doesn't involve
>a raft of new docs.
>
>S.
>
>
>> 
>> Bob
>> 
>> |-----Original Message-----
>> |From: Stephen Farrell [mailto:[email-masked]]
>> |Sent: Wednesday, March 11, 2009 10:59 AM
>> |To: Durst, Robert C.
>> |Cc: Eddy, Wesley M. (GRC-RCN0)[Verizon]; Peter Lovell; Symington, Susan
>> |F.; dtn interest
>> |Subject: Re: [dtn-interest] "last call" comments on the latest BSP
>> |
>> |
>> |Well I don't really get this. Right now BSP specifies some mandatory
>> |to implement ciphersuites. I've not heard anyone say they'd like to
>> |implement BSP with a different set of ciphersuites, without there
>> |being a separate draft describing that case, e.g. the checksum draft
>> |is a case in point.
>> |
>> |And I don't think creating new documents is very efficient either
>> |so I'd argue against this change I think.
>> |
>> |S.
>> |
>> |Durst, Robert C. wrote:
>> |> I concur with the notion of having separate conformance statements for
>> |the protocol functions and the ciphersuites.  I wonder if, rather than
>> |the designations of "limited" and "full" compliance, we might be a bit
>> |more specific/transparent/whatever and specify "protocol" or
>> |"protocol+ciphersuite" conformance classes.  (That said, I think that we
>> |should still strive to keep our "ciphersuite" conformance class to the
>> |minimum needed for interoperability with a "reasonable" balance between
>> |computational complexity and actual protection.  Everyone's mileage WILL
>> |vary on the definition of reasonable.)
>> |>
>> |> Bob
>> |>
>> |> |-----Original Message-----
>> |> |From: [email-masked] [mailto:dtn-
>> |> [email-masked]] On Behalf Of Eddy,
>> |Wesley
>> |> |M. (GRC-RCN0)[Verizon]
>> |> |Sent: Tuesday, March 10, 2009 4:34 PM
>> |> |To: Peter Lovell; Symington, Susan F.
>> |> |Cc: dtn interest
>> |> |Subject: Re: [dtn-interest] "last call" comments on the latest BSP
>> |> |
>> |> |>-----Original Message-----
>> |> |>From: [email-masked]
>> |> |>[mailto:[email-masked]] On
>> |> |>Behalf Of Peter Lovell
>> |> |>Sent: Tuesday, March 10, 2009 3:44 PM
>> |> |>
>> |> |>>10)   Section 4. Mandatory Ciphersuites: Do we really want
>> |> |>>implementation of the ESB ciphersuite to be optional?  Don't
>> |> |>we need at
>> |> |>>least one mandatory ciphersuite for use with the ESB? Shouldn't
>> |> |>>implementation of the ESB ciphersuite be mandatory?
>> |> |>
>> |> |>Well, this whole area is ripe for discussion next week.
>> |> |>
>> |> |>Some have said, and I have some sympathy for the position, that it
>> |> |>should be possible to have BSP code and yet not do the mandatory
>> |> |>ciphersuites. Since they require RSA support that makes them
>> |> |>"heavyweight" for small devices, but you can't be compliant unless
>> |you
>> |> |>have them.
>> |> |>
>> |> |>I've been toying with the idea of having two parts to the BSP
>> |> |>spec - one
>> |> |>for the protocol and rules and a second for the standard
>> |ciphersuites.
>> |> |>Having just BSP would be "limited compliance" and having the
>> |standard
>> |> |>suites also would be "full compliance". This will be an important
>> |issue
>> |> |>when DTN compliance is required for government contracts etc. We
>> |don't
>> |> |>want to place wasteful burdens on small devices that only
>> |> |>hinder adoption.
>> |> |>
>> |> |>If we do make this change then I'd support adding ESB4 as one of the
>> |> |>standard set.
>> |> |
>> |> |
>> |> |I would support splitting the protocol rules from the ciphersuite
>> |> |definitions.  By the time bundle protocol and BSP are in wider
>> |> |deployment (or support / compliance required for contracts), the
>> |> |algorithms du jour may have changed enough that supporting the
>> |> |protocol with other ciphersuites would be desirable.
>> |> |
>> |> |"Late binding" of the specific algorithms is worth a lot if there's
>> |> |ever an attempt to advance up the Standards Track, rather than just
>> |> |stay at Experimental.
>> |> |
>> |> |Plus, I'm one of the pesky ones that doesn't want to have to
>> |> |implement / link to RSA, bignum code, and other things that may
>> |> |not be needed or desirable in absolutely all cases.  If we're
>> |> |going to make certain ciphersuites / algorithms mandatory, then
>> |> |we better make sure with the DTN delployers that those algorithms
>> |> |make sense and are feasible in ALL deployment scenarios, otherwise
>> |> |we'll wind up with lots of "non-compliant" deployments based.  So
>> |> |far, I don't think that poll has been issued ... I would encourage
>> |> |people to look at the constraints that 6LOWPAN and ROLL have to
>> |> |work within.  For instance, in draft-ietf-roll-protocols-survey-06 :
>> |> |
>> |> |   LLNs have security considerations.  These considerations vary
>> |greatly
>> |> |   depending on application domain.  For example, deployers
>> |industrial
>> |> |   monitoring networks may impose more stringent confidentiality
>> |> |   requirements than home automation networks do.  Such requirements
>> |are
>> |> |   an important consideration in protocol design, but their variety
>> |> |   makes distilling them to a minimalist set of "necessary but not
>> |> |   sufficient" criteria is of limited use.  The criteria in this
>> |> |   document are not the only requirements and considerations in LLN
>> |> |   protocols, and as such the omission of a security criterion should
>> |> |   not be interpreted as a lack of a need for security in LLNs.
>> |> |
>> |> |Similarly, the ommission of a particular ciphersuite from the set
>> |> |of required BSP facets should not be interpreted as a lack of need
>> |> |for the security properties of that ciphersuite in some significant
>> |> |classes of DTNs, just as a lack of universal need in all DTNs.
>> |> |
>> |> |---------------------------
>> |> |Wes Eddy
>> |> |Network & Systems Architect
>> |> |Verizon FNS / NASA GRC
>> |> |Office: (216) 433-6682
>> |> |---------------------------
>> |> |
>> |> |_______________________________________________
>> |> |dtn-interest mailing list
>> |> [email-masked]
>> |> |http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> |>
>> |> _______________________________________________
>> |> dtn-interest mailing list
>> |> [email-masked]
>> |> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> |>
>> 

Date: Wed, 11 Mar 2009 15:51:05 +0000
From: Stephen Farrell <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

Total hack so feel free to ignore this even if its not
broken:-)

CBHE is a CL. Therefore its fair to assume a receiver
knows something about the previous-hop BA.

In particular for non-IP CLs, we could just assume the
receiver "knows" the right authority-part to put back
into a decompressed EID. (So I suspect the space case
would be covered.)

For an IP-based CL, if the receiver doesn't already know
based on the sending IP address, (or IPsec SA, whatever),
a well-connected receiver could do a reverse DNS lookup
of some sort, or a look-up analogous to a mail blocklist
check, and its just uses the relevant DNS name. (Oops,
then CBHE has a potential dependency on DNSSEC;-)

I dunno how a USB stick'd work though, but presumably
CBHE isn't really needed there.

I dunno how an only-locally connected IP-based CL would
work. (Where DNS is unavailable.) Maybe have an optional
authority part in the encoding? But again, is CBHE
really needed for such CLs?

If all else fails, use "cbhe.dtnrg.org" (or whatever
we pick)

Would something like that work?
S.

Burleigh, Scott C wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Eddy, Wesley M.
>> (GRC-RCN0)[Verizon]
>> Sent: Wednesday, March 11, 2009 7:17 AM
>> To: Stephen Farrell; DTN
>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>>
>>
>> I believe this is "ready to publish" aside from one facet
>> that's nearly editorial.
>>
>> Instead of "dtn://cbhe.ccsds.org/9.37" (as an example),I
>> think it would more appropriately be:
>> dtn://cbhe.dtnrg/ccsds/9.37
>>
>> or more generically:
>> dtn://cbhe.dtnrg/<BODY-GOVERNING-NODE-NUMBERS>/<NODE-NUMBER>.<SERVICE-
>> NUMBER>
>>
>> The reason I suggest replacing the "ccsds.org" string with
>> "dtnrg" is that it seems very inappropriate for us to write
>> a spec in DTNRG using another body's name without any kind
>> of formal liason.  Wouldn't we be torqued if WiMax Forum or
>> some other SDO started defining specs with "dtnrg" strings
>> embedded in them that we'd never seen or agreed to formally?
>>
>> Instead, I suggest adding the BODY-GOVERNING-NODE-NUMBERS
>> field to the URI so that we can differentiate between CCSDS
>> use of spacecraft IDs, or other numbering authorities that
>> may have their own registries used to generate node numbers.
> 
> Wes, I think there are two points here.
> 
> First, I see what you're saying about defining a DTNRG spec in terms of another organization's name, and I would certainly be fine with changing from "cbhe.ccsds.org" to "cbhe.dtnrg.org".
> 
> But the problem with adding the name of the node number assignment organization to the CBHE-style URI is that we have no way of recovering it during decompression.  I wrote about this in an earlier email on this thread, posted yesterday a little after 5 PM my time, responding to a comment from Stephen: as CBHE is currently written, there's no way to carry that name in either compressed or uncompressed form.  
> 
> Adding this little bit of hierarchical structure is of course a very reasonable thing to propose -- we do it all the time -- but in this case I think it would weaken the spec.  It would bloat the compressed bundle somewhat, and in the event that we find we need to accommodate multiple node number allocation authorities there are other (admittedly less elegant) ways to do it.  The cost of this change being assured and the benefit being kind of speculative, I think it's not a good bet.
> 
>> Other than that ... it looks like a solid draft to me and I
>> think it should go forward.
> 
> Thanks.
> 
> Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Wed, 11 Mar 2009 15:23:21 +0000
From: Stephen Farrell <[email-masked]>
To: "Durst, Robert C." <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

Hi Bob,

Durst, Robert C. wrote:
> Stephen,
> 
> I didn't (or at least didn't intend to) suggest creating new documents.  Peter suggested, and Wes and I supported, the notion of revising the conformance requirements.  When Peter mentioned "splitting" the document, I interpreted it to mean an organizational change within the existing document to coalesce those sections that would constitute protocol conformance and those that would constitute ciphersuite conformance.  So I don't really interpret this as something that requires creating new documents.

Ah, that's different. Would have to think about it, but shuffling text
is fine by me if that improves things. Concrete suggestions as to what
to put where would be appreciated. (Originally, that's how we structured
the doc, or at least what we tried to do.)

> 
> I agree with you that I also have not heard anyone say that they'd like to implement the BSP with different ciphersuites.  But I have heard people say that they don't feel like they can implement the BSP with THESE ciphersuites.  I've ported DTN to a gumstix processor, and while it fit, it wasn't very peppy.  I have sympathy for those folks who want to be very selective about the computational complexity of the algorithms that they choose, and yet wish to maintain conformance to the BSP protocol itself. 

Right. So they write an I-D with their favorite ciphersuites in it.
Just like the checksum thing. I don't see a problem with doing that
with BSP as-is, but again, specific suggested changes would be
welcome.

> 
> I share the concern that if we allow conformance without mandating at least some ciphersuite(s) we run the risk of non-interoperability, and so I think that the protocol operations would be a MUST and the ciphersuites could be a SHOULD, with the burden placed on the implementer to document why the ciphersuites in the (single) spec aren't implemented.

I don't follow. Without a ciphersuite, there are no crypto'd-bundles
and hence no interop. Again, maybe specific suggestions would clarify.

> 
> So if this were simply a conformance statement change to the current draft could you support it?

Possibly:-) But definitely more likely if it doesn't involve
a raft of new docs.

S.

> 
> Bob
> 
> |-----Original Message-----
> |From: Stephen Farrell [mailto:[email-masked]]
> |Sent: Wednesday, March 11, 2009 10:59 AM
> |To: Durst, Robert C.
> |Cc: Eddy, Wesley M. (GRC-RCN0)[Verizon]; Peter Lovell; Symington, Susan
> |F.; dtn interest
> |Subject: Re: [dtn-interest] "last call" comments on the latest BSP
> |
> |
> |Well I don't really get this. Right now BSP specifies some mandatory
> |to implement ciphersuites. I've not heard anyone say they'd like to
> |implement BSP with a different set of ciphersuites, without there
> |being a separate draft describing that case, e.g. the checksum draft
> |is a case in point.
> |
> |And I don't think creating new documents is very efficient either
> |so I'd argue against this change I think.
> |
> |S.
> |
> |Durst, Robert C. wrote:
> |> I concur with the notion of having separate conformance statements for
> |the protocol functions and the ciphersuites.  I wonder if, rather than
> |the designations of "limited" and "full" compliance, we might be a bit
> |more specific/transparent/whatever and specify "protocol" or
> |"protocol+ciphersuite" conformance classes.  (That said, I think that we
> |should still strive to keep our "ciphersuite" conformance class to the
> |minimum needed for interoperability with a "reasonable" balance between
> |computational complexity and actual protection.  Everyone's mileage WILL
> |vary on the definition of reasonable.)
> |>
> |> Bob
> |>
> |> |-----Original Message-----
> |> |From: [email-masked] [mailto:dtn-
> |> [email-masked]] On Behalf Of Eddy,
> |Wesley
> |> |M. (GRC-RCN0)[Verizon]
> |> |Sent: Tuesday, March 10, 2009 4:34 PM
> |> |To: Peter Lovell; Symington, Susan F.
> |> |Cc: dtn interest
> |> |Subject: Re: [dtn-interest] "last call" comments on the latest BSP
> |> |
> |> |>-----Original Message-----
> |> |>From: [email-masked]
> |> |>[mailto:[email-masked]] On
> |> |>Behalf Of Peter Lovell
> |> |>Sent: Tuesday, March 10, 2009 3:44 PM
> |> |>
> |> |>>10)   Section 4. Mandatory Ciphersuites: Do we really want
> |> |>>implementation of the ESB ciphersuite to be optional?  Don't
> |> |>we need at
> |> |>>least one mandatory ciphersuite for use with the ESB? Shouldn't
> |> |>>implementation of the ESB ciphersuite be mandatory?
> |> |>
> |> |>Well, this whole area is ripe for discussion next week.
> |> |>
> |> |>Some have said, and I have some sympathy for the position, that it
> |> |>should be possible to have BSP code and yet not do the mandatory
> |> |>ciphersuites. Since they require RSA support that makes them
> |> |>"heavyweight" for small devices, but you can't be compliant unless
> |you
> |> |>have them.
> |> |>
> |> |>I've been toying with the idea of having two parts to the BSP
> |> |>spec - one
> |> |>for the protocol and rules and a second for the standard
> |ciphersuites.
> |> |>Having just BSP would be "limited compliance" and having the
> |standard
> |> |>suites also would be "full compliance". This will be an important
> |issue
> |> |>when DTN compliance is required for government contracts etc. We
> |don't
> |> |>want to place wasteful burdens on small devices that only
> |> |>hinder adoption.
> |> |>
> |> |>If we do make this change then I'd support adding ESB4 as one of the
> |> |>standard set.
> |> |
> |> |
> |> |I would support splitting the protocol rules from the ciphersuite
> |> |definitions.  By the time bundle protocol and BSP are in wider
> |> |deployment (or support / compliance required for contracts), the
> |> |algorithms du jour may have changed enough that supporting the
> |> |protocol with other ciphersuites would be desirable.
> |> |
> |> |"Late binding" of the specific algorithms is worth a lot if there's
> |> |ever an attempt to advance up the Standards Track, rather than just
> |> |stay at Experimental.
> |> |
> |> |Plus, I'm one of the pesky ones that doesn't want to have to
> |> |implement / link to RSA, bignum code, and other things that may
> |> |not be needed or desirable in absolutely all cases.  If we're
> |> |going to make certain ciphersuites / algorithms mandatory, then
> |> |we better make sure with the DTN delployers that those algorithms
> |> |make sense and are feasible in ALL deployment scenarios, otherwise
> |> |we'll wind up with lots of "non-compliant" deployments based.  So
> |> |far, I don't think that poll has been issued ... I would encourage
> |> |people to look at the constraints that 6LOWPAN and ROLL have to
> |> |work within.  For instance, in draft-ietf-roll-protocols-survey-06 :
> |> |
> |> |   LLNs have security considerations.  These considerations vary
> |greatly
> |> |   depending on application domain.  For example, deployers
> |industrial
> |> |   monitoring networks may impose more stringent confidentiality
> |> |   requirements than home automation networks do.  Such requirements
> |are
> |> |   an important consideration in protocol design, but their variety
> |> |   makes distilling them to a minimalist set of "necessary but not
> |> |   sufficient" criteria is of limited use.  The criteria in this
> |> |   document are not the only requirements and considerations in LLN
> |> |   protocols, and as such the omission of a security criterion should
> |> |   not be interpreted as a lack of a need for security in LLNs.
> |> |
> |> |Similarly, the ommission of a particular ciphersuite from the set
> |> |of required BSP facets should not be interpreted as a lack of need
> |> |for the security properties of that ciphersuite in some significant
> |> |classes of DTNs, just as a lack of universal need in all DTNs.
> |> |
> |> |---------------------------
> |> |Wes Eddy
> |> |Network & Systems Architect
> |> |Verizon FNS / NASA GRC
> |> |Office: (216) 433-6682
> |> |---------------------------
> |> |
> |> |_______________________________________________
> |> |dtn-interest mailing list
> |> [email-masked]
> |> |http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> |>
> |> _______________________________________________
> |> dtn-interest mailing list
> |> [email-masked]
> |> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> |>
> 

From: "Durst, Robert C." <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 11:18:21 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn, interest <[email-masked]>, Peter
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

Stephen,

I didn't (or at least didn't intend to) suggest creating new documents.  Peter suggested, and Wes and I supported, the notion of revising the conformance requirements.  When Peter mentioned "splitting" the document, I interpreted it to mean an organizational change within the existing document to coalesce those sections that would constitute protocol conformance and those that would constitute ciphersuite conformance.  So I don't really interpret this as something that requires creating new documents.

I agree with you that I also have not heard anyone say that they'd like to implement the BSP with different ciphersuites.  But I have heard people say that they don't feel like they can implement the BSP with THESE ciphersuites.  I've ported DTN to a gumstix processor, and while it fit, it wasn't very peppy.  I have sympathy for those folks who want to be very selective about the computational complexity of the algorithms that they choose, and yet wish to maintain conformance to the BSP protocol itself. 

I share the concern that if we allow conformance without mandating at least some ciphersuite(s) we run the risk of non-interoperability, and so I think that the protocol operations would be a MUST and the ciphersuites could be a SHOULD, with the burden placed on the implementer to document why the ciphersuites in the (single) spec aren't implemented.

So if this were simply a conformance statement change to the current draft could you support it?

Bob

|-----Original Message-----
|From: Stephen Farrell [mailto:[email-masked]]
|Sent: Wednesday, March 11, 2009 10:59 AM
|To: Durst, Robert C.
|Cc: Eddy, Wesley M. (GRC-RCN0)[Verizon]; Peter Lovell; Symington, Susan
|F.; dtn interest
|Subject: Re: [dtn-interest] "last call" comments on the latest BSP
|
|
|Well I don't really get this. Right now BSP specifies some mandatory
|to implement ciphersuites. I've not heard anyone say they'd like to
|implement BSP with a different set of ciphersuites, without there
|being a separate draft describing that case, e.g. the checksum draft
|is a case in point.
|
|And I don't think creating new documents is very efficient either
|so I'd argue against this change I think.
|
|S.
|
|Durst, Robert C. wrote:
|> I concur with the notion of having separate conformance statements for
|the protocol functions and the ciphersuites.  I wonder if, rather than
|the designations of "limited" and "full" compliance, we might be a bit
|more specific/transparent/whatever and specify "protocol" or
|"protocol+ciphersuite" conformance classes.  (That said, I think that we
|should still strive to keep our "ciphersuite" conformance class to the
|minimum needed for interoperability with a "reasonable" balance between
|computational complexity and actual protection.  Everyone's mileage WILL
|vary on the definition of reasonable.)
|>
|> Bob
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:dtn-
|> [email-masked]] On Behalf Of Eddy,
|Wesley
|> |M. (GRC-RCN0)[Verizon]
|> |Sent: Tuesday, March 10, 2009 4:34 PM
|> |To: Peter Lovell; Symington, Susan F.
|> |Cc: dtn interest
|> |Subject: Re: [dtn-interest] "last call" comments on the latest BSP
|> |
|> |>-----Original Message-----
|> |>From: [email-masked]
|> |>[mailto:[email-masked]] On
|> |>Behalf Of Peter Lovell
|> |>Sent: Tuesday, March 10, 2009 3:44 PM
|> |>
|> |>>10)   Section 4. Mandatory Ciphersuites: Do we really want
|> |>>implementation of the ESB ciphersuite to be optional?  Don't
|> |>we need at
|> |>>least one mandatory ciphersuite for use with the ESB? Shouldn't
|> |>>implementation of the ESB ciphersuite be mandatory?
|> |>
|> |>Well, this whole area is ripe for discussion next week.
|> |>
|> |>Some have said, and I have some sympathy for the position, that it
|> |>should be possible to have BSP code and yet not do the mandatory
|> |>ciphersuites. Since they require RSA support that makes them
|> |>"heavyweight" for small devices, but you can't be compliant unless
|you
|> |>have them.
|> |>
|> |>I've been toying with the idea of having two parts to the BSP
|> |>spec - one
|> |>for the protocol and rules and a second for the standard
|ciphersuites.
|> |>Having just BSP would be "limited compliance" and having the
|standard
|> |>suites also would be "full compliance". This will be an important
|issue
|> |>when DTN compliance is required for government contracts etc. We
|don't
|> |>want to place wasteful burdens on small devices that only
|> |>hinder adoption.
|> |>
|> |>If we do make this change then I'd support adding ESB4 as one of the
|> |>standard set.
|> |
|> |
|> |I would support splitting the protocol rules from the ciphersuite
|> |definitions.  By the time bundle protocol and BSP are in wider
|> |deployment (or support / compliance required for contracts), the
|> |algorithms du jour may have changed enough that supporting the
|> |protocol with other ciphersuites would be desirable.
|> |
|> |"Late binding" of the specific algorithms is worth a lot if there's
|> |ever an attempt to advance up the Standards Track, rather than just
|> |stay at Experimental.
|> |
|> |Plus, I'm one of the pesky ones that doesn't want to have to
|> |implement / link to RSA, bignum code, and other things that may
|> |not be needed or desirable in absolutely all cases.  If we're
|> |going to make certain ciphersuites / algorithms mandatory, then
|> |we better make sure with the DTN delployers that those algorithms
|> |make sense and are feasible in ALL deployment scenarios, otherwise
|> |we'll wind up with lots of "non-compliant" deployments based.  So
|> |far, I don't think that poll has been issued ... I would encourage
|> |people to look at the constraints that 6LOWPAN and ROLL have to
|> |work within.  For instance, in draft-ietf-roll-protocols-survey-06 :
|> |
|> |   LLNs have security considerations.  These considerations vary
|greatly
|> |   depending on application domain.  For example, deployers
|industrial
|> |   monitoring networks may impose more stringent confidentiality
|> |   requirements than home automation networks do.  Such requirements
|are
|> |   an important consideration in protocol design, but their variety
|> |   makes distilling them to a minimalist set of "necessary but not
|> |   sufficient" criteria is of limited use.  The criteria in this
|> |   document are not the only requirements and considerations in LLN
|> |   protocols, and as such the omission of a security criterion should
|> |   not be interpreted as a lack of a need for security in LLNs.
|> |
|> |Similarly, the ommission of a particular ciphersuite from the set
|> |of required BSP facets should not be interpreted as a lack of need
|> |for the security properties of that ciphersuite in some significant
|> |classes of DTNs, just as a lack of universal need in all DTNs.
|> |
|> |---------------------------
|> |Wes Eddy
|> |Network & Systems Architect
|> |Verizon FNS / NASA GRC
|> |Office: (216) 433-6682
|> |---------------------------
|> |
|> |_______________________________________________
|> |dtn-interest mailing list
|> [email-masked]
|> |http://maillists.intel-research.net/mailman/listinfo/dtn-interest
|>
|> _______________________________________________
|> dtn-interest mailing list
|> [email-masked]
|> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
|>

Date: Wed, 11 Mar 2009 15:15:57 +0000
From: Stephen Farrell <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
> 
> I'm not going to win any popularity contest today ...

Correct! I'm sorry to say that all I see in your mail is
essentially FUD.

> I think this draft should be HELD by the RG for now, and publication
> postponed until some other pieces and reviews come along.  I believe
> it's mostly an okay document, but that it's very premature within the
> rest of the DTN security architecture development for us to be putting
> it out.

What "rest of the DTN security architecture development" do you mean?
Who's doing that? When will they be finished? Are you volunteering
for something?

> The context for the BSP strongly depends on another document
> (draft-irtf-dtnrg-sec-overview), which has plenty of open issues that
> haven't been approached yet by the RG.  Without that context, it's
> not possible to understand what the requirements or needed ops and
> management features of the BSP are.

Disagree. I specifically believe that BSP is fine to proceed without
the sec-overview. And there's lots of precedent for that elsewhere,
e.g. in DKIM, rfc4871 is published and in use and the overview doc
is still in last call more than a year later. That's actually been
useful as it allowed some experience to be fed back into the overview
(which is I agree a good bit away from being ready). I think you've
got that relationship backwards.

> When the sec-overview is ready, THEN the BSP can be reviewed for its
> adequacy to meet some portion of the security concerns, and the realm
> of its applicability towards those concerns can be understood and
> evaluated.  

See above.

> Until then, we have no idea if BSP is either necessary or

Its not necessary. Its optional.

> sufficient; 

For what? If you have some use-cases that'd be interesting,
and content-ful.

> it's just bolt-on crypto, 

TBBA is not a good criticism.

> and there's not yet a "total
> package" security solution that we can see how it fits within or
> relates to (e.g. no KMP).

Disagree. DTN key management is not going to be done for quite
a while IMO. (I see no reason to hold up our ESP equivalent while
we await an ISAKMP/IKE/... bun fight to complete;-)

Seriously, if we want there to be a DTN key management solution
then I think we need to do experiments with BSP to see how
different proposals work. That is much easier if BSP is stable
and implemented and an *experimental* RFC.

> Furthermore, I think it's very dangerous for us to publish a security
> spec as an RFC without having a few eyes from the SECDIR actually
> verify that we've done something reasonable and confirm that we've
> understood our own problem space.  The fact that it's an RFC (without
> regard to it being Experimental or IRTF-stream rather than IETF)
> means that other people will see it, pick it up, and assume that it's
> okay, and if it's not okay, then we'll be doing a major disservice.

>From the process p-o-v, we absolutely should not get secdir review
involved. It already took ages to get the IRTF stream up and (sort of)
running, and the IETF/IESG/directorates shouldn't be part of that
process other than to prevent end-runs. I've no problem if we get
some more security review, but I don't want that getting embedded
in the process. Feel free to send links to your favorite security
types, but don't ask DTNRG to wait for that for documents that've
been drafts for a number of years already. (And I say all that as
a secdir member.)

Secondly, delaying on the basis of some possible unspecified
"major disservice" seems to me plain silly. If you've some specifics
then what are they? How could we finish anything on the basis
of such content-free criticism?

Lastly, I'm puzzled by the fact that you asked for last call on
the checksum draft which would therefore be similarly held up.
Did you not really want last call?

Stephen.

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Wed, 11 Mar 2009 08:05:25 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Eddy, Wesley M.
> (GRC-RCN0)[Verizon]
> Sent: Wednesday, March 11, 2009 7:17 AM
> To: Stephen Farrell; DTN
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> 
> I believe this is "ready to publish" aside from one facet
> that's nearly editorial.
> 
> Instead of "dtn://cbhe.ccsds.org/9.37" (as an example),I
> think it would more appropriately be:
> dtn://cbhe.dtnrg/ccsds/9.37
> 
> or more generically:
> dtn://cbhe.dtnrg/<BODY-GOVERNING-NODE-NUMBERS>/<NODE-NUMBER>.<SERVICE-
> NUMBER>
> 
> The reason I suggest replacing the "ccsds.org" string with
> "dtnrg" is that it seems very inappropriate for us to write
> a spec in DTNRG using another body's name without any kind
> of formal liason.  Wouldn't we be torqued if WiMax Forum or
> some other SDO started defining specs with "dtnrg" strings
> embedded in them that we'd never seen or agreed to formally?
> 
> Instead, I suggest adding the BODY-GOVERNING-NODE-NUMBERS
> field to the URI so that we can differentiate between CCSDS
> use of spacecraft IDs, or other numbering authorities that
> may have their own registries used to generate node numbers.

Wes, I think there are two points here.

First, I see what you're saying about defining a DTNRG spec in terms of another organization's name, and I would certainly be fine with changing from "cbhe.ccsds.org" to "cbhe.dtnrg.org".

But the problem with adding the name of the node number assignment organization to the CBHE-style URI is that we have no way of recovering it during decompression.  I wrote about this in an earlier email on this thread, posted yesterday a little after 5 PM my time, responding to a comment from Stephen: as CBHE is currently written, there's no way to carry that name in either compressed or uncompressed form.  

Adding this little bit of hierarchical structure is of course a very reasonable thing to propose -- we do it all the time -- but in this case I think it would weaken the spec.  It would bloat the compressed bundle somewhat, and in the event that we find we need to accommodate multiple node number allocation authorities there are other (admittedly less elegant) ways to do it.  The cost of this change being assured and the benefit being kind of speculative, I think it's not a good bet.

> Other than that ... it looks like a solid draft to me and I
> think it should go forward.

Thanks.

Scott

Date: Wed, 11 Mar 2009 14:58:34 +0000
From: Stephen Farrell <[email-masked]>
To: "Durst, Robert C." <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

Well I don't really get this. Right now BSP specifies some mandatory
to implement ciphersuites. I've not heard anyone say they'd like to
implement BSP with a different set of ciphersuites, without there
being a separate draft describing that case, e.g. the checksum draft
is a case in point.

And I don't think creating new documents is very efficient either
so I'd argue against this change I think.

S.

Durst, Robert C. wrote:
> I concur with the notion of having separate conformance statements for the protocol functions and the ciphersuites.  I wonder if, rather than the designations of "limited" and "full" compliance, we might be a bit more specific/transparent/whatever and specify "protocol" or "protocol+ciphersuite" conformance classes.  (That said, I think that we should still strive to keep our "ciphersuite" conformance class to the minimum needed for interoperability with a "reasonable" balance between computational complexity and actual protection.  Everyone's mileage WILL vary on the definition of reasonable.)
> 
> Bob
> 
> |-----Original Message-----
> |From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Eddy, Wesley
> |M. (GRC-RCN0)[Verizon]
> |Sent: Tuesday, March 10, 2009 4:34 PM
> |To: Peter Lovell; Symington, Susan F.
> |Cc: dtn interest
> |Subject: Re: [dtn-interest] "last call" comments on the latest BSP
> |
> |>-----Original Message-----
> |>From: [email-masked]
> |>[mailto:[email-masked]] On
> |>Behalf Of Peter Lovell
> |>Sent: Tuesday, March 10, 2009 3:44 PM
> |>
> |>>10)   Section 4. Mandatory Ciphersuites: Do we really want
> |>>implementation of the ESB ciphersuite to be optional?  Don't
> |>we need at
> |>>least one mandatory ciphersuite for use with the ESB? Shouldn't
> |>>implementation of the ESB ciphersuite be mandatory?
> |>
> |>Well, this whole area is ripe for discussion next week.
> |>
> |>Some have said, and I have some sympathy for the position, that it
> |>should be possible to have BSP code and yet not do the mandatory
> |>ciphersuites. Since they require RSA support that makes them
> |>"heavyweight" for small devices, but you can't be compliant unless you
> |>have them.
> |>
> |>I've been toying with the idea of having two parts to the BSP
> |>spec - one
> |>for the protocol and rules and a second for the standard ciphersuites.
> |>Having just BSP would be "limited compliance" and having the standard
> |>suites also would be "full compliance". This will be an important issue
> |>when DTN compliance is required for government contracts etc. We don't
> |>want to place wasteful burdens on small devices that only
> |>hinder adoption.
> |>
> |>If we do make this change then I'd support adding ESB4 as one of the
> |>standard set.
> |
> |
> |I would support splitting the protocol rules from the ciphersuite
> |definitions.  By the time bundle protocol and BSP are in wider
> |deployment (or support / compliance required for contracts), the
> |algorithms du jour may have changed enough that supporting the
> |protocol with other ciphersuites would be desirable.
> |
> |"Late binding" of the specific algorithms is worth a lot if there's
> |ever an attempt to advance up the Standards Track, rather than just
> |stay at Experimental.
> |
> |Plus, I'm one of the pesky ones that doesn't want to have to
> |implement / link to RSA, bignum code, and other things that may
> |not be needed or desirable in absolutely all cases.  If we're
> |going to make certain ciphersuites / algorithms mandatory, then
> |we better make sure with the DTN delployers that those algorithms
> |make sense and are feasible in ALL deployment scenarios, otherwise
> |we'll wind up with lots of "non-compliant" deployments based.  So
> |far, I don't think that poll has been issued ... I would encourage
> |people to look at the constraints that 6LOWPAN and ROLL have to
> |work within.  For instance, in draft-ietf-roll-protocols-survey-06 :
> |
> |   LLNs have security considerations.  These considerations vary greatly
> |   depending on application domain.  For example, deployers industrial
> |   monitoring networks may impose more stringent confidentiality
> |   requirements than home automation networks do.  Such requirements are
> |   an important consideration in protocol design, but their variety
> |   makes distilling them to a minimalist set of "necessary but not
> |   sufficient" criteria is of limited use.  The criteria in this
> |   document are not the only requirements and considerations in LLN
> |   protocols, and as such the omission of a security criterion should
> |   not be interpreted as a lack of a need for security in LLNs.
> |
> |Similarly, the ommission of a particular ciphersuite from the set
> |of required BSP facets should not be interpreted as a lack of need
> |for the security properties of that ciphersuite in some significant
> |classes of DTNs, just as a lack of universal need in all DTNs.
> |
> |---------------------------
> |Wes Eddy
> |Network & Systems Architect
> |Verizon FNS / NASA GRC
> |Office: (216) 433-6682
> |---------------------------
> |
> |_______________________________________________
> |dtn-interest mailing list
> [email-masked]
> |http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Wed, 11 Mar 2009 09:47:48 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Stephen Farrell
>Sent: Tuesday, March 10, 2009 12:35 PM
>
>This message starts the "last call" on the Bundle Security
>Protocol draft. [1]
>

I'm not going to win any popularity contest today ...

I think this draft should be HELD by the RG for now, and publication
postponed until some other pieces and reviews come along.  I believe
it's mostly an okay document, but that it's very premature within the
rest of the DTN security architecture development for us to be putting
it out.

The context for the BSP strongly depends on another document
(draft-irtf-dtnrg-sec-overview), which has plenty of open issues that
haven't been approached yet by the RG.  Without that context, it's
not possible to understand what the requirements or needed ops and
management features of the BSP are.

When the sec-overview is ready, THEN the BSP can be reviewed for its
adequacy to meet some portion of the security concerns, and the realm
of its applicability towards those concerns can be understood and
evaluated.  Until then, we have no idea if BSP is either necessary or
sufficient; it's just bolt-on crypto, and there's not yet a "total
package" security solution that we can see how it fits within or
relates to (e.g. no KMP).

Furthermore, I think it's very dangerous for us to publish a security
spec as an RFC without having a few eyes from the SECDIR actually
verify that we've done something reasonable and confirm that we've
understood our own problem space.  The fact that it's an RFC (without
regard to it being Experimental or IRTF-stream rather than IETF)
means that other people will see it, pick it up, and assume that it's
okay, and if it's not okay, then we'll be doing a major disservice.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Wed, 11 Mar 2009 09:17:26 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Stephen Farrell
>Sent: Thursday, March 05, 2009 1:54 PM
>To: DTN
>Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>
>
>This message starts the "last call" on the Compressed
>Bundle Header Encoding draft. [1]
>
>Can you read and comment on this in the next month, i.e.
>before the end of April 5th, but ideally before March
>19th so we can discuss any issues when we meet.
>
>Please bear in mind that as an IRTF RG, and not an
>IETF WG, we do not need to establish rough consensus
>for documents, but if we do have that its a good thing.
>For the later stages of review, it's useful if folks have
>said "I agree, its ok and its ready" or equivalent so
>please do send a mail to the list saying that if it
>applies. (Preserving the subject line so we can just
>add a link in the tracker later.)

I believe this is "ready to publish" aside from one facet
that's nearly editorial.

Instead of "dtn://cbhe.ccsds.org/9.37" (as an example),I
think it would more appropriately be:
dtn://cbhe.dtnrg/ccsds/9.37

or more generically:
dtn://cbhe.dtnrg/<BODY-GOVERNING-NODE-NUMBERS>/<NODE-NUMBER>.<SERVICE-NUMBER>

The reason I suggest replacing the "ccsds.org" string with
"dtnrg" is that it seems very inappropriate for us to write
a spec in DTNRG using another body's name without any kind
of formal liason.  Wouldn't we be torqued if WiMax Forum or
some other SDO started defining specs with "dtnrg" strings
embedded in them that we'd never seen or agreed to formally?

Instead, I suggest adding the BODY-GOVERNING-NODE-NUMBERS
field to the URI so that we can differentiate between CCSDS
use of spacecraft IDs, or other numbering authorities that
may have their own registries used to generate node numbers.

Other than that ... it looks like a solid draft to me and I
think it should go forward.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 11 Mar 2009 08:38:17 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of [email-masked]
>Sent: Tuesday, March 10, 2009 11:48 PM
>
>> #0, I guess I'm left wondering if this is the only spec 
>needed to implement a
>> CL for space DTNs? If so, cool. If not, would it be better 
>if it were?
>
>Stephen,
>
>weren't you in Minneapolis, where two very different 
>approaches to space DTNs
>and implementations, using two different convergence layers - 
>based on LTP
>(over CFDP over CCSDS) and based on Saratoga (over UDP/IP over HDLC) -
>were presented, based on actual in-space testing results?
>
>http://tools.ietf.org/html/draft-wood-dtnrg-saratoga
>
>The presentations there are a clear indication that more than 
>the cbhe spec
>is needed to implement a convergence layer for space.
>
>Perhaps you could look at finalising the meeting minutes 
>(draft not archived) or
>finalising the proceedings of the Minneapolis meeting (draft very hard
>to find) to refresh your memory.
>

I don't think this RG should be worrying about "space DTNs" and
trying to tailor for them ... there are other groups actively
doing that, and the discussion should be taken to them, in my
opinion.

I think the root problem here is just that "space DTNs" aren't
some homogenous class of DTNs.  The requirements for unmanned
near-Earth versus deep space are different, and when you factor
in the envisioned lunar scenarios with more ad-hoc connectivity
and richer options for infrastructure, the requirements and
assumptions are MUCH different.  It's like saying you're doing
something for "wireless links" without specifying if you mean
low-rate/low-power PAN, free-space optical, cellular, etc;
unproductively unspecific.

CBHE may be useful in the broader set of DTNs that contain links
with either constrained bandwidth or very short contact times,
which includes underwater/submarine (at least) in addition to
deep space.  Since it may be applicable in multiple domains, it
makes sense to me to publish it from DTNRG, but it will only
greatly confuse matters if we say we're doing it for "space DTNs";
instead focus on the properties of links/networks that it's an
optimization for.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: "Durst, Robert C." <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>, Peter Lovell <[email-masked]>, "Symington, Susan F." <[email-masked]>
Date: Wed, 11 Mar 2009 09:20:57 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

I concur with the notion of having separate conformance statements for the protocol functions and the ciphersuites.  I wonder if, rather than the designations of "limited" and "full" compliance, we might be a bit more specific/transparent/whatever and specify "protocol" or "protocol+ciphersuite" conformance classes.  (That said, I think that we should still strive to keep our "ciphersuite" conformance class to the minimum needed for interoperability with a "reasonable" balance between computational complexity and actual protection.  Everyone's mileage WILL vary on the definition of reasonable.)

Bob

|-----Original Message-----
|From: [email-masked] [mailto:dtn-
[email-masked]] On Behalf Of Eddy, Wesley
|M. (GRC-RCN0)[Verizon]
|Sent: Tuesday, March 10, 2009 4:34 PM
|To: Peter Lovell; Symington, Susan F.
|Cc: dtn interest
|Subject: Re: [dtn-interest] "last call" comments on the latest BSP
|
|>-----Original Message-----
|>From: [email-masked]
|>[mailto:[email-masked]] On
|>Behalf Of Peter Lovell
|>Sent: Tuesday, March 10, 2009 3:44 PM
|>
|>>10)   Section 4. Mandatory Ciphersuites: Do we really want
|>>implementation of the ESB ciphersuite to be optional?  Don't
|>we need at
|>>least one mandatory ciphersuite for use with the ESB? Shouldn't
|>>implementation of the ESB ciphersuite be mandatory?
|>
|>Well, this whole area is ripe for discussion next week.
|>
|>Some have said, and I have some sympathy for the position, that it
|>should be possible to have BSP code and yet not do the mandatory
|>ciphersuites. Since they require RSA support that makes them
|>"heavyweight" for small devices, but you can't be compliant unless you
|>have them.
|>
|>I've been toying with the idea of having two parts to the BSP
|>spec - one
|>for the protocol and rules and a second for the standard ciphersuites.
|>Having just BSP would be "limited compliance" and having the standard
|>suites also would be "full compliance". This will be an important issue
|>when DTN compliance is required for government contracts etc. We don't
|>want to place wasteful burdens on small devices that only
|>hinder adoption.
|>
|>If we do make this change then I'd support adding ESB4 as one of the
|>standard set.
|
|
|I would support splitting the protocol rules from the ciphersuite
|definitions.  By the time bundle protocol and BSP are in wider
|deployment (or support / compliance required for contracts), the
|algorithms du jour may have changed enough that supporting the
|protocol with other ciphersuites would be desirable.
|
|"Late binding" of the specific algorithms is worth a lot if there's
|ever an attempt to advance up the Standards Track, rather than just
|stay at Experimental.
|
|Plus, I'm one of the pesky ones that doesn't want to have to
|implement / link to RSA, bignum code, and other things that may
|not be needed or desirable in absolutely all cases.  If we're
|going to make certain ciphersuites / algorithms mandatory, then
|we better make sure with the DTN delployers that those algorithms
|make sense and are feasible in ALL deployment scenarios, otherwise
|we'll wind up with lots of "non-compliant" deployments based.  So
|far, I don't think that poll has been issued ... I would encourage
|people to look at the constraints that 6LOWPAN and ROLL have to
|work within.  For instance, in draft-ietf-roll-protocols-survey-06 :
|
|   LLNs have security considerations.  These considerations vary greatly
|   depending on application domain.  For example, deployers industrial
|   monitoring networks may impose more stringent confidentiality
|   requirements than home automation networks do.  Such requirements are
|   an important consideration in protocol design, but their variety
|   makes distilling them to a minimalist set of "necessary but not
|   sufficient" criteria is of limited use.  The criteria in this
|   document are not the only requirements and considerations in LLN
|   protocols, and as such the omission of a security criterion should
|   not be interpreted as a lack of a need for security in LLNs.
|
|Similarly, the ommission of a particular ciphersuite from the set
|of required BSP facets should not be interpreted as a lack of need
|for the security properties of that ciphersuite in some significant
|classes of DTNs, just as a lack of universal need in all DTNs.
|
|---------------------------
|Wes Eddy
|Network & Systems Architect
|Verizon FNS / NASA GRC
|Office: (216) 433-6682
|---------------------------
|
|_______________________________________________
|dtn-interest mailing list
[email-masked]
|http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Date: Wed, 11 Mar 2009 03:48:05 -0000
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A1FC.2F4FBF84
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> #0, I guess I'm left wondering if this is the only spec needed to =
implement a
> CL for space DTNs? If so, cool. If not, would it be better if it were?

Stephen,

weren't you in Minneapolis, where two very different approaches to space =
DTNs
and implementations, using two different convergence layers - based on =
LTP
(over CFDP over CCSDS) and based on Saratoga (over UDP/IP over HDLC) -=20
were presented, based on actual in-space testing results?

http://tools.ietf.org/html/draft-wood-dtnrg-saratoga

The presentations there are a clear indication that more than the cbhe =
spec
is needed to implement a convergence layer for space.

Perhaps you could look at finalising the meeting minutes (draft not =
archived) or
finalising the proceedings of the Minneapolis meeting (draft very hard
to find) to refresh your memory.

hope this helps,

L.

DTN work: http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

-----Original Message-----
From: [email-masked] on behalf of =
Stephen Farrell
Sent: Tue 2009-03-10 23:25
To: Stephen Farrell
Cc: DTN
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
=20

My comments on this one. Sorry if they overlap with earlier
ones,
S.

------_=_NextPart_001_01C9A1FC.2F4FBF84
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-cbhe</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>&gt; #0, I guess I'm left wondering if this is the =
only spec needed to implement a<BR>
&gt; CL for space DTNs? If so, cool. If not, would it be better if it =
were?<BR>
<BR>
Stephen,<BR>
<BR>
weren't you in Minneapolis, where two very different approaches to space =
DTNs<BR>
and implementations, using two different convergence layers - based on =
LTP<BR>
(over CFDP over CCSDS) and based on Saratoga (over UDP/IP over HDLC) =
-<BR>
were presented, based on actual in-space testing results?<BR>
<BR>
<A =
HREF=3D"http://tools.ietf.org/html/draft-wood-dtnrg-saratoga">http://tool=
s.ietf.org/html/draft-wood-dtnrg-saratoga</A><BR>
<BR>
The presentations there are a clear indication that more than the cbhe =
spec<BR>
is needed to implement a convergence layer for space.<BR>
<BR>
Perhaps you could look at finalising the meeting minutes (draft not =
archived) or<BR>
finalising the proceedings of the Minneapolis meeting (draft very =
hard<BR>
to find) to refresh your memory.<BR>
<BR>
hope this helps,<BR>
<BR>
L.<BR>
<BR>
DTN work: <A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://www.=
ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A><BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Stephen Farrell<BR>
Sent: Tue 2009-03-10 23:25<BR>
To: Stephen Farrell<BR>
Cc: DTN<BR>
Subject: Re: [dtn-interest] RG &quot;last call&quot; on =
draft-irtf-dtnrg-cbhe<BR>
<BR>
<BR>
My comments on this one. Sorry if they overlap with earlier<BR>
ones,<BR>
S.<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9A1FC.2F4FBF84--

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Tue, 10 Mar 2009 17:03:51 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 4:25 PM
> To: Burleigh, Scott C
> Cc: DTN
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> 
> 
> Burleigh, Scott C wrote:
> >> -----Original Message-----
> >> From: [email-masked] [mailto:dtn-
> >> [email-masked]] On Behalf Of Teemu
> >> Sent: Tuesday, March 10, 2009 6:57 AM
> >> To: Stephen Farrell; DTN
> >> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> >>
> >> Hi,
> >>
> >> How would I make sure NODE_NUMBERs of my nodes do not collide with those of
> >> other networks? It seems like either there should be a way to register my
> >> node numbers, perhaps be allocated a range, or use my own authority instead
> >> of "cbhe.ccsds.org".
> >
> > I'd vote for approach (a).  The near-term application of CBHE is in space
> flight operations, a community that is so small that node number
> registration is a non-problem.  If CBHE were used more broadly, clearly
> some sort of node number assignment bureaucracy would grow up.  That sort
> of thing doesn't seem to have crippled the adoption of Ethernet, though,
> for example.  If it's cost-effective, it will happen; if not, it won't.
> 
> That confuses me. I read the spec as saying that someone in CCSDS would
> be making sure there're no collisions, which, to me, implies that any
> such registry is within CCSDS and not visible here, so if you do want
> to make use of this spec but cannot get entries into that registry
> (a bit of an unlikely case, except maybe for N.Korea) and you also
> want to transmit bundles via someone else that does CBHE then you'd
> write up a spec that this one with s/cbhe.ccsds.org/your-own-domain/
> and then off you go. But maybe we're all just agreeing but saying
> it differently.

Maybe, but maybe not.

I look at "cbhe.ccsds.org" as merely a string that indicates the structure of a given URI, not necessarily as the name of the organization that assigned the node number embedded in that URI.

I can easily imagine CBHE being adopted only by the space flight community, for a community-wide interplanetary internet.  In that case I would expect some CCSDS Control Authority to be responsible for all node number allocations.

If some other DTN user community wanted to adopt CBHE for its private purposes, cool, it could certainly be its own node number allocation authority even without registering a CBHE-like spec based on a different authority ID. 

If we wanted those two user communities to interoperate, though, they would have to agree on a common node number allocation authority structure, maybe one that's federated in some way.  In order to have the two communities interoperate using CBHE when one of them uses "cbhe.ccsds.org" as authority ID and the other uses "your.domain.net" as authority ID, we would have to change the definition of CBHE.  As the I-D is written, if your authority ID isn't "cbhe.ccsds.org" you're not CBHE conformant -- there isn't any way to decompress back to the correct authority ID string, because neither that string nor any compressed representation of it is carried anywhere in the compressed bundle.

This is by design.  CBHE is designed to address a narrow problem in the simplest way possible, with zero impact on the Bundle Protocol spec.  We can talk about applying it more broadly, but there is a can of worms waiting to be opened up if we start on that.

Scott

Date: Tue, 10 Mar 2009 23:25:42 +0000
From: Stephen Farrell <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

This is a multi-part message in MIME format.
--------------050202000901010203080509
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

My comments on this one. Sorry if they overlap with earlier
ones,
S.

--------------050202000901010203080509
Content-Type: text/plain;
 name="cbhe-comments.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="cbhe-comments.txt"

SF Comments on draft-irtf-dtnrg-cbhe-01
20090310

General:

#0, I guess I'm left wondering if this is the only spec needed to implement a
CL for space DTNs? If so, cool. If not, would it be better if it were?

#1, The spec as-is only compresses certain EIDs and not general headers so the
title is, for me, misleading. The actual compression is also space-specifc (via
ccsds.org) so I think a better name might be "Space DTN EID Compression" or
something like that.

#2, Just wondering...Have CCSDS agreed to sort-of delegate the cbhe.ccsds.org
DNS sub-domain for this purpose? If so, a reference would be great. (Even if to
a mail or web page.) If that's a prooblem, maybe replacing that with a nasa.gov
sub-domain might do? If neither, we can probably get some domain dedicated to
this that'd not be likely to disappear anytime soon. I'd not be surprised if we
get asked by the IRSG, IESG or IANA about this so having the answer up front
would be good. 

#3, section 2.1, 2nd para and after: I think *this* is the specification for
dtn://cbhe.ccsds.org/* EIDs since its nowehere else.

#4, I don't understand why service number zero is needed for admin stuff when
there're flags for that in the header?

#5, the list at the end of 2.1 seems to require exactly 4 EIDs to be present in
a certain order. I'm not sure that's right.

#6, 3.1, what should a compliant CL do when presented with a bundle that
doesn't match this spec? send it or /dev/null or what? Similarly, for 3.2 is a
decoder get a non compressed (but otherwise correct) bundle encoding then what?

#7 sec. cons. (there's always one:-) If ccsds.org changes ownership this spec
might be in trouble:-) And the BSP needs a reference.

#8, some examples would make a nice appendix if they could be easily done

Nits:

#1, section 1, 2nd para: s/contains four BP endpoint identifiers/contains four
or more BP endpoint identifiers/, although the report-to and custodian EIDs are
also optional so its "2 or more" really?

#2, s/natural number/positive integer/ is better for coders IMO and that
conflicts (ok only slightly) with the next para where its defined as an integer
within a range.

--------------050202000901010203080509--

Date: Tue, 10 Mar 2009 23:24:36 +0000
From: Stephen Farrell <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

Burleigh, Scott C wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Teemu
>> Sent: Tuesday, March 10, 2009 6:57 AM
>> To: Stephen Farrell; DTN
>> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>>
>> Hi,
>>
>> How would I make sure NODE_NUMBERs of my nodes do not collide with those of
>> other networks? It seems like either there should be a way to register my
>> node numbers, perhaps be allocated a range, or use my own authority instead
>> of "cbhe.ccsds.org".
> 
> I'd vote for approach (a).  The near-term application of CBHE is in space flight operations, a community that is so small that node number registration is a non-problem.  If CBHE were used more broadly, clearly some sort of node number assignment bureaucracy would grow up.  That sort of thing doesn't seem to have crippled the adoption of Ethernet, though, for example.  If it's cost-effective, it will happen; if not, it won't.

That confuses me. I read the spec as saying that someone in CCSDS would
be making sure there're no collisions, which, to me, implies that any
such registry is within CCSDS and not visible here, so if you do want
to make use of this spec but cannot get entries into that registry
(a bit of an unlikely case, except maybe for N.Korea) and you also
want to transmit bundles via someone else that does CBHE then you'd
write up a spec that this one with s/cbhe.ccsds.org/your-own-domain/
and then off you go. But maybe we're all just agreeing but saying
it differently.

S.

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Tue, 10 Mar 2009 15:52:43 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: Eddy, Wesley M. (GRC-RCN0)[Verizon] [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 12:38 PM
> To: Burleigh, Scott C; DTN
> Subject: RE: [dtn-interest] Re(2): RG "last call" on draft-irtf-dtnrg-cbhe
> 
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]] On
> >Behalf Of Burleigh, Scott C
> >Sent: Tuesday, March 10, 2009 3:04 PM
>
> ...
> 
> >I'm thinking this is a precipice we can step back from if we
> >want to: the fact that RFC5050 accommodates the insertion of
> >additional EIDs in the dictionary doesn't mean we have to use
> >that feature.  Maybe we just shouldn't.
> 
> I can fully sympathize with that.  Even though RG "last call"
> is probaby a bit late to suggest such changes, and the folks
> maintaining implementations won't be too happy, it seems
> valuable in the long run.

I do realize that this would screw up implementations and I am not altogether happy about that, having been similarly hammered myself once or twice in the past.  (Well, maybe twenty or thirty times.)  But if this really has the potential to cause large downstream problems, which I suggest it has, it could save a lot of people a lot of work to catch it now rather than after it's an RFC.

Scott

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: Peter Lovell <[email-masked]>, Susan <[email-masked]>
Date: Tue, 10 Mar 2009 15:33:49 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Peter Lovell
>Sent: Tuesday, March 10, 2009 3:44 PM
>
>>10)   Section 4. Mandatory Ciphersuites: Do we really want
>>implementation of the ESB ciphersuite to be optional?  Don't 
>we need at
>>least one mandatory ciphersuite for use with the ESB? Shouldn't
>>implementation of the ESB ciphersuite be mandatory?
>
>Well, this whole area is ripe for discussion next week.
>
>Some have said, and I have some sympathy for the position, that it
>should be possible to have BSP code and yet not do the mandatory
>ciphersuites. Since they require RSA support that makes them
>"heavyweight" for small devices, but you can't be compliant unless you
>have them.
>
>I've been toying with the idea of having two parts to the BSP 
>spec - one
>for the protocol and rules and a second for the standard ciphersuites.
>Having just BSP would be "limited compliance" and having the standard
>suites also would be "full compliance". This will be an important issue
>when DTN compliance is required for government contracts etc. We don't
>want to place wasteful burdens on small devices that only 
>hinder adoption.
>
>If we do make this change then I'd support adding ESB4 as one of the
>standard set.

I would support splitting the protocol rules from the ciphersuite
definitions.  By the time bundle protocol and BSP are in wider
deployment (or support / compliance required for contracts), the
algorithms du jour may have changed enough that supporting the
protocol with other ciphersuites would be desirable.

"Late binding" of the specific algorithms is worth a lot if there's
ever an attempt to advance up the Standards Track, rather than just
stay at Experimental.

Plus, I'm one of the pesky ones that doesn't want to have to
implement / link to RSA, bignum code, and other things that may
not be needed or desirable in absolutely all cases.  If we're
going to make certain ciphersuites / algorithms mandatory, then
we better make sure with the DTN delployers that those algorithms
make sense and are feasible in ALL deployment scenarios, otherwise
we'll wind up with lots of "non-compliant" deployments based.  So
far, I don't think that poll has been issued ... I would encourage
people to look at the constraints that 6LOWPAN and ROLL have to
work within.  For instance, in draft-ietf-roll-protocols-survey-06 :

   LLNs have security considerations.  These considerations vary greatly
   depending on application domain.  For example, deployers industrial
   monitoring networks may impose more stringent confidentiality
   requirements than home automation networks do.  Such requirements are
   an important consideration in protocol design, but their variety
   makes distilling them to a minimalist set of "necessary but not
   sufficient" criteria is of limited use.  The criteria in this
   document are not the only requirements and considerations in LLN
   protocols, and as such the omission of a security criterion should
   not be interpreted as a lack of a need for security in LLNs.

Similarly, the ommission of a particular ciphersuite from the set
of required BSP facets should not be interpreted as a lack of need
for the security properties of that ciphersuite in some significant
classes of DTNs, just as a lack of universal need in all DTNs.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

Content-class: urn:content-classes:message
Date: Tue, 10 Mar 2009 19:49:55 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" ondraft-irtf-dtnrg-bundle-checksum

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A1B9.6A862833
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks, included as a fix for the next version.

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

-----Original Message-----
From: [email-masked] on behalf of =
Peter TB Brett
Sent: Tue 2009-03-10 17:35
To: [email-masked]
Subject: Re: [dtn-interest] RG "last call" =
ondraft-irtf-dtnrg-bundle-checksum
=20
On Tuesday 10 March 2009 16:34:22 Stephen Farrell wrote:
> This message starts the "last call" on the Bundle Checksum
> draft. [1]
>
> Note that this should really be read in conjunction with
> the bundle security protocol draft (see the next in this
> long line of last call messages:-)
>
> Can you read and comment on this in the next month, i.e.
> before the end of April 9th, but ideally before March
> 19th so we can discuss any issues when we meet.
> =20

On p.4, the following sentence is not grammatical.

   However, [RFC4838] discusses 'reliable delivery', this is expected to
   be provided to the bundle layer, and is not a property of the bundle
   layer. =20

I suggest the following:

   Although [RFC4838] discusses 'reliable delivery', this is expected to
   be provided to the bundle layer, rather than being a property of the
   bundle layer itself.

                     Peter

------_=_NextPart_001_01C9A1B9.6A862833
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] RG &quot;last call&quot; =
ondraft-irtf-dtnrg-bundle-checksum</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Thanks, included as a fix for the next version.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Peter TB Brett<BR>
Sent: Tue 2009-03-10 17:35<BR>
To: [email-masked]<BR>
Subject: Re: [dtn-interest] RG &quot;last call&quot; =
ondraft-irtf-dtnrg-bundle-checksum<BR>
<BR>
On Tuesday 10 March 2009 16:34:22 Stephen Farrell wrote:<BR>
&gt; This message starts the &quot;last call&quot; on the Bundle =
Checksum<BR>
&gt; draft. [1]<BR>
&gt;<BR>
&gt; Note that this should really be read in conjunction with<BR>
&gt; the bundle security protocol draft (see the next in this<BR>
&gt; long line of last call messages:-)<BR>
&gt;<BR>
&gt; Can you read and comment on this in the next month, i.e.<BR>
&gt; before the end of April 9th, but ideally before March<BR>
&gt; 19th so we can discuss any issues when we meet.<BR>
&gt;&nbsp;<BR>
<BR>
On p.4, the following sentence is not grammatical.<BR>
<BR>
&nbsp;&nbsp; However, [RFC4838] discusses 'reliable delivery', this is =
expected to<BR>
&nbsp;&nbsp; be provided to the bundle layer, and is not a property of =
the bundle<BR>
&nbsp;&nbsp; layer.&nbsp;<BR>
<BR>
I suggest the following:<BR>
<BR>
&nbsp;&nbsp; Although [RFC4838] discusses 'reliable delivery', this is =
expected to<BR>
&nbsp;&nbsp; be provided to the bundle layer, rather than being a =
property of the<BR>
&nbsp;&nbsp; bundle layer itself.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Peter<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9A1B9.6A862833--

From: Peter Lovell <[email-masked]>
To: Susan <[email-masked]>
Date: Tue, 10 Mar 2009 15:44:05 -0400
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] "last call" comments on the latest BSP

Hi Susan,

On Tue, Mar 10, 2009, Symington, Susan F. <[email-masked]> wrote:

>Peter,
>
>Thank you for the good job you did incorporating extension block
>security into the BSP. Here are some very minor (mostly editorial)
>comments/questions on the latest draft.

Thanks for the text comments -- I'll make those changes.

>1)      Why did you add in section 2 that the "...PCB indicates that the
>payload has been encrypted in whole or in part"...  When is the payload
>encrypted in part? Isn't it always encrypted in whole?  My inclination
>would be to delete "in whole or in part".

A ciphersuite can encrypt only a portion of the payload, if it wishes.
The block must have a fragment-range item in such a case. PCB3 doesn't
do this but another ciphersuite might do so for some reason. Come to
think of it, I guess there's nothing to prevent several non-overlapping
ranges in a single payload being encrypted by different keys. That would
be a good test to have in a regression test suite!

>5)      Very interesting about the EID-list needing to move from the
>encapsulated bundle to the encapsulating bundle and back again. Glad you
>got that  in there.

So am I. I'm even more glad that *that* code is done -- it really is
rather hairy.

>10)   Section 4. Mandatory Ciphersuites: Do we really want
>implementation of the ESB ciphersuite to be optional?  Don't we need at
>least one mandatory ciphersuite for use with the ESB? Shouldn't
>implementation of the ESB ciphersuite be mandatory?

Well, this whole area is ripe for discussion next week.

Some have said, and I have some sympathy for the position, that it
should be possible to have BSP code and yet not do the mandatory
ciphersuites. Since they require RSA support that makes them
"heavyweight" for small devices, but you can't be compliant unless you
have them.

I've been toying with the idea of having two parts to the BSP spec - one
for the protocol and rules and a second for the standard ciphersuites.
Having just BSP would be "limited compliance" and having the standard
suites also would be "full compliance". This will be an important issue
when DTN compliance is required for government contracts etc. We don't
want to place wasteful burdens on small devices that only hinder adoption.

If we do make this change then I'd support adding ESB4 as one of the
standard set.

>11)   Section 4.4 "...however see the discussion below concerning eid-
>list entries..." I don't believe there is such a discussion below. I
>think it was earlier.

True - that was moved up to the general discussion since it applies to
all rather than just one specific confidentiality suite. There's also
the same comment on section 4.3 from which this was cloned.

Thanks.....Peter

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>, DTN <[email-masked]>
Date: Tue, 10 Mar 2009 14:38:11 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  RG "last call" on draft-irtf-dtnrg-cbhe

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Burleigh, Scott C
>Sent: Tuesday, March 10, 2009 3:04 PM
>
>One other thought on this: have we perhaps reached a point 
>where we've got a tail wagging a dog?  When I read the BSP I-D 
>I see a fair amount of text that deals with managing security 
>source and destination EIDs and the references to them.  It 
>seems to me that the hoops we're finding ourselves having to 
>jump through in order to preserve the dictionary mechanism may 
>be a cost -- in spec complexity, implementation complexity, 
>risk of error, processing overhead -- that exceeds the added value.

I have full agreement on this.

>How much compression does the dictionary mechanism buy us, 
>realistically?  Has anybody done any sort of study yet?  In 
>particular, how often do we think an EID inserted by one BP 
>extension is going to be identical to an EID inserted by 
>another BP extension, when neither of them is identical to the 
>destination, source, report-to, or current custodian?  Might 
>it not be simpler and safer, for example, to say that when 
>extension blocks refer to EIDs that are the 
>destination/source/report-to/custodian they use dictionary 
>offsets but when they refer to other EIDs they contain the EID 
>text locally?  Is the compression we get from EID references 
>into an expanded dictionary really more valuable than that 
>safety and simplicity?

Taking the standpoint of the checksum block's use of the
BSP, I think we typically expect that the "security source"
(chesksumer) and "security destination" (checksum validater)
will be the same as the bundle source and destination.  I
don't expect that it would be inserting or removing any
EIDs from the dictionary in normal use.

>I'm thinking this is a precipice we can step back from if we 
>want to: the fact that RFC5050 accommodates the insertion of 
>additional EIDs in the dictionary doesn't mean we have to use 
>that feature.  Maybe we just shouldn't.

I can fully sympathize with that.  Even though RG "last call"
is probaby a bit late to suggest such changes, and the folks
maintaining implementations won't be too happy, it seems
valuable in the long run.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Tue, 10 Mar 2009 12:04:15 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: Scott, Keith L. [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 7:52 AM
> To: Burleigh, Scott C; DTN; [email-masked]; Symington, Susan F.
> Subject: RE: [dtn-interest] Re(2): RG "last call" on draft-irtf-dtnrg-cbhe
> 
> From the new version (-07) of the security spec, things might not be all
> that complicated:
> 
> It is the job of the security protocol to canonicalize the EIDs referenced
> from the primary bundle header.  Any EIDs that get added to the dictionary
> get ignored by this (I think).  Thus I should be able to add to / reorder
> the dictionary at will (provided I fix all the references into it).
> 
> If somebody adds a NEW EID to the dictionary, CBHE has to leave it (or at
> least a compressed representation of it?) there, I think.  CBHE can
> compress out the entries from the primary bundle block, but 'new' ones that
> are added afterwards have to stay.  CBHE can compress these or not in the
> dictionary, so long as it has a way to recover them later and, as above, I
> don't think it has to worry about ordering on decompression.  If an
> endpoint that is added later (not referenced from the primary bundle block)
> is NOT cbhe-conformant, presumably it would have to be left in the
> dictionary intact, though cbhe could still compress the primary bundle
> block EIDs.
> 
> In *any* case, during compression cbhe probably has to crawl the list of
> extension blocks to compress any cbhe-compressible EID references there
> (since they might share entries with the primary bundle block).

Still a nightmare.  As I say, I am happy enough to stick with option (b): if you've got any EID references in any extension blocks, you simply don't use CBHE.

I don't see this as an obstacle: in the application environments that CBHE was originally intended to address (interplanetary internet) it's a challenge just to get plain-vanilla BP accepted -- by the time we're in a position to use any advanced features of BSP or any yet-to-be-invented extensions that need to add EIDs to the dictionary, bundle header compression may well no longer be an issue.

What I do *not* want to do is postpone standardization of a very simple capability that will be needed as early as next year in order to incorporate a mind-numbingly complex accommodation of capabilities that we may not need until 2025.

One other thought on this: have we perhaps reached a point where we've got a tail wagging a dog?  When I read the BSP I-D I see a fair amount of text that deals with managing security source and destination EIDs and the references to them.  It seems to me that the hoops we're finding ourselves having to jump through in order to preserve the dictionary mechanism may be a cost -- in spec complexity, implementation complexity, risk of error, processing overhead -- that exceeds the added value.

How much compression does the dictionary mechanism buy us, realistically?  Has anybody done any sort of study yet?  In particular, how often do we think an EID inserted by one BP extension is going to be identical to an EID inserted by another BP extension, when neither of them is identical to the destination, source, report-to, or current custodian?  Might it not be simpler and safer, for example, to say that when extension blocks refer to EIDs that are the destination/source/report-to/custodian they use dictionary offsets but when they refer to other EIDs they contain the EID text locally?  Is the compression we get from EID references into an expanded dictionary really more valuable than that safety and simplicity?

I'm thinking this is a precipice we can step back from if we want to: the fact that RFC5050 accommodates the insertion of additional EIDs in the dictionary doesn't mean we have to use that feature.  Maybe we just shouldn't.

Scott 

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Burleigh, Scott
> C
> Sent: Monday, March 09, 2009 1:54 PM
> To: DTN
> Subject: Re: [dtn-interest] Re(2): RG "last call" on draft-irtf-dtnrg-cbhe
> 
> > -----Original Message-----
> > From: Peter Lovell [mailto:[email-masked]]
> > Sent: Monday, March 09, 2009 10:33 AM
> > To: Kscott; David Young; Burleigh, Scott C
> > Cc: DTN
> > Subject: Re(2): [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> >
> > On Mon, Mar 9, 2009, Scott, Keith L. <[email-masked]> wrote:
> >
> > >Except that it's possible (with certain constraints, such as security)
> > >for extension blocks to insert entries into the dictionary (section
> > >4.5.2 of rfc5050, particularly the Block EID Reference Count and EID
> > >References).  It's not clear from RFC5050 that adding entries is in fact
> > >allowed, but I think the payload security block (PSB) can add an entry
> > >in order to insert a reference to the security source.
> >
> > Hi Keith,
> >
> > RFC5050 does seem to suggest that adding entries to the dictionary is
> > allowed (in the "Dictionary" discussion on page 21, as an example, and
> > there are a few others).
> >
> > Security processing certainly can add entries but the rule is that all
> > entries MUST be in an EID-list in the blocks headers. Having EID
> > references that are not in the list is unsupported and things quickly go
> > bad when the dictionary is revised.
> 
> Which means, though, that either (a) CBHE needs to compress all those
> additional dictionary entries as well (by revising the EID references in
> the extension blocks' headers, which means we need a further canonical
> order for those extension blocks' endpoint IDs' strings in the dictionary
> to enable correct decompression) or else (b) the CBHE I-D's canonical order
> of EID reference strings in the dictionary must be declared to be
> comprehensive, i.e., you can't do CBHE compression if you've got any EID
> references (as opposed to EIDs) in any extension block.  The former being a
> nightmare, I'm going for the latter.

From: "Symington, Susan F." <[email-masked]>
To: Peter Lovell <[email-masked]>
Date: Tue, 10 Mar 2009 14:08:42 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: [dtn-interest] "last call" comments on the latest BSP

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC0228851330IMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Peter,

Thank you for the good job you did incorporating extension block security i=
nto the BSP. Here are some very minor (mostly editorial) comments/questions=
 on the latest draft. The only one of real interest is comment 10, regardin=
g whether the ESB ciphersuite should be mandatory or optional:

1)      Why did you add in section 2 that the "...PCB indicates that the pa=
yload has been encrypted in whole or in part"...  When is the payload encry=
pted in part? Isn't it always encrypted in whole?  My inclination would be =
to delete "in whole or in part".

2)  Section 2.4 says: "If super-encryption if
   the block is not desired then protection of the block should be done" (T=
he second "if" should be an "of".

3)      On page 21 , integrity signature item: Do you mean "PI" rather than=
 "PS"?

4)      Section 2.7 "the content of two of the items defined above Section =
2.6:..." I think you need an "in" before "section 2.6.

5)      Very interesting about the EID-list needing to move from the encaps=
ulated bundle to the encapsulating bundle and back again. Glad you got that=
  in there.

6)      Need a hyphen before "block type of encapsulated block" (right befo=
re section 2.7 starts)

7)      Last paragraph before the beginning of section 3.3.  "ESBs are effe=
ctivelt placeholders".  Should be "effectively".

8)      Section 3.3: again, you write about "PS and PC blocks".  Shouldn't =
it be "PI and PC blocks"?

9)      Last paragraph of 3.6: "...the node MUST decrypt and/or decapsulate=
 the encapsulated in accordance"  You need to insert "ESB" after "encapsula=
ted".

10)   Section 4. Mandatory Ciphersuites: Do we really want implementation o=
f the ESB ciphersuite to be optional?  Don't we need at least one mandatory=
 ciphersuite for use with the ESB? Shouldn't implementation of the ESB ciph=
ersuite be mandatory?

11)   Section 4.4 "...however see the discussion below concerning eid-list =
entries..." I don't believe there is such a discussion below. I think it wa=
s earlier.
-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC0228851330IMCMBX2MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1287734735;
	mso-list-type:hybrid;
	mso-list-template-ids:-627149004 67698705 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:1813407991;
	mso-list-type:hybrid;
	mso-list-template-ids:-627149004 67698705 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Peter,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thank you for the good job you did incorporating exten=
sion
block security into the BSP. Here are some very minor (mostly editorial) co=
mments/questions
on the latest draft. The only one of real interest is comment 10, regarding
whether the ESB ciphersuite should be mandatory or optional:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>1)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Why did you add in section 2 that the &#8220;&#8230=
;PCB
indicates that the payload has been encrypted in whole or in part&#8221;&#8=
230;&nbsp;
When is the payload encrypted in part? Isn&#8217;t it always encrypted in
whole?&nbsp; My inclination would be to delete &#8220;in whole or in part&#=
8221;.<o:p></o:p></p>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></pre><pre
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if=
 !supportLists]><span
style=3D'mso-list:Ignore'>2)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp; </span></span><![endif]>Section 2.4 says: &#8220;If super-encryption i=
f<o:p></o:p></pre>

<p class=3DMsoNormal style=3D'margin-left:.25in'><span style=3D'font-size:1=
2.0pt;
font-family:"Times New Roman","serif"'>&nbsp;&nbsp; the block is not desire=
d
then protection of the block should be done&#8221; (The second &#8220;if&#8=
221;
should be an &#8220;of&#8221;.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in'><span style=3D'font-size:1=
2.0pt;
font-family:"Times New Roman","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>3)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>On page 21 , integrity signature item: Do you mean =
&#8220;PI&#8221;
rather than &#8220;PS&#8221;?<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>4)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Section 2.7 &#8220;the content of two of the items
defined above Section 2.6:&#8230;&#8221; I think you need an &#8220;in&#822=
1;
before &#8220;section 2.6.<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>5)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Very interesting about the EID-list needing to move=
 from
the encapsulated bundle to the encapsulating bundle and back again. Glad yo=
u
got that &nbsp;in there.<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>6)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Need a hyphen before &#8220;block type of encapsula=
ted
block&#8221; (right before section 2.7 starts)<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>7)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Last paragraph before the beginning of section
3.3.&nbsp; &#8220;ESBs are effectivelt placeholders&#8221;.&nbsp; Should be=
 &#8220;effectively&#8221;.<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>8)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Section 3.3: again, you write about &#8220;PS and P=
C
blocks&#8221;.&nbsp; Shouldn&#8217;t it be &#8220;PI and PC blocks&#8221;?<=
o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>9)<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Last paragraph of 3.6: &#8220;&#8230;the node MUST
decrypt and/or decapsulate the encapsulated in accordance&#8221;&nbsp; You =
need
to insert &#8220;ESB&#8221; after &#8220;encapsulated&#8221;.<o:p></o:p></p=
>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>10)<span style=3D'font:7.0pt "Times New Roman"'>&=
nbsp;&nbsp;
</span></span><![endif]>Section 4. Mandatory Ciphersuites: Do we really wan=
t
implementation of the ESB ciphersuite to be optional?&nbsp; Don&#8217;t we =
need
at least one mandatory ciphersuite for use with the ESB? Shouldn&#8217;t
implementation of the ESB ciphersuite be mandatory?<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>11)<span style=3D'font:7.0pt "Times New Roman"'>&=
nbsp;&nbsp;
</span></span><![endif]>Section 4.4 &#8220;&#8230;however see the discussio=
n
below concerning eid-list entries&#8230;&#8221; I don&#8217;t believe there=
 is
such a discussion below. I think it was earlier.<o:p></o:p></p>

<p class=3DMsoNormal>-susan<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
**</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>Susan
Symington</span><span style=3D'font-size:12.0pt;font-family:"Times New Roma=
n","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>The
MITRE Corporation</span><span style=3D'font-size:12.0pt;font-family:"Times =
New Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>[email-masked]</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7209
(voice)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman"=
,"serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Courier N=
ew"'>703-983-7142
(fax)</span><span style=3D'font-size:12.0pt;font-family:"Times New Roman","=
serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>***************************************************************=
***</span><o:p></o:p></p>

</div>

</body>

</html>

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC0228851330IMCMBX2MITREO_--

From: Peter TB Brett <[email-masked]>
Organization: Integral Informatics Ltd
To: [email-masked]
Date: Tue, 10 Mar 2009 17:35:20 +0000
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-checksum

--nextPart15858228.b1Hoojs1OV
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 10 March 2009 16:34:22 Stephen Farrell wrote:
> This message starts the "last call" on the Bundle Checksum
> draft. [1]
>
> Note that this should really be read in conjunction with
> the bundle security protocol draft (see the next in this
> long line of last call messages:-)
>
> Can you read and comment on this in the next month, i.e.
> before the end of April 9th, but ideally before March
> 19th so we can discuss any issues when we meet.
> =20

On p.4, the following sentence is not grammatical.

   However, [RFC4838] discusses 'reliable delivery', this is expected to
   be provided to the bundle layer, and is not a property of the bundle
   layer. =20

I suggest the following:

   Although [RFC4838] discusses 'reliable delivery', this is expected to
   be provided to the bundle layer, rather than being a property of the
   bundle layer itself.

                     Peter

--nextPart15858228.b1Hoojs1OV
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart15858228.b1Hoojs1OV--

Date: Tue, 10 Mar 2009 17:51:06 +0100
From: samo <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Remote participation on DTNRG meeting in SF

Hi!

Will it there be a chance for remote participation on DTNRG meetings (at 
least one way audio stream)?

Regards,
Samo

Date: Tue, 10 Mar 2009 16:35:48 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest]   RG "last call" on draft-irtf-dtnrg-prophet

This message starts the "last call" on the PRoPHET
draft. [1]

Can you read and comment on this in the next month, i.e.
before the end of April 9th, but ideally before March
19th so we can discuss any issues when we meet.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-prophet

Date: Tue, 10 Mar 2009 16:34:22 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-checksum

This message starts the "last call" on the Bundle Checksum
draft. [1]

Note that this should really be read in conjunction with
the bundle security protocol draft (see the next in this
long line of last call messages:-)

Can you read and comment on this in the next month, i.e.
before the end of April 9th, but ideally before March
19th so we can discuss any issues when we meet.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum

Date: Tue, 10 Mar 2009 16:34:30 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-security

This message starts the "last call" on the Bundle Security
Protocol draft. [1]

Note that this should really be read in conjunction with
the bundle checksum draft (see the previous mail in this
long line of last call messages:-)

Can you read and comment on this in the next month, i.e.
before the end of April 9th, but ideally before March
19th so we can discuss any issues when we meet.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-security-07

From: Peter Lovell <[email-masked]>
To: Keith Scott <[email-masked]>, Scott Burleigh <[email-masked]>, dtn interest <[email-masked]>, Susan <[email-masked]>
Date: Tue, 10 Mar 2009 12:23:25 -0400
Subject: [dtn-interest] Re(2): Re(2): RG "last call" on draft-irtf-dtnrg-cbhe

Hi Keith,

On Tue, Mar 10, 2009, Scott, Keith L. <[email-masked]> wrote:

>From the new version (-07) of the security spec, things might not be all
>that complicated:
>
>It is the job of the security protocol to canonicalize the EIDs
>referenced from the primary bundle header.

BAB processes the entire primary block exactly (strict
canonicalization). It includes the dictionary and doesn't pay any
attention to the various parts.

PIB mutable canonicalization looks at the bundle-source and bundle-
destination, and no others.

>Any EIDs that get added to
>the dictionary get ignored by this (I think).  Thus I should be able to
>add to / reorder the dictionary at will (provided I fix all the
>references into it).

Quite correct. Security blocks have no sensitivity to the ordering of
text pieces in the dictionary. The dictionary can be rearranged and/or
compressed as long as the process scans and updates the EID lists. A
side note for the curious: an EID list in an encrypted block can't be
updated by the process updating the dictionary. For this reason, the EID
list for any block being encrypted MUST be replicated into the
encapsulating block. The EIDs in this list will be updated. When the
block is decrypted, the stale entries are replaced by the updated ones
from the encapsulation list.

>If somebody adds a NEW EID to the dictionary, CBHE has to leave it (or
>at least a compressed representation of it?) there, I think.  CBHE can
>compress out the entries from the primary bundle block, but 'new' ones
>that are added afterwards have to stay.  CBHE can compress these or not
>in the dictionary, so long as it has a way to recover them later and, as
>above, I don't think it has to worry about ordering on decompression.

Any new EID beyond the "standard four" has to be there somewhere. I
think we have a problem if it stays in the dictionary, though, because
the cbhe "flag" indicating compression is a zero-length dictionary, IIRC.

>If an endpoint that is added later (not referenced from the primary
>bundle block) is NOT cbhe-conformant, presumably it would have to be
>left in the dictionary intact, though cbhe could still compress the
>primary bundle block EIDs.
>
>In *any* case, during compression cbhe probably has to crawl the list of
>extension blocks to compress any cbhe-compressible EID references there
>(since they might share entries with the primary bundle block).

We have choices here. If we think that there won't be partially-
conformant systems deployed (i.e. they'll be 100% or not at all) then
crawling the list and converting them all makes sense. Reconstituting
the dictionary is a bit trickier since you have to have all the blocks
(i.e. all the EID lists) before you can emit the dictionary.

Alternatively, if we have a solution to the "flag" question, we can
leave extra entries in the dictionary. In this case, reconstituting the
dictionary is OK iff the standard four entries are guaranteed to be
first. The rfc doesn't mandate this but RI does it this way. If we don't
want to rely on that, we can compress the dictionary to make it so but
that gets back to the issue above -- we have to see all the EID lists
before we can emit the dictionary. Assuming we can, then we compress the
standard four and leave the others as-is. We can't selectively compress
these as we don't have any way to differentiate compressed from
uncompressed entries.

I suspect we'll be having more design discussions on this :)

Cheers.....Peter

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Tue, 10 Mar 2009 09:04:33 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Teemu
> Sent: Tuesday, March 10, 2009 6:57 AM
> To: Stephen Farrell; DTN
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> Hi,
> 
> How would I make sure NODE_NUMBERs of my nodes do not collide with those of
> other networks? It seems like either there should be a way to register my
> node numbers, perhaps be allocated a range, or use my own authority instead
> of "cbhe.ccsds.org".

I'd vote for approach (a).  The near-term application of CBHE is in space flight operations, a community that is so small that node number registration is a non-problem.  If CBHE were used more broadly, clearly some sort of node number assignment bureaucracy would grow up.  That sort of thing doesn't seem to have crippled the adoption of Ethernet, though, for example.  If it's cost-effective, it will happen; if not, it won't.

> The first approach would come with the overhead of maintaining the registry
> and having to register all the nodes. Also, I might know that my nodes will
> only be talking amongst themselves in which case I should be able to pick
> the numbers from some private range without registering.

Sure, the latter is always an option.  Not much different from running a private IP-based LAN.

> The second approach would require the authority component to be sent along
> with the bundle in order to enable decompression, which kind of negates the
> whole point of the mechanism.

Exactly.

> However, as the node number grows so do the
> SDNVs and at some point it would become more efficient to use a different
> authority with smaller node numbers.

I don't think so.  In general I would expect a genuinely flat namespace to be more densely populated than a hierarchical namespace.

> I'm also wondering about the implications for routing mechanisms of this
> type of a naming scheme, but I suspect that's out of scope for this draft.

It is, but as an aside I'll point out that the Contact Graph Routing we used for the Deep Impact Network experiment is very comfortable with numeric node identifiers.  Relies on them, in fact.

> Nit:
> Section 1: s/strategems/stratagems

Thanks!

Scott

From: "Scott, Keith L." <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>, DTN <[email-masked]>, "[email-masked]" <[email-masked]>, "Symington, Susan F." <[email-masked]>
Date: Tue, 10 Mar 2009 10:52:24 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  RG "last call" on draft-irtf-dtnrg-cbhe

>From the new version (-07) of the security spec, things might not be all that complicated:

It is the job of the security protocol to canonicalize the EIDs referenced from the primary bundle header.  Any EIDs that get added to the dictionary get ignored by this (I think).  Thus I should be able to add to / reorder the dictionary at will (provided I fix all the references into it).

If somebody adds a NEW EID to the dictionary, CBHE has to leave it (or at least a compressed representation of it?) there, I think.  CBHE can compress out the entries from the primary bundle block, but 'new' ones that are added afterwards have to stay.  CBHE can compress these or not in the dictionary, so long as it has a way to recover them later and, as above, I don't think it has to worry about ordering on decompression.  If an endpoint that is added later (not referenced from the primary bundle block) is NOT cbhe-conformant, presumably it would have to be left in the dictionary intact, though cbhe could still compress the primary bundle block EIDs.

In *any* case, during compression cbhe probably has to crawl the list of extension blocks to compress any cbhe-compressible EID references there (since they might share entries with the primary bundle block).

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Burleigh, Scott C
Sent: Monday, March 09, 2009 1:54 PM
To: DTN
Subject: Re: [dtn-interest] Re(2): RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: Peter Lovell [mailto:[email-masked]]
> Sent: Monday, March 09, 2009 10:33 AM
> To: Kscott; David Young; Burleigh, Scott C
> Cc: DTN
> Subject: Re(2): [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> On Mon, Mar 9, 2009, Scott, Keith L. <[email-masked]> wrote:
> 
> >Except that it's possible (with certain constraints, such as security)
> >for extension blocks to insert entries into the dictionary (section
> >4.5.2 of rfc5050, particularly the Block EID Reference Count and EID
> >References).  It's not clear from RFC5050 that adding entries is in fact
> >allowed, but I think the payload security block (PSB) can add an entry
> >in order to insert a reference to the security source.
> 
> Hi Keith,
> 
> RFC5050 does seem to suggest that adding entries to the dictionary is
> allowed (in the "Dictionary" discussion on page 21, as an example, and
> there are a few others).
> 
> Security processing certainly can add entries but the rule is that all
> entries MUST be in an EID-list in the blocks headers. Having EID
> references that are not in the list is unsupported and things quickly go
> bad when the dictionary is revised.

Which means, though, that either (a) CBHE needs to compress all those additional dictionary entries as well (by revising the EID references in the extension blocks' headers, which means we need a further canonical order for those extension blocks' endpoint IDs' strings in the dictionary to enable correct decompression) or else (b) the CBHE I-D's canonical order of EID reference strings in the dictionary must be declared to be comprehensive, i.e., you can't do CBHE compression if you've got any EID references (as opposed to EIDs) in any extension block.  The former being a nightmare, I'm going for the latter.

Scott

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 10 Mar 2009 15:56:35 +0200
From: Teemu <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

Hi,

How would I make sure NODE_NUMBERs of my nodes do not collide with those of
other networks? It seems like either there should be a way to register my
node numbers, perhaps be allocated a range, or use my own authority instead
of "cbhe.ccsds.org".

The first approach would come with the overhead of maintaining the registry
and having to register all the nodes. Also, I might know that my nodes will
only be talking amongst themselves in which case I should be able to pick
the numbers from some private range without registering.

The second approach would require the authority component to be sent along
with the bundle in order to enable decompression, which kind of negates the
whole point of the mechanism. However, as the node number grows so do the
SDNVs and at some point it would become more efficient to use a different
authority with smaller node numbers.

I'm also wondering about the implications for routing mechanisms of this
type of a naming scheme, but I suspect that's out of scope for this draft.

Nit:
Section 1: s/strategems/stratagems

Cheers,
-Teemu

On 5.3.2009 20.54, "Stephen Farrell" <[email-masked]> wrote:

> 
> This message starts the "last call" on the Compressed
> Bundle Header Encoding draft. [1]
> 
> Can you read and comment on this in the next month, i.e.
> before the end of April 5th, but ideally before March
> 19th so we can discuss any issues when we meet.
> 
> Please bear in mind that as an IRTF RG, and not an
> IETF WG, we do not need to establish rough consensus
> for documents, but if we do have that its a good thing.
> For the later stages of review, it's useful if folks have
> said "I agree, its ok and its ready" or equivalent so
> please do send a mail to the list saying that if it
> applies. (Preserving the subject line so we can just
> add a link in the tracker later.)
> 
> Thanks,
> Stephen.
> 
> 
> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Peter Lovell <[email-masked]>
To: Scott Burleigh <[email-masked]>, dtn interest <[email-masked]>
Date: Tue, 10 Mar 2009 08:24:24 -0400
Subject: [dtn-interest] Re(2): Re(2): RG "last call" on draft-irtf-dtnrg-cbhe

On Mon, Mar 9, 2009, Scott C. Burleigh <[email-masked]> wrote:

>Peter Lovell wrote:
>> On Mon, Mar 9, 2009, Burleigh, Scott C <[email-masked]>
>wrote:
>>
>>
>>>> -----Original Message-----
>>>> From: Peter Lovell [mailto:[email-masked]]
>>>> Sent: Monday, March 09, 2009 10:33 AM
>>>> To: Kscott; David Young; Burleigh, Scott C
>>>> Cc: DTN
>>>> Subject: Re(2): [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>>>>
>>>> On Mon, Mar 9, 2009, Scott, Keith L. <[email-masked]> wrote:
>>>>
>>>>
>>>>> Except that it's possible (with certain constraints, such as security)
>>>>> for extension blocks to insert entries into the dictionary (section
>>>>> 4.5.2 of rfc5050, particularly the Block EID Reference Count and EID
>>>>> References).  It's not clear from RFC5050 that adding entries is in fact
>>>>> allowed, but I think the payload security block (PSB) can add an entry
>>>>> in order to insert a reference to the security source.
>>>>>
>>>> Hi Keith,
>>>>
>>>> RFC5050 does seem to suggest that adding entries to the dictionary is
>>>> allowed (in the "Dictionary" discussion on page 21, as an example, and
>>>> there are a few others).
>>>>
>>>> Security processing certainly can add entries but the rule is that all
>>>> entries MUST be in an EID-list in the blocks headers. Having EID
>>>> references that are not in the list is unsupported and things quickly go
>>>> bad when the dictionary is revised.
>>>>
>>> Which means, though, that either (a) CBHE needs to compress all those
>>> additional dictionary entries as well (by revising the EID references in
>>> the extension blocks' headers, which means we need a further canonical
>>> order for those extension blocks' endpoint IDs' strings in the
>>> dictionary to enable correct decompression) or else (b) the CBHE I-D's
>>> canonical order of EID reference strings in the dictionary must be
>>> declared to be comprehensive, i.e., you can't do CBHE compression if
>>> you've got any EID references (as opposed to EIDs) in any extension
>>> block.  The former being a nightmare, I'm going for the latter.
>>>
>>> Scott
>>>
>> Hi Scott,
>>
>> it has been quite a while now but I seem to remember some discussion
>> about the dictionary having a canonical list. I don't remember why we
>> didn't do it but it was a topic of discussion.
>>
>> Security blocks applied by the bundle creator will quite possibly have
>> no EID list entries, but any added afterward will have at least a
>> security-source identifier. That will violate rule (b) and prevent CBHE,
>> which is unfortunate.
>Hmmm.  I have stayed resolutely out of the BSP specification activity,
>since everybody involved knows way more about security than I do, but
>maybe I should have been watching a little more closely so that I
>wouldn't be quite so surprised by your second paragraph.  I believe what
>you are saying is that if I've got a 3-hop path A-B-C-D and I want
>bundle authentication on every hop, then as soon as nodes B adds its
>bundle authentication block I can no longer use CBHE.  Since we plan to
>use both CBHE and bundle authentication in the DINET 2 experiment, I am
>somewhat nonplussed.
>
>On a quick review of the BSP I-D I find that the reason the BAB needs an
>EID reference is to record the applicable security-source, but that "if
>the forwarding node is known through other implementation-specific
>means, such as from the convergence layer, an EID reference need not be
>included."  We will have another means of knowing the forwarding node,
>so I guess this is not a problem.  Something I will want to watch out
>for in the future, though.
>
>Scott

Hi Scott,

BAB is not so much of a problem since it's for a single hop.

The scenario which would be a problem is if the B-C section (one hop or
it could be several) is insecure so B adds PayloadIntegrity or
PayloadConfidentiality. It could be a network-to-network tunnel, for
example. "B" would be the security-source and that would have to be in
the dictionary. If C is the security-destination and that would have to
be there too.

So end-to-end PIB and PCB from bundle-source to bundle-destination would
be OK since those SHOULD not have EID-list entries. I say SHOULD since
they're recommended against but not prohibited.

Cheers.....Peter

Date: Mon, 09 Mar 2009 20:53:07 -0700
From: "Scott C. Burleigh" <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  RG "last call" on draft-irtf-dtnrg-cbhe

This is a multi-part message in MIME format.
--------------000704050004060406030706
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> On Mon, Mar 9, 2009, Burleigh, Scott C <[email-masked]> wrote:
>
>   
>>> -----Original Message-----
>>> From: Peter Lovell [mailto:[email-masked]]
>>> Sent: Monday, March 09, 2009 10:33 AM
>>> To: Kscott; David Young; Burleigh, Scott C
>>> Cc: DTN
>>> Subject: Re(2): [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>>>
>>> On Mon, Mar 9, 2009, Scott, Keith L. <[email-masked]> wrote:
>>>
>>>       
>>>> Except that it's possible (with certain constraints, such as security)
>>>> for extension blocks to insert entries into the dictionary (section
>>>> 4.5.2 of rfc5050, particularly the Block EID Reference Count and EID
>>>> References).  It's not clear from RFC5050 that adding entries is in fact
>>>> allowed, but I think the payload security block (PSB) can add an entry
>>>> in order to insert a reference to the security source.
>>>>         
>>> Hi Keith,
>>>
>>> RFC5050 does seem to suggest that adding entries to the dictionary is
>>> allowed (in the "Dictionary" discussion on page 21, as an example, and
>>> there are a few others).
>>>
>>> Security processing certainly can add entries but the rule is that all
>>> entries MUST be in an EID-list in the blocks headers. Having EID
>>> references that are not in the list is unsupported and things quickly go
>>> bad when the dictionary is revised.
>>>       
>> Which means, though, that either (a) CBHE needs to compress all those
>> additional dictionary entries as well (by revising the EID references in
>> the extension blocks' headers, which means we need a further canonical
>> order for those extension blocks' endpoint IDs' strings in the
>> dictionary to enable correct decompression) or else (b) the CBHE I-D's
>> canonical order of EID reference strings in the dictionary must be
>> declared to be comprehensive, i.e., you can't do CBHE compression if
>> you've got any EID references (as opposed to EIDs) in any extension
>> block.  The former being a nightmare, I'm going for the latter.
>>
>> Scott
>>     
> Hi Scott,
>
> it has been quite a while now but I seem to remember some discussion
> about the dictionary having a canonical list. I don't remember why we
> didn't do it but it was a topic of discussion.
>
> Security blocks applied by the bundle creator will quite possibly have
> no EID list entries, but any added afterward will have at least a
> security-source identifier. That will violate rule (b) and prevent CBHE,
> which is unfortunate.
Hmmm.  I have stayed resolutely out of the BSP specification activity, 
since everybody involved knows way more about security than I do, but 
maybe I should have been watching a little more closely so that I 
wouldn't be quite so surprised by your second paragraph.  I believe what 
you are saying is that if I've got a 3-hop path A-B-C-D and I want 
bundle authentication on every hop, then as soon as nodes B adds its 
bundle authentication block I can no longer use CBHE.  Since we plan to 
use both CBHE and bundle authentication in the DINET 2 experiment, I am 
somewhat nonplussed.

On a quick review of the BSP I-D I find that the reason the BAB needs an 
EID reference is to record the applicable security-source, but that "if 
the forwarding node is known through other implementation-specific 
means, such as from the convergence layer, an EID reference need not be 
included."  We will have another means of knowing the forwarding node, 
so I guess this is not a problem.  Something I will want to watch out 
for in the future, though.

Scott

--------------000704050004060406030706
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">On Mon, Mar 9, 2009, Burleigh, Scott C <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">-----Original Message-----
From: Peter Lovell [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]
Sent: Monday, March 09, 2009 10:33 AM
To: Kscott; David Young; Burleigh, Scott C
Cc: DTN
Subject: Re(2): [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

On Mon, Mar 9, 2009, Scott, Keith L. <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

      </pre>
      <blockquote type="cite">
        <pre wrap="">Except that it's possible (with certain constraints, such as security)
for extension blocks to insert entries into the dictionary (section
4.5.2 of rfc5050, particularly the Block EID Reference Count and EID
References).  It's not clear from RFC5050 that adding entries is in fact
allowed, but I think the payload security block (PSB) can add an entry
in order to insert a reference to the security source.
        </pre>
      </blockquote>
      <pre wrap="">Hi Keith,

RFC5050 does seem to suggest that adding entries to the dictionary is
allowed (in the "Dictionary" discussion on page 21, as an example, and
there are a few others).

Security processing certainly can add entries but the rule is that all
entries MUST be in an EID-list in the blocks headers. Having EID
references that are not in the list is unsupported and things quickly go
bad when the dictionary is revised.
      </pre>
    </blockquote>
    <pre wrap="">Which means, though, that either (a) CBHE needs to compress all those
additional dictionary entries as well (by revising the EID references in
the extension blocks' headers, which means we need a further canonical
order for those extension blocks' endpoint IDs' strings in the
dictionary to enable correct decompression) or else (b) the CBHE I-D's
canonical order of EID reference strings in the dictionary must be
declared to be comprehensive, i.e., you can't do CBHE compression if
you've got any EID references (as opposed to EIDs) in any extension
block.  The former being a nightmare, I'm going for the latter.

Scott
    </pre>
  </blockquote>
  <pre wrap=""><!---->Hi Scott,

it has been quite a while now but I seem to remember some discussion
about the dictionary having a canonical list. I don't remember why we
didn't do it but it was a topic of discussion.

Security blocks applied by the bundle creator will quite possibly have
no EID list entries, but any added afterward will have at least a
security-source identifier. That will violate rule (b) and prevent CBHE,
which is unfortunate.</pre>
</blockquote>
Hmmm.  I have stayed resolutely out of the BSP specification activity,
since everybody involved knows way more about security than I do, but
maybe I should have been watching a little more closely so that I
wouldn't be quite so surprised by your second paragraph.  I believe
what you are saying is that if I've got a 3-hop path A-B-C-D and I want
bundle authentication on every hop, then as soon as nodes B adds its
bundle authentication block I can no longer use CBHE.  Since we plan to
use both CBHE and bundle authentication in the DINET 2 experiment, I am
somewhat nonplussed.<br>
<br>
On a quick review of the BSP I-D I find that the reason the BAB needs
an EID reference is to record the applicable security-source, but that
"if the forwarding node is known through other implementation-specific
means, such as from the convergence layer, an EID reference need not be
included."  We will have another means of knowing the forwarding node,
so I guess this is not a problem.  Something I will want to watch out
for in the future, though.<br>
<br>
Scott<br>
</body>
</html>

--------------000704050004060406030706--

From: Peter Lovell <[email-masked]>
To: Scott Burleigh <[email-masked]>, dtn interest <[email-masked]>
Date: Mon, 09 Mar 2009 22:10:51 -0400
Subject: [dtn-interest] Re(2): Re(2): RG "last call" on draft-irtf-dtnrg-cbhe

On Mon, Mar 9, 2009, Burleigh, Scott C <[email-masked]> wrote:

>> -----Original Message-----
>> From: Peter Lovell [mailto:[email-masked]]
>> Sent: Monday, March 09, 2009 10:33 AM
>> To: Kscott; David Young; Burleigh, Scott C
>> Cc: DTN
>> Subject: Re(2): [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
>>
>> On Mon, Mar 9, 2009, Scott, Keith L. <[email-masked]> wrote:
>>
>> >Except that it's possible (with certain constraints, such as security)
>> >for extension blocks to insert entries into the dictionary (section
>> >4.5.2 of rfc5050, particularly the Block EID Reference Count and EID
>> >References).  It's not clear from RFC5050 that adding entries is in fact
>> >allowed, but I think the payload security block (PSB) can add an entry
>> >in order to insert a reference to the security source.
>>
>> Hi Keith,
>>
>> RFC5050 does seem to suggest that adding entries to the dictionary is
>> allowed (in the "Dictionary" discussion on page 21, as an example, and
>> there are a few others).
>>
>> Security processing certainly can add entries but the rule is that all
>> entries MUST be in an EID-list in the blocks headers. Having EID
>> references that are not in the list is unsupported and things quickly go
>> bad when the dictionary is revised.
>
>Which means, though, that either (a) CBHE needs to compress all those
>additional dictionary entries as well (by revising the EID references in
>the extension blocks' headers, which means we need a further canonical
>order for those extension blocks' endpoint IDs' strings in the
>dictionary to enable correct decompression) or else (b) the CBHE I-D's
>canonical order of EID reference strings in the dictionary must be
>declared to be comprehensive, i.e., you can't do CBHE compression if
>you've got any EID references (as opposed to EIDs) in any extension
>block.  The former being a nightmare, I'm going for the latter.
>
>Scott

Hi Scott,

it has been quite a while now but I seem to remember some discussion
about the dictionary having a canonical list. I don't remember why we
didn't do it but it was a topic of discussion.

Security blocks applied by the bundle creator will quite possibly have
no EID list entries, but any added afterward will have at least a
security-source identifier. That will violate rule (b) and prevent CBHE,
which is unfortunate.

Regards.....Peter

From: "Symington, Susan F." <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 9 Mar 2009 15:28:50 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-retrans-block

--_002_F5830D8920D7BA4DB8BCFE1DC57164AC0228850E45IMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stephen,

I will reorganize the draft as you suggest with an applicability statement =
up front that makes clear that use of the BAB along every hop is needed and=
 that routing loops won't be tolerated if replays are being suppressed. Att=
ached are your comments along with a response indicating how I plan to addr=
ess each.

-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: Friday, March 06, 2009 11:42 AM
>To: Symington, Susan F.
>Cc: DTN
>Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-
>retrans-block
>
>
>Hi Susan,
>
>The attached are my comments on this. I guess the
>main one is: "#0, I think that overall this one's not
>really ready as-is."
>
>Stephen.
>
>
>

--_002_F5830D8920D7BA4DB8BCFE1DC57164AC0228850E45IMCMBX2MITREO_
Content-Type: text/plain; name="retran-block-comments-sf-response.txt"
Content-Description: retran-block-comments-sf-response.txt
Content-Disposition: attachment;
	filename="retran-block-comments-sf-response.txt"; size=9072;
	creation-date="Mon, 09 Mar 2009 15:28:11 GMT";
	modification-date="Mon, 09 Mar 2009 15:28:11 GMT"
Content-Transfer-Encoding: base64

--_002_F5830D8920D7BA4DB8BCFE1DC57164AC0228850E45IMCMBX2MITREO_--

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Mon, 9 Mar 2009 10:53:33 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  RG "last call" on draft-irtf-dtnrg-cbhe

> -----Original Message-----
> From: Peter Lovell [mailto:[email-masked]]
> Sent: Monday, March 09, 2009 10:33 AM
> To: Kscott; David Young; Burleigh, Scott C
> Cc: DTN
> Subject: Re(2): [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> On Mon, Mar 9, 2009, Scott, Keith L. <[email-masked]> wrote:
> 
> >Except that it's possible (with certain constraints, such as security)
> >for extension blocks to insert entries into the dictionary (section
> >4.5.2 of rfc5050, particularly the Block EID Reference Count and EID
> >References).  It's not clear from RFC5050 that adding entries is in fact
> >allowed, but I think the payload security block (PSB) can add an entry
> >in order to insert a reference to the security source.
> 
> Hi Keith,
> 
> RFC5050 does seem to suggest that adding entries to the dictionary is
> allowed (in the "Dictionary" discussion on page 21, as an example, and
> there are a few others).
> 
> Security processing certainly can add entries but the rule is that all
> entries MUST be in an EID-list in the blocks headers. Having EID
> references that are not in the list is unsupported and things quickly go
> bad when the dictionary is revised.

Which means, though, that either (a) CBHE needs to compress all those additional dictionary entries as well (by revising the EID references in the extension blocks' headers, which means we need a further canonical order for those extension blocks' endpoint IDs' strings in the dictionary to enable correct decompression) or else (b) the CBHE I-D's canonical order of EID reference strings in the dictionary must be declared to be comprehensive, i.e., you can't do CBHE compression if you've got any EID references (as opposed to EIDs) in any extension block.  The former being a nightmare, I'm going for the latter.

Scott

From: Peter Lovell <[email-masked]>
To: Kscott <[email-masked]>, David Young <[email-masked]>, "Burleigh, Scott C" <[email-masked]>
Date: Mon, 09 Mar 2009 13:32:39 -0400
Cc: DTN <[email-masked]>
Subject: [dtn-interest] Re(2):  RG "last call" on draft-irtf-dtnrg-cbhe

On Mon, Mar 9, 2009, Scott, Keith L. <[email-masked]> wrote:

>Except that it's possible (with certain constraints, such as security)
>for extension blocks to insert entries into the dictionary (section
>4.5.2 of rfc5050, particularly the Block EID Reference Count and EID
>References).  It's not clear from RFC5050 that adding entries is in fact
>allowed, but I think the payload security block (PSB) can add an entry
>in order to insert a reference to the security source. 

Hi Keith,

RFC5050 does seem to suggest that adding entries to the dictionary is
allowed (in the "Dictionary" discussion on page 21, as an example, and
there are a few others). 

Security processing certainly can add entries but the rule is that all
entries MUST be in an EID-list in the blocks headers. Having EID
references that are not in the list is unsupported and things quickly go
bad when the dictionary is revised.

Cheers.....Peter

From: "Scott, Keith L." <[email-masked]>
To: David Young <[email-masked]>, "Burleigh, Scott C" <[email-masked]>
Date: Mon, 9 Mar 2009 12:50:32 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

Except that it's possible (with certain constraints, such as security) for extension blocks to insert entries into the dictionary (section 4.5.2 of rfc5050, particularly the Block EID Reference Count and EID References).  It's not clear from RFC5050 that adding entries is in fact allowed, but I think the payload security block (PSB) can add an entry in order to insert a reference to the security source.  The constraint at the beginning of section 2.1 might want to read:

   Compressed Bundle Header Encoding (CBHE) is possible only when all
   endpoint IDs in the dictionary of a given bundle are "CBHE-
                       ^^^^^^^^^^
   conformant".  Two forms of endpoint ID are CBHE-conformant: (a) the
   null endpoint ID "dtn:none" and (b) any endpoint ID whose scheme name
   is "dtn" and whose authority component is "cbhe.ccsds.org".

and then remove the text in 3.1

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Young
Sent: Monday, March 09, 2009 12:06 PM
To: Burleigh, Scott C
Cc: DTN
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

This looks good to me, with one issue:

In section 3.1 "Transmission", there is a line reading "whose
extension blocks (if any) contain no citations of endpoint IDs that
are contained in the primary block's dictionary."  I would move this
line into the 2.1 "constraints" section.  I also think this line may
not be necessary at all.  Section 2.1 describes how a dictionary
should be formatted- a constraint that ensures implementors can
compress and restore the dictionary exactly.  Since
compression/restoration of the dictionary is an entirely
convergence-layer step, and I presume any extended headers aren't
interpreted by the CL, then this concern about referencing the
dictionary is unfounded.

On Thu, Mar 5, 2009 at 2:54 PM, Stephen Farrell
<[email-masked]> wrote:
>
> This message starts the "last call" on the Compressed
> Bundle Header Encoding draft. [1]
>
> Can you read and comment on this in the next month, i.e.
> before the end of April 5th, but ideally before March
> 19th so we can discuss any issues when we meet.
>
> Please bear in mind that as an IRTF RG, and not an
> IETF WG, we do not need to establish rough consensus
> for documents, but if we do have that its a good thing.
> For the later stages of review, it's useful if folks have
> said "I agree, its ok and its ready" or equivalent so
> please do send a mail to the list saying that if it
> applies. (Preserving the subject line so we can just
> add a link in the tracker later.)
>
> Thanks,
> Stephen.
>
>
> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
David Young
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: DTN <[email-masked]>
Date: Mon, 9 Mar 2009 09:21:31 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

Excellent point.  The new stuff in 2.1 makes that old constraint unnecessary.  I'll fix the text.

Scott

> -----Original Message-----
> From: David Young [mailto:[email-masked]]
> Sent: Monday, March 09, 2009 9:06 AM
> To: Burleigh, Scott C
> Cc: DTN
> Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe
> 
> This looks good to me, with one issue:
> 
> In section 3.1 "Transmission", there is a line reading "whose
> extension blocks (if any) contain no citations of endpoint IDs that
> are contained in the primary block's dictionary."  I would move this
> line into the 2.1 "constraints" section.  I also think this line may
> not be necessary at all.  Section 2.1 describes how a dictionary
> should be formatted- a constraint that ensures implementors can
> compress and restore the dictionary exactly.  Since
> compression/restoration of the dictionary is an entirely
> convergence-layer step, and I presume any extended headers aren't
> interpreted by the CL, then this concern about referencing the
> dictionary is unfounded.
> 
> 
> On Thu, Mar 5, 2009 at 2:54 PM, Stephen Farrell
> <[email-masked]> wrote:
> >
> > This message starts the "last call" on the Compressed
> > Bundle Header Encoding draft. [1]
> >
> > Can you read and comment on this in the next month, i.e.
> > before the end of April 5th, but ideally before March
> > 19th so we can discuss any issues when we meet.
> >
> > Please bear in mind that as an IRTF RG, and not an
> > IETF WG, we do not need to establish rough consensus
> > for documents, but if we do have that its a good thing.
> > For the later stages of review, it's useful if folks have
> > said "I agree, its ok and its ready" or equivalent so
> > please do send a mail to the list saying that if it
> > applies. (Preserving the subject line so we can just
> > add a link in the tracker later.)
> >
> > Thanks,
> > Stephen.
> >
> >
> > [1] http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> 
> 
> 
> --
> David Young

Date: Mon, 9 Mar 2009 12:06:21 -0400
From: David Young <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-cbhe

This looks good to me, with one issue:

In section 3.1 "Transmission", there is a line reading "whose
extension blocks (if any) contain no citations of endpoint IDs that
are contained in the primary block's dictionary."  I would move this
line into the 2.1 "constraints" section.  I also think this line may
not be necessary at all.  Section 2.1 describes how a dictionary
should be formatted- a constraint that ensures implementors can
compress and restore the dictionary exactly.  Since
compression/restoration of the dictionary is an entirely
convergence-layer step, and I presume any extended headers aren't
interpreted by the CL, then this concern about referencing the
dictionary is unfounded.

On Thu, Mar 5, 2009 at 2:54 PM, Stephen Farrell
<[email-masked]> wrote:
>
> This message starts the "last call" on the Compressed
> Bundle Header Encoding draft. [1]
>
> Can you read and comment on this in the next month, i.e.
> before the end of April 5th, but ideally before March
> 19th so we can discuss any issues when we meet.
>
> Please bear in mind that as an IRTF RG, and not an
> IETF WG, we do not need to establish rough consensus
> for documents, but if we do have that its a good thing.
> For the later stages of review, it's useful if folks have
> said "I agree, its ok and its ready" or equivalent so
> please do send a mail to the list saying that if it
> applies. (Preserving the subject line so we can just
> add a link in the tracker later.)
>
> Thanks,
> Stephen.
>
>
> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
David Young

From: "Fall, Kevin" <[email-masked]>
To: Wendy Haven <[email-masked]>, Peter Lovell <[email-masked]>
Date: Sat, 7 Mar 2009 13:23:11 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] where to stay for meeting?

--_000_02968BB921677D479DAB47F25B731223F39BF4ACorsmsx504amrcor_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_02968BB921677D479DAB47F25B731223F39BF4ACorsmsx504amrcor_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_02968BB921677D479DAB47F25B731223F39BF4ACorsmsx504amrcor_--

From: Marshall Eubanks <[email-masked]>
To: Hans Kruse <[email-masked]>
Date: Fri, 6 Mar 2009 15:06:13 -0500
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-metadata-block

On Mar 6, 2009, at 2:51 PM, Hans Kruse wrote:

> I have never requested a new registry from IANA, so I am not sure  
> yet as to the process there.

The most straightforward way is to publish an RFC that describes the  
registry and its use. IANA will take case
of everything as part of the publication process.

Regards
Marshall

>  However, in the registries I have work with, normally all that is  
> recorded and published  is the code point (number), a human-readable  
> tag, possibly a brief one-sentence description, and a contact.   
> After all, the main purpose is to avoid collisions.
>
> The reason I suggested a range of "private" numbers (some protocols  
> call them experimental) is for the case where you know up-front that  
> your bundles will never leave the closed network you are working  
> in.  You control all the ontologies, so you can coordinate  
> locally.   The draft then makes clear that you cannot send bundles  
> with these code points into a "public" portion of the DTN network,  
> and makes clear that bundles from other sites that you permit into  
> your network may contain code points that collide with yours.  The  
> closest analogy I can think of are RFC1918 private IP addresses, or  
> the "vendor specific" DHCP options.
>
> On Mar 6, 2009, at 12:01 PM, Symington, Susan F. wrote:
>
>> You and Stephen make the good point that ontologies might collide,  
>> and yes, I agree that this is undesirable. Ideally it would be nice  
>> to be able to reserve a number or range of numbers that are  
>> reserved for a specific ontology or set of ontologies without  
>> having to make the details or anything more than the name and  
>> contact information for a specific ontology publicly available. Is  
>> this possible? I am not that familiar with IANA. If we just specify  
>> a range of numbers that do (or do not) require IANA registration  
>> and  use those values for "private" ontologies, then it seems that  
>> there would still be the danger that folks might use the same  
>> number for two different ontologies.
>
> Hans Kruse, Professor
> J. Warren McClure School of Information and Telecommunication Systems
> Adjunct Associate Professor of Electrical Engineering and Computer  
> Science
> 292 Lindley Hall, Ohio University, Athens, OH, 45701
> 740-593-4891 voice, 740-593-4889 fax
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Hans Kruse <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Date: Fri, 6 Mar 2009 14:51:07 -0500
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-metadata-block

--Apple-Mail-5-363829634
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I have never requested a new registry from IANA, so I am not sure yet  
as to the process there.  However, in the registries I have work with,  
normally all that is recorded and published  is the code point  
(number), a human-readable tag, possibly a brief one-sentence  
description, and a contact.  After all, the main purpose is to avoid  
collisions.

The reason I suggested a range of "private" numbers (some protocols  
call them experimental) is for the case where you know up-front that  
your bundles will never leave the closed network you are working in.   
You control all the ontologies, so you can coordinate locally.   The  
draft then makes clear that you cannot send bundles with these code  
points into a "public" portion of the DTN network, and makes clear  
that bundles from other sites that you permit into your network may  
contain code points that collide with yours.  The closest analogy I  
can think of are RFC1918 private IP addresses, or the "vendor  
specific" DHCP options.

On Mar 6, 2009, at 12:01 PM, Symington, Susan F. wrote:

> You and Stephen make the good point that ontologies might collide,  
> and yes, I agree that this is undesirable. Ideally it would be nice  
> to be able to reserve a number or range of numbers that are reserved  
> for a specific ontology or set of ontologies without having to make  
> the details or anything more than the name and contact information  
> for a specific ontology publicly available. Is this possible? I am  
> not that familiar with IANA. If we just specify a range of numbers  
> that do (or do not) require IANA registration and  use those values  
> for "private" ontologies, then it seems that there would still be  
> the danger that folks might use the same number for two different  
> ontologies.

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-5-363829634
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I have never requested a new =
registry from IANA, so I am not sure yet as to the process there. =
&nbsp;However, in the registries I have work with, normally all that is =
recorded and published &nbsp;is the code point (number), a =
human-readable tag, possibly a brief one-sentence description, and a =
contact. &nbsp;After all, the main purpose is to avoid =
collisions.<div><br></div><div>The reason I suggested a range of =
"private" numbers (some protocols call them experimental) is for the =
case where you know up-front that your bundles will never leave the =
closed network you are working in. &nbsp;You control all the ontologies, =
so you can coordinate locally. &nbsp; The draft then makes clear that =
you cannot send bundles with these code points into a "public" portion =
of the DTN network, and makes clear that bundles from other sites that =
you permit into your network may contain code points that collide with =
yours. &nbsp;The closest analogy I can think of are RFC1918 private IP =
addresses, or the "vendor specific" DHCP =
options.</div><div><br><div><div>On Mar 6, 2009, at 12:01 PM, Symington, =
Susan F. wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; ">You and Stephen make the good =
point that ontologies might collide, and yes, I agree that this is =
undesirable. Ideally it would be nice to be able to reserve a number or =
range of numbers that are reserved for a specific ontology or set of =
ontologies without having to make the details or anything more than the =
name and contact information for a specific ontology publicly available. =
Is this possible? I am not that familiar with IANA. If we just specify a =
range of numbers that do (or do not) require IANA registration and =
&nbsp;use those values for "private" ontologies, then it seems that =
there would still be the danger that folks might use the same number for =
two different ontologies. &nbsp;<br></span></blockquote></div><br><div> =
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-5-363829634--

From: "Symington, Susan F." <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 6 Mar 2009 12:01:05 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-metadata-block

Stephen and Hans: Thanks for your comments. I am responding to them in the same email because they were related.

Stephen, 

Our thinking is that as people experiment with different ontologies and experience success with them, the ones that can be made publicly available would be made publicly available. We would want everyone to know that block type 0x08 encodes an ontology so that all nodes that support ontologies could support this block type in the same way, by looking up to see whether they support the specific ontology that is identified and, if so, indexing to a specific way of treating the bundle based on that ontology.  (A router might support multiple ontologies.)  

My understanding is that there are other implementations that use this metadtata block (0x08).  I believe BBN does.  So it isn't block type 0x08 that I would think should be private; just, perhaps, a particular ontology that is encoded in this metadata block.

Hans, 

You and Stephen make the good point that ontologies might collide, and yes, I agree that this is undesirable. Ideally it would be nice to be able to reserve a number or range of numbers that are reserved for a specific ontology or set of ontologies without having to make the details or anything more than the name and contact information for a specific ontology publicly available. Is this possible? I am not that familiar with IANA. If we just specify a range of numbers that do (or do not) require IANA registration and  use those values for "private" ontologies, then it seems that there would still be the danger that folks might use the same number for two different ontologies.  

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

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Thursday, March 05, 2009 3:38 PM
>To: Symington, Susan F.
>Cc: Stephen Farrell; DTN
>Subject: RE: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-
>metadata-block
>
>> Hi Stephen,
>> This block enables us to use a standard protocol to invoke non-
>standard
>routing treatments.
>
>Right, I (think I) understand what you use it for, but I don't
>understand why you want everyone to knwo that block type 0x08
>is just to encode the presence of an unknown (to others) ontology  type
>which could easily collide with the ontology type(s) you're
>using in private.
>
>If you used block type 192 (the 1st of the private types) I
>think you'd achieve the same effect, or am I missing something?
>
>Do you know if anyone else uses this block?
>
>>>#2 Should ontologies be managed by IANA? If so, should the
>>>rule be specification required? It says "...providing the
>>>content and format have been defined and documented as
>>>part of an ontology" which'd imply a spec (or is there
>>>an ontology-police somewhere else? :-)
>> No, I don't believe that these ontologies should be managed by IANA.
>Many,
>> as I stated, will not ever be made publicly available, so such
>> registration should not be a requirement. Certainly folks could
>register
>their ontologies with IANA if desired, but it shouldn't be required.
>
>But then the ontology types might collide so again I don't
>get it.
>
>Stephen.
>
>
>
>

Date: Fri, 6 Mar 2009 09:15:34 -0800
From: Wendy Haven <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] where to stay for meeting?

--00163646c7b6c4ef590464766e2b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hello...

My name is Wendy Haven and I work for Google.  The Avante hotel
(~$200/night) is a preferred place for some of the people that visit
Mountain View from our other offices.

They seem to have availability for the week of the meetings, and they are
very close to the Plex.  They give one colleague of mine a ride to and from
work when she is here, too.  Very nice people and excellent, very
comfortable and tech-y rooms.

Feel free to contact me directly if anyone needs any further guidance, I
will do my best to help.

Wendy

On Fri, Mar 6, 2009 at 8:39 AM, Peter Lovell <[email-masked]> wrote:

> Hi Andrew,
>
> I think you'd find it much more convenient to stay somewhere close for
> the dtn meeting. Getting to the meeting from the IETF hotel will get
> your day off to a bad start :)
>
> I'm staying at the Quality Inn & Suites, 5 Fairchild Drive, Mountain
> View. The one Stephen mentioned (Residence Inn? - I forget) was already
> full except for the penthouse and that was just a tad too expensive.
>
> Cheers.....Peter
>
>
>
>
> On Fri, Mar 6, 2009, Andrew Sullivan <[email-masked]> wrote:
>
> >Hi,
> >
> >I was wondering whether most people are planning to stay in one place
> >for the DTN meeting, or are going to stay at the IETF hotel, or
> >something like that.
> >
> >Best regards,
> >
> >A
> >
> >--
> >Andrew Sullivan
> >[email-masked]
> >Shinkuro, Inc.
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 

Wendy Haven
Technical Program Manager
www.google.com
(+1) 650. 253. 7571 office
(+1) 650. 861. 1981mobile

Please consider the environment before printing, and *conserve power*
whenever possible, which is often :)

This e-mail may contain confidential and/or privileged information. If
you have received this e-mail in error please notify the sender
immediately and destroy this e-mail. Thank you.

--00163646c7b6c4ef590464766e2b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello...<br><br>My name is Wendy Haven and I work for Google.=C2=A0 The Ava=
nte hotel (~$200/night) is a preferred place for some of the people that vi=
sit Mountain View from our other offices.<br><br>They seem to have availabi=
lity for the week of the meetings, and they are very close to the Plex.=C2=
=A0 They give one colleague of mine a ride to and from work when she is her=
e, too.=C2=A0 Very nice people and excellent, very comfortable and tech-y r=
ooms.<br>
<br>Feel free to contact me directly if anyone needs any further guidance, =
I will do my best to help.<br><br>Wendy<br><br><div class=3D"gmail_quote">O=
n Fri, Mar 6, 2009 at 8:39 AM, Peter Lovell <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Andrew,<br>
<br>
I think you&#39;d find it much more convenient to stay somewhere close for<=
br>
the dtn meeting. Getting to the meeting from the IETF hotel will get<br>
your day off to a bad start :)<br>
<br>
I&#39;m staying at the Quality Inn &amp; Suites, 5 Fairchild Drive, Mountai=
n<br>
View. The one Stephen mentioned (Residence Inn? - I forget) was already<br>
full except for the penthouse and that was just a tad too expensive.<br>
<br>
Cheers.....Peter<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
<br>
On Fri, Mar 6, 2009, Andrew Sullivan &lt;<a href=3D"mailto:[email-masked]=
">[email-masked]</a>&gt; wrote:<br>
<br>
&gt;Hi,<br>
&gt;<br>
&gt;I was wondering whether most people are planning to stay in one place<b=
r>
&gt;for the DTN meeting, or are going to stay at the IETF hotel, or<br>
&gt;something like that.<br>
&gt;<br>
&gt;Best regards,<br>
&gt;<br>
&gt;A<br>
&gt;<br>
&gt;--<br>
&gt;Andrew Sullivan<br>
&gt;<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;Shinkuro, Inc.<br>
&gt;_______________________________________________<br>
&gt;dtn-interest mailing list<br>
&gt;<a href=3D"mailto:[email-masked]">dtn-intere=
[email-masked]</a><br>
&gt;<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-int=
erest" target=3D"_blank">http://maillists.intel-research.net/mailman/listin=
fo/dtn-interest</a><br>
<br>
<br>
_______________________________________________<br>
dtn-interest mailing list<br>
<a href=3D"mailto:[email-masked]">dtn-interest@m=
aillists.intel-research.net</a><br>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t" target=3D"_blank">http://maillists.intel-research.net/mailman/listinfo/d=
tn-interest</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div dir=3D=
"ltr"><span style=3D"border-collapse: collapse;"><br>Wendy Haven <br>Techni=
cal Program Manager=C2=A0 <br><a href=3D"http://www.google.com" style=3D"co=
lor: rgb(28, 81, 168);" target=3D"_blank">www.google.com</a><br>
(+1) 650. 253. 7571 office<br>(+1) 650. 861. 1981mobile<br><br>Please consi=
der the environment before printing, and *conserve power*<br>whenever possi=
ble, which is often :)<br><br>This e-mail may contain confidential and/or p=
rivileged information. If<br>
you have received this e-mail in error please notify the sender<br>immediat=
ely and destroy this e-mail. Thank you.</span><br></div><br>

--00163646c7b6c4ef590464766e2b--

From: Peter Lovell <[email-masked]>
To: Andrew Sullivan <[email-masked]>, dtn interest <[email-masked]>
Date: Fri, 06 Mar 2009 11:39:57 -0500
Subject: Re: [dtn-interest] where to stay for meeting?

Hi Andrew,

I think you'd find it much more convenient to stay somewhere close for
the dtn meeting. Getting to the meeting from the IETF hotel will get
your day off to a bad start :)

I'm staying at the Quality Inn & Suites, 5 Fairchild Drive, Mountain
View. The one Stephen mentioned (Residence Inn? - I forget) was already
full except for the penthouse and that was just a tad too expensive.

Cheers.....Peter

On Fri, Mar 6, 2009, Andrew Sullivan <[email-masked]> wrote:

>Hi,
>
>I was wondering whether most people are planning to stay in one place
>for the DTN meeting, or are going to stay at the IETF hotel, or
>something like that.
>
>Best regards,
>
>A
>
>--
>Andrew Sullivan
>[email-masked]
>Shinkuro, Inc.
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Fri, 6 Mar 2009 16:42:28 +0000
From: Stephen Farrell <[email-masked]>
To: "Susan F. Symington" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-retrans-block

--------------060505070808010708030005
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hi Susan,

The attached are my comments on this. I guess the
main one is: "#0, I think that overall this one's not
really ready as-is."

Stephen.

--------------060505070808010708030005
Content-Type: text/plain; name="retran-block-comments.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="retran-block-comments.txt"

draft-irtf-dtnrg-bundle-retrans-block-04

SF comments 20090306

#0, I think that overall this one's not really ready as-is.

#1, What's an "unauthorized bundle duplicate"? If any DTN node is allowed to
use whatever routing strategy it likes, (which I believe is the general case),
then I can't see how one can ever know that a duplicate is authorized or not,
so I have problems seeing how this block can be effective.  For example, if a
bundle traverses a set of nodes where epidemic routing is used, then some
copies of the bundle reach some gateways after which unicast routing is used,
multiple copies of the bundle are likely to arrive at a node that knows nothing
about the epidemic "region". I can't see how that can be distinguished from the
case where the same node is part of a routing loop. And I don't see how this
block helps with that since all the same things can happen with the bundle
containing this block. So I think this document is specifying something that's
only useful in some subset of DTNs (where deletion of replayed bundles is
required) and that should be made explicit in an applicability statement. The
rest of the document could then be much simpler since you could delete all
phrases like "If the security policy of the node is ..." and just get on with
specifying how to use the block.

#2, p7 and elsewhere. For this block to mitigate intentional replays, it
REQUIRES that the bundle with this block be authenticated. Otherwise the bad
actor can simply add the new block. While that does require the bad actor to
actively change the bundle, that's not that much work. Perhaps we need to think
about a different approach where information to allow replay detection/control
is added to the bundle before its first sent and not only when retransmitted by
a custodian?

#3, I think section 4 could *really* do with some ascii art.

#4, I think the document structure needs a bit of work. Its just too hard to
read right now. I'd suggest that you add an applicability statement (see #1)
that says when this block can be used then the current section 3, then the
current section 7 and move the other discussion to appendices.

#5, 7.1 1st para: that sentence just confuses me no end. It reads like the
custodian is sending a Failed custody signal to itself? 

#6, 7.1 2nd para: this means "delete the RB if the guy who put it there is not
the current custodian" right? Maybe say that 'cause the current text is very
hard to read.

#7, 7.2 Insertion attacks. If I know ahead of time that you'll emit a bundle at
time t0 and first send out a bogus bundle the rules here would seem to create a
DoS on the legitimate sendeer? (If I don't know t0, I can just send loads of
'em.)

#8, 7.3 & 7.4 seem superflous

#9 security cons: the RB can be protected with a PSB - the custodian can be a
security source for that - why not? Depending on a BAB doesn't work either,
unless every single hop requires all bundles hop-by-hop protected. 

#10 securituy cons: inserting a bundle does not require subverting a DTN node.
If I can mess at a CL or below I can do that.

#11: Shouldn't there be some consideration of the payload as well? E.g. what do
I do if the payload's changed the 2nd time I get the bundle and I still have
the 1st copy in storage? Seems like there are potential attacks here and maybe
this should really be considered together with the proposal(s?) to superseed a
an earlier version of a bundle?

Nits:

#1 The RFC editor might not like refereneces being in the abstract, (can't
remember) but probably better to move those into the body of the text

#2 Intro: I'd get rid of the tutorial material e.g. the 2nd & 3rd sentences
here and same elsewhere if there's more such.

#3. p7 s/this paper/this specification/

#4, sec cons: s/in tact/intact/

--------------060505070808010708030005--

From: Marshall Eubanks <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Mar 2009 11:32:00 -0500
Cc: [email-masked]
Subject: Re: [dtn-interest] where to stay for meeting?

On Mar 6, 2009, at 11:13 AM, Andrew Sullivan wrote:

> Hi,
>
> I was wondering whether most people are planning to stay in one place
> for the DTN meeting, or are going to stay at the IETF hotel, or
> something like that.
>

I will be up at the IETF hotel.

Regards
Marshall

> Best regards,
>
> A
>
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Fri, 6 Mar 2009 11:28:34 -0500
From: David Young <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] where to stay for meeting?

Shawn Ostermann and I are in Dinah's Garden Hotel.  We won't really be
sticking around for the IETF meeting.
The site http://down.dsg.cs.tcd.ie/dtnrg-at-google/ has the specifics
in the hotels section.

On Fri, Mar 6, 2009 at 11:13 AM, Andrew Sullivan <[email-masked]> wrote:
> Hi,
>
> I was wondering whether most people are planning to stay in one place
> for the DTN meeting, or are going to stay at the IETF hotel, or
> something like that.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
David Young

Date: Fri, 6 Mar 2009 11:13:55 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] where to stay for meeting?

Hi,

I was wondering whether most people are planning to stay in one place
for the DTN meeting, or are going to stay at the IETF hotel, or
something like that.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Date: Fri, 6 Mar 2009 13:46:21 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Loads of last calls

Folks,

We've a bunch of things being last called. I hope you'll try
read and comment on them since we really don't want everything
to be an Internet-draft forever and getting your review is
an important part of the process of making them into RFCs.

However, I realise that its a bit of a pain to send a mail
about each, particularly if all you want to say is "ok," so
I was thinking of setting up a doodle poll where people
could say yes/no/dunno more easily. (See [1] for what it
might look a bit like.)

I plan to set that up once all the last calls are
started (there's 2 more to come;-).

After the end of the last calls, I'll summarise the poll
to the list so everyone can check its ok and so its
archived.

Note that this isn't voting, its just a way to more easily
gather the set of "its ok" messages that I'm sure you'd
all otherwise eventually send. If you do have substantive
comments, then those should be mailed to the list.

Any thoughts on that? In this case, I'll take silence as
agreement and go ahead and do it once all the last calls
are started.

Stephen.

[1] http://www.doodle.com/wn4cqt5y3npqqzuc

From: Hans Kruse <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 5 Mar 2009 21:33:15 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] March 19.20 Agenda

--Apple-Mail-3-301558003
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

On Mar 5, 2009, at 5:19 PM, Ivancic, William D. (GRC-RHN0) wrote:

> Interop:  What is the status of TCPCL for ION that conforms to the =20
> DTNRG TCPCL?
There is a patch that was discussed on ion-users, but that replaces =20
the current ION TCPCL.   We (OU) are working on moving the current =20
TCPCL in ION to something we plan to call s-TCPCL (simple TCP =20
convergence layer), then implementing the DTNRG version.  We have code =20=

that is entering initial testing, stay tuned....

>
>
> DTN over IPv6:  ION does not currently support IPv6 (nor does =20
> DTN-2).  Should it?   We plan to fix DTN-2 to run on IPv6 if =20
> Viag=E9nie does not.  Viag=E9nie indicated at one point that they plan =
=20
> of fixing this.  If not, it should only take a few days according to =20=

> my coders. One thought we had was the URI representation with : for =20=

> application makes parsing the URI for IPv6 a bit difficult.  =20
> However, we believe the URI specification may indicate that the Ipv6 =20=

> address needs to be enclose in brackets with the port number (DTN =20
> Application) outside that (i.e.[IPv6 address]:ping).  Standardizing =20=

> on such a mechanism would make IPv6 implementation much easier.
The square bracket format is what firefox uses (I did not check the =20
standard, it may be in there).   I'd like to see that in all the =20
implementations (that means it will need to go into the UDP and LTP/=20
UDP code as well).

>
>
>
> /Will

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer =20
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-3-301558003
Content-Type: text/html;
	charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Mar 5, 2009, =
at 5:19 PM, Ivancic, William D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; ">Interop: &nbsp;What is the status =
of TCPCL for ION that conforms to the DTNRG =
TCPCL?</span></blockquote>There is a patch that was discussed on =
ion-users, but that replaces the current ION TCPCL. &nbsp; We (OU) are =
working on moving the current TCPCL in ION to something we plan to call =
s-TCPCL (simple TCP convergence layer), then implementing the DTNRG =
version. &nbsp;We have code that is entering initial testing, stay =
tuned....</div><div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><br><br>DTN over IPv6: &nbsp;ION =
does not currently support IPv6 (nor does DTN-2). &nbsp;Should it? =
&nbsp;&nbsp;We plan to fix DTN-2 to run on IPv6 if Viag=E9nie does not. =
&nbsp;Viag=E9nie indicated at one point that they plan of fixing this. =
&nbsp;If not, it should only take a few days according to my coders. One =
thought we had was the URI representation with : for application makes =
parsing the URI for IPv6 a bit difficult. &nbsp;However, we believe the =
URI specification may indicate that the Ipv6 address needs to be enclose =
in brackets with the port number (DTN Application) outside that =
(i.e.[IPv6 address]:ping). &nbsp;Standardizing on such a mechanism would =
make IPv6 implementation much easier.<span =
class=3D"Apple-converted-space">&nbsp;</span></span></blockquote>The =
square bracket format is what firefox uses (I did not check the =
standard, it may be in there). &nbsp; I'd like to see that in all the =
implementations (that means it will need to go into the UDP and LTP/UDP =
code as well).</div><div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; =
"><br><br><br>/Will<br></span></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> </div><br></body></html>=

--Apple-Mail-3-301558003--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 5 Mar 2009 16:19:19 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] March 19.20 Agenda

Regarding DTNbone:  We should probably discuss running some type of routing protocol - DTLSR or something.

Interop:  What is the status of TCPCL for ION that conforms to the DTNRG TCPCL?

DTN over IPv6:  ION does not currently support IPv6 (nor does DTN-2).  Should it?   We plan to fix DTN-2 to run on IPv6 if Viag�nie does not.  Viag�nie indicated at one point that they plan of fixing this.  If not, it should only take a few days according to my coders. One thought we had was the URI representation with : for application makes parsing the URI for IPv6 a bit difficult.  However, we believe the URI specification may indicate that the Ipv6 address needs to be enclose in brackets with the port number (DTN Application) outside that (i.e.[IPv6 address]:ping).  Standardizing on such a mechanism would make IPv6 implementation much easier. 

/Will

========================
Agenda

The meeting will start at 9am on the 19th.

The agenda is deliberately somewhat loose. The intent is to allow time for in-depth discussion, and hopefully resolution, of some technical issues. Those discussions will be interspersed with some talks as appropriate. Details will firm-up in the coming weeks. If you want to give a talk, or present on a particular topic, mail the chairs. Note though that we don't want to get a stream of "updates," this time, we'd like any talks to describe new things or be by new people.

   1. Intros/Agenda-bash
   2. Document/RG status
   3. Last call documents (specific issues)
   4. DTNbone progress
   5. Interop - planning more?
   6. DTN network management
   7. Endpoint identifier schemes aka DTN naming
   8. Making DTN mainstream/Report on Dagstuhl DTN II seminar

From: Hans Kruse <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Date: Thu, 5 Mar 2009 15:39:36 -0500
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-metadata-block

--Apple-Mail-11-280338720
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I am not sure I am entirely comfortable with that.   Even if they are  
not "publicly available", couldn't collisions still occur?  You use a  
number for an ontology, but your router also forwards bundles for  
another project.  If they start using the same number for their  
(different) meta-data blocks, there will be a problem.

How about specifying that a specific range of numbers requires IANA  
registration (or one could specify a range that does NOT require  
registration; depends on which case might be more common).   That  
would provide protection for implementations that need to work in an  
environment where bundles from different projects can get mixed.

On Mar 5, 2009, at 3:00 PM, Symington, Susan F. wrote:

>> #2 Should ontologies be managed by IANA? If so, should the
>> rule be specification required? It says "...providing the
>> content and format have been defined and documented as
>> part of an ontology" which'd imply a spec (or is there
>> an ontology-police somewhere else? :-)
>>
> No, I don't believe that these ontologies should be managed by IANA.  
> Many, as I stated, will not ever be made publicly available, so such  
> registration should not be a requirement. Certainly folks could  
> register their ontologies with IANA if desired, but it shouldn't be  
> required.

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-11-280338720
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I am not sure I am entirely =
comfortable with that. &nbsp; Even if they are not "publicly available", =
couldn't collisions still occur? &nbsp;You use a number for an ontology, =
but your router also forwards bundles for another project. &nbsp;If they =
start using the same number for their (different) meta-data blocks, =
there will be a problem.<div><br></div><div>How about specifying that a =
specific range of numbers requires IANA registration (or one could =
specify a range that does NOT require registration; depends on which =
case might be more common). &nbsp; That would provide protection for =
implementations that need to work in an environment where bundles from =
different projects can get mixed.</div><div><br><div><div>On Mar 5, =
2009, at 3:00 PM, Symington, Susan F. wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><blockquote type=3D"cite">#2 =
Should ontologies be managed by IANA? If so, should =
the<br></blockquote><blockquote type=3D"cite">rule be specification =
required? It says "...providing the<br></blockquote><blockquote =
type=3D"cite">content and format have been defined and documented =
as<br></blockquote><blockquote type=3D"cite">part of an ontology" =
which'd imply a spec (or is there<br></blockquote><blockquote =
type=3D"cite">an ontology-police somewhere else? =
:-)<br></blockquote><blockquote type=3D"cite"><br></blockquote>No, I =
don't believe that these ontologies should be managed by IANA. Many, as =
I stated, will not ever be made publicly available, so such registration =
should not be a requirement. Certainly folks could register their =
ontologies with IANA if desired, but it shouldn't be =
required.<br></span></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-11-280338720--

Date: Thu, 5 Mar 2009 20:37:49 -0000 (GMT)
From: [email-masked]
To: "Symington, Susan F." <[email-masked]>
Importance: Normal
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-metadata-block
Reply-To: [email-masked]

> Hi Stephen,
> This block enables us to use a standard protocol to invoke non-standard
routing treatments.

Right, I (think I) understand what you use it for, but I don't
understand why you want everyone to knwo that block type 0x08
is just to encode the presence of an unknown (to others) ontology  type
which could easily collide with the ontology type(s) you're
using in private.

If you used block type 192 (the 1st of the private types) I
think you'd achieve the same effect, or am I missing something?

Do you know if anyone else uses this block?

>>#2 Should ontologies be managed by IANA? If so, should the
>>rule be specification required? It says "...providing the
>>content and format have been defined and documented as
>>part of an ontology" which'd imply a spec (or is there
>>an ontology-police somewhere else? :-)
> No, I don't believe that these ontologies should be managed by IANA.
Many,
> as I stated, will not ever be made publicly available, so such
> registration should not be a requirement. Certainly folks could register
their ontologies with IANA if desired, but it shouldn't be required.

But then the ontology types might collide so again I don't
get it.

Stephen.

From: "Symington, Susan F." <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Thu, 5 Mar 2009 15:00:36 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-metadata-block

Hi Stephen,

This block enables us to use a standard protocol to invoke non-standard routing treatments. I don't think it would be wise to hold up this draft until there is a document that defines a type of metadata that might be used because I suspect that many of the ontologies that have been or will be defined for use with this metadata block are not intended for public release. 

As you suspect, we have defined an ontology that uses the metadata block that we use for content-based storage, retrieval, and routing of DTN bundles. The ontology consists of several different record format types and describes the processing required for each. Within this ontology, a "data tag" metadata record format is required to tag the data with information regarding its subject and source. A "search cache" record format is required to indicate the type of bundles (by subject and source) that should be searched for in a data cache. A "sent cache" record format type is required to indicate which bundles have already been retrieved and provided from previous data caches. When a DTN node receives a bundle with the metadata block, it invokes the external router and, based on the ontology indicated in the ontology field, the external router indexes in to a specific way of treating the bundle based on that ontology.  In the case of the ontology that I have just described, the behavior of the external router is dictated by the content of the specific record format that is in the metadata block. If the bundle has a "data tag" metadata item, the bundle is stored in the node's cache. If the bundle has a "search cache" metadata item, the node searches its cache for bundles with the indicated characteristics and forwards them accordingly. If the bundle has both a "search cache" and a "sent cache" metadata item, the node searches its cache for bundles with the indicated characteristics that have not already been retrieved (e.g., that are not listed in the "sent cache" metadata item) and forwards them accordingly.  That's a basic overview of the ontology which should give you an idea of what the metadata block can be used for.

We want the metadata block to be extensible so that different networks can treat it in different ways. There are lots of things it could be used for, like:
Content-based indexing, searching, and routing
Geographic point of origin marking
Geographic destination marking
Etc.
I'm not sure I'd' be comfortable specifying what it could not be used for. 

The metadata block is really a container that carries information that is further specified. We do not want to hold up specification of this container until one or more of the specific use cases are ready to progress to RFC status because it is not clear how long it would take to get public release for one of them. Instead, we'd like to get the container defined so that people can experiment with it and subsequently document successful use experiences.

Here are responses to your specific comments:
>#1 Why use SDNVs to represent ontologies? Just based on the
>name I'd have thought that maybe URIs would be better.
>
SDNVs seem sufficient. We just need a way to uniquely identify each ontology, and a number suffices.

>#2 Should ontologies be managed by IANA? If so, should the
>rule be specification required? It says "...providing the
>content and format have been defined and documented as
>part of an ontology" which'd imply a spec (or is there
>an ontology-police somewhere else? :-)
>
No, I don't believe that these ontologies should be managed by IANA. Many, as I stated, will not ever be made publicly available, so such registration should not be a requirement. Certainly folks could register their ontologies with IANA if desired, but it shouldn't be required.

>#3 It says agents "MUST be capable of:
>[...]
>     -Modifying the ontology-specific metadata in a received metadata
>      block and forwarding the modified block with the bundle
>
>   as defined in this document."
>
>But there's nothing here to say how modifications are to
>be done so I don't understand the MUST.
>
I agree that this last "MUST"" bullet can be deleted altogether. I had a specific ontology in mind when I wrote it but it isn't applicable generally so yes, I agree with you, it shouldn't be a MUST. The only MUSTs should be generating and receiving the block. Thanks.

-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: Thursday, March 05, 2009 1:12 PM
>To: Symington, Susan F.
>Cc: DTN
>Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-
>metadata-block
>
>
>Hi Susan,
>
>I've a basic question on this - what's defined here other
>than that block type 0x08 can contain a type encoded as an
>SDNV followed by a value?
>
>I guess I'm wondering whether we should hold this one until
>we have some draft or other document that defines at least
>one type of meta-data that might be used. Without that I find
>it hard to know what this is really for? (And very hard to
>know what it's not for.)
>
>The text just says:
>  "This block is designed to be used to carry metadata
>   that is associated with the bundle so that forwarding nodes can use
>   this metadata to make routing and other decisions regarding the
>   bundle."
>
>Which could be just about anything at all. I'm guessing that
>you guys have done some work here, but (after a quick look
>around) I've not found anything that uses this.
>
>Some other comments below.
>
>Stephen.
>
>#1 Why use SDNVs to represent ontologies? Just based on the
>name I'd have thought that maybe URIs would be better.
>
>#2 Should ontologies be managed by IANA? If so, should the
>rule be specification required? It says "...providing the
>content and format have been defined and documented as
>part of an ontology" which'd imply a spec (or is there
>an ontology-police somewhere else? :-)
>
>#3 It says agents "MUST be capable of:
>[...]
>     -Modifying the ontology-specific metadata in a received metadata
>      block and forwarding the modified block with the bundle
>
>   as defined in this document."
>
>But there's nothing here to say how modifications are to
>be done so I don't understand the MUST.
>

Date: Thu, 05 Mar 2009 18:54:03 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest]  RG "last call" on draft-irtf-dtnrg-cbhe

This message starts the "last call" on the Compressed
Bundle Header Encoding draft. [1]

Can you read and comment on this in the next month, i.e.
before the end of April 5th, but ideally before March
19th so we can discuss any issues when we meet.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 05 Mar 2009 18:12:00 +0000
From: Stephen Farrell <[email-masked]>
To: "Susan F. Symington" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-metadata-block

Hi Susan,

I've a basic question on this - what's defined here other
than that block type 0x08 can contain a type encoded as an
SDNV followed by a value?

I guess I'm wondering whether we should hold this one until
we have some draft or other document that defines at least
one type of meta-data that might be used. Without that I find
it hard to know what this is really for? (And very hard to
know what it's not for.)

The text just says:
  "This block is designed to be used to carry metadata
   that is associated with the bundle so that forwarding nodes can use
   this metadata to make routing and other decisions regarding the
   bundle."

Which could be just about anything at all. I'm guessing that
you guys have done some work here, but (after a quick look
around) I've not found anything that uses this.

Some other comments below.

Stephen.

#1 Why use SDNVs to represent ontologies? Just based on the
name I'd have thought that maybe URIs would be better.

#2 Should ontologies be managed by IANA? If so, should the
rule be specification required? It says "...providing the
content and format have been defined and documented as
part of an ontology" which'd imply a spec (or is there
an ontology-police somewhere else? :-)

#3 It says agents "MUST be capable of:
[...]
     -Modifying the ontology-specific metadata in a received metadata
      block and forwarding the modified block with the bundle

   as defined in this document."

But there's nothing here to say how modifications are to
be done so I don't understand the MUST.

Date: Thu, 05 Mar 2009 09:49:24 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Bundle checksum draft ready for last call

I just checked with Pete Lovell yesterday and he's planning
to get the bundle security stuff out in a few days in a
state ready for last calling. I think these two should go
together, since they both define ciphersuites, so the clock
for both should start ticking in a few days.

S.

Lloyd Wood wrote:
>>
> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-checksum-04.txt
> 
> has been posted and is ready for Last Call.
> 
> L.
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 
> 
> 

From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 4 Mar 2009 20:08:28 +0000
Cc: DTN <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: [dtn-interest] Bundle checksum draft ready for last call

>
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-checksum-04.txt

has been posted and is ready for Last Call.

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 4 Mar 2009 20:05:57 +0000
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Hidden Minneapolis meeting minutes?

What was the response?

(The proceedings pages appear unchanged.)

On 17 Feb 2009, at 18:50, Stephen Farrell wrote:

> I've asked. We'll see.
> S.
>
> Lloyd Wood wrote:
>> The Minneapolis DTNRG meeting slides at:
>> http://www.ietf.org/proceedings/08nov/agenda/DTNRG.html
>> are not linked to directly from the main meeting proceedings page  
>> and frameset:
>> http://www.ietf.org/proceedings/08nov/
>> possibly because meeting minutes aren't included?
>>
>> The slides are a little difficult to find. Can this be corrected?
>>
>> thanks,
>>
>> L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 4 Mar 2009 20:02:25 +0000
Cc: DTN <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-previous-hop-block

On 4 Mar 2009, at 11:20, Stephen Farrell wrote:
 > From the tone of Lloyd's message (and the history) I at least
> assume that he's just trolling,

Hardly.

http://www.dtnrg.org/wiki/Docs

2009

Lloyd Wood, Wes Eddy and Peter Holliday, A Bundle of Problems, IEEE  
Aerospace Conference, Big Sky, Montana, March 2009 (15 pages).

http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#bundle-problems

Many of these documented problems that are seemingly new to you - such  
as problems with clocks or reliability - are design issues we've  
raised before (mostly unsuccessfully) in this forum. Trolling? Really?

Again, the problems aren't with this block draft. The problems are  
more fundamental, and with the bundle protocol itself.

I strongly encourage you to read and understand this paper.

L.

> so I hope folks don't take his
> bait, but rather discuss the draft in question in a sensible
> manner.
>
> Stephen.
>
> Lloyd Wood wrote:
>> On 4 Mar 2009, at 10:24, Stephen Farrell wrote:
>>> Sorry if these've come up before and I wasn't paying attention.
>> [..]
>>
>>> Stephen.
>>>
>>> SF comments on draft-irtf-dtnrg-bundle-previous-hop-block-05
>>
>>>
>>>
>>> #2 If a bundle with this is sent to a node that doesn't implement  
>>> this
>>> block
>>> then it'll delete the block before forwarding. However, the  
>>> dictionary
>>> in that
>>> forwarded bundle will still contain any EIDs inserted for this  
>>> block,
>>> thus
>>> breaking e2e integrity. Wouldn't it be better for this block to not
>>> use the
>>> dictionary to avoid this problem?
>>
>> breaking e2e integrity was a deliberate design choice for the bundle
>> protocol.
>> This appears to be a basic problem with the design of the  
>> dictionary and
>> extensible blocks in the bundle protocol.
>>
>>> #8 What if the forwarder has no clock?
>>
>> not considering problems with clocks was a deliberate design choice
>> bundle protocol.
>> This appears to be a basic problem with design of time handling in  
>> the
>> bundle protocol.
>>
>> Good that you're recognizing these basic problems, at least - but I
>> don't think that the previous hop block draft can take the blame  
>> for the
>> constraints placed on it by the design it has to work within.
>>
>> cheers,
>>
>> L.
>>
>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>>
>> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>
>>
>>
>>
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

Content-class: urn:content-classes:message
Date: Wed, 4 Mar 2009 16:38:43 -0000
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re(2): Re(2): RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99CE7.DC4E8275
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

But if you can't trust the dictionary, what can you trust?

> If a bit changes in a bundle and there's no check to notice, did it
> really change?

If the bit is evaluated as payload or affects a protocol state machine,
it changed. Otherwise it's called 'padding'.

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

-----Original Message-----
From: Peter Lovell [mailto:[email-masked]]
Sent: Wed 2009-03-04 16:05
To: Wood L Dr (Electronic Eng)
Cc: DTN
Subject: Re(2): [dtn-interest] Re(2): RG "last call" on =
draft-irtf-dtnrg-bundle-previous-hop-block
=20
On Wed, Mar 4, 2009, Lloyd Wood <[email-masked]> wrote:

>If mutable canonicalization doesn't cover it, e2e integrity is lost =20
>anyway.
>
>Catch-22.

True, but what if I don't care?=20

There may be changes made in various places but if they don't compromise
what I consider important, what does it matter?

If a bit changes in a bundle and there's no check to notice, did it
really change?

Cheers.....Peter

------_=_NextPart_001_01C99CE7.DC4E8275
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: Re(2): [dtn-interest] Re(2): RG &quot;last call&quot; on =
draft-irtf-dtnrg-bundle-previous-hop-block</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>But if you can't trust the dictionary, what can you =
trust?<BR>
<BR>
&gt; If a bit changes in a bundle and there's no check to notice, did =
it<BR>
&gt; really change?<BR>
<BR>
If the bit is evaluated as payload or affects a protocol state =
machine,<BR>
it changed. Otherwise it's called 'padding'.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Peter Lovell [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Wed 2009-03-04 16:05<BR>
To: Wood L Dr (Electronic Eng)<BR>
Cc: DTN<BR>
Subject: Re(2): [dtn-interest] Re(2): RG &quot;last call&quot; on =
draft-irtf-dtnrg-bundle-previous-hop-block<BR>
<BR>
On Wed, Mar 4, 2009, Lloyd Wood &lt;[email-masked]&gt; wrote:<BR>
<BR>
&gt;If mutable canonicalization doesn't cover it, e2e integrity is =
lost&nbsp;<BR>
&gt;anyway.<BR>
&gt;<BR>
&gt;Catch-22.<BR>
<BR>
True, but what if I don't care?<BR>
<BR>
There may be changes made in various places but if they don't =
compromise<BR>
what I consider important, what does it matter?<BR>
<BR>
If a bit changes in a bundle and there's no check to notice, did it<BR>
really change?<BR>
<BR>
Cheers.....Peter<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C99CE7.DC4E8275--

From: Peter Lovell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Wed, 04 Mar 2009 11:05:50 -0500
Cc: DTN <[email-masked]>
Subject: [dtn-interest] Re(2): Re(2): RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

On Wed, Mar 4, 2009, Lloyd Wood <[email-masked]> wrote:

>If mutable canonicalization doesn't cover it, e2e integrity is lost  
>anyway.
>
>Catch-22.

True, but what if I don't care? 

There may be changes made in various places but if they don't compromise
what I consider important, what does it matter?

If a bit changes in a bundle and there's no check to notice, did it
really change?

Cheers.....Peter

From: Lloyd Wood <[email-masked]>
To: Peter Lovell <[email-masked]>
Date: Wed, 4 Mar 2009 15:39:56 +0000
Cc: DTN <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Re(2): RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

If mutable canonicalization doesn't cover it, e2e integrity is lost  
anyway.

Catch-22.

On 4 Mar 2009, at 13:36, Peter Lovell wrote:

> On Wed, Mar 4, 2009, Stephen Farrell <[email-masked]>  
> wrote:
>
>> #2 If a bundle with this is sent to a node that doesn't implement  
>> this block
>> then it'll delete the block before forwarding. However, the  
>> dictionary
> in that
>> forwarded bundle will still contain any EIDs inserted for this  
>> block, thus
>> breaking e2e integrity.
>
> Hi Stephen,
>
> I don't understand the breakage. Mutable canonicalization (the
> "standard" form in the spec) doesn't digest the whole dictionary, and
> shouldn't care whether a general EID entry is there or not. It only
> cares about source, destination and report-to.
>
> I guess I misunderstand.
>
> Cheers.....Peter
>

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 04 Mar 2009 10:34:38 -0500
Cc: DTN <[email-masked]>
Subject: [dtn-interest] Re(2): RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

On Wed, Mar 4, 2009, Stephen Farrell <[email-masked]> wrote:

>
>
>Peter Lovell wrote:
>> On Wed, Mar 4, 2009, Stephen Farrell <[email-masked]> wrote:
>> 
>>> #2 If a bundle with this is sent to a node that doesn't implement
>this block
>>> then it'll delete the block before forwarding. However, the dictionary
>> in that
>>> forwarded bundle will still contain any EIDs inserted for this block, thus
>>> breaking e2e integrity.
>> 
>> Hi Stephen,
>> 
>> I don't understand the breakage. Mutable canonicalization (the
>> "standard" form in the spec) doesn't digest the whole dictionary, and
>> shouldn't care whether a general EID entry is there or not. It only
>> cares about source, destination and report-to.
>> 
>> I guess I misunderstand.
>
>Nope. Looks like its me that got that wrong I guess.
>
>Good that we got the mutable c14n stuff right, eh;-)
>
>S.

Hi Stephen,

well, in a way. I understand the desire to protect the envelope but
don't think this is the right way.

My preference would be to have PIB protect the payload, and just the
payload (treating already-present payload-securing blocks as a part of
the payload). We'd then protect the header separately, probably
including the PIB.

Doing it this way has several advantages. First is that the original
signature applies even when the payload is forwarded etc. So you can
have the originator's attestation of accuracy even after passing through
several resends etc. The second is that you can have a different key to
protect the header stuff, possibly one that is less tightly controlled
than the sender's keys. I know of a number of applications that might
find this an attractive scenario.

Of course, it's perfectly possible to do this with a variation of the
current mutable canonicalization in a new ciphersuite. I just wish we'd
make it the default.

Cheers.....Peter

Date: Wed, 04 Mar 2009 15:03:48 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

Peter Lovell wrote:
> On Wed, Mar 4, 2009, Stephen Farrell <[email-masked]> wrote:
> 
>> #2 If a bundle with this is sent to a node that doesn't implement this block
>> then it'll delete the block before forwarding. However, the dictionary
> in that
>> forwarded bundle will still contain any EIDs inserted for this block, thus
>> breaking e2e integrity.
> 
> Hi Stephen,
> 
> I don't understand the breakage. Mutable canonicalization (the
> "standard" form in the spec) doesn't digest the whole dictionary, and
> shouldn't care whether a general EID entry is there or not. It only
> cares about source, destination and report-to.
> 
> I guess I misunderstand.

Nope. Looks like its me that got that wrong I guess.

Good that we got the mutable c14n stuff right, eh;-)

S.

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Wed, 04 Mar 2009 08:36:03 -0500
Subject: [dtn-interest] Re(2): RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

On Wed, Mar 4, 2009, Stephen Farrell <[email-masked]> wrote:

>#2 If a bundle with this is sent to a node that doesn't implement this block
>then it'll delete the block before forwarding. However, the dictionary
in that
>forwarded bundle will still contain any EIDs inserted for this block, thus
>breaking e2e integrity.

Hi Stephen,

I don't understand the breakage. Mutable canonicalization (the
"standard" form in the spec) doesn't digest the whole dictionary, and
shouldn't care whether a general EID entry is there or not. It only
cares about source, destination and report-to.

I guess I misunderstand.

Cheers.....Peter

Date: Wed, 04 Mar 2009 11:20:10 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-previous-hop-block

>From the tone of Lloyd's message (and the history) I at least
assume that he's just trolling, so I hope folks don't take his
bait, but rather discuss the draft in question in a sensible
manner.

Stephen.

Lloyd Wood wrote:
> On 4 Mar 2009, at 10:24, Stephen Farrell wrote:
>> Sorry if these've come up before and I wasn't paying attention.
> [..]
> 
>> Stephen.
>>
>> SF comments on draft-irtf-dtnrg-bundle-previous-hop-block-05
> 
>>
>>
>> #2 If a bundle with this is sent to a node that doesn't implement this
>> block
>> then it'll delete the block before forwarding. However, the dictionary
>> in that
>> forwarded bundle will still contain any EIDs inserted for this block,
>> thus
>> breaking e2e integrity. Wouldn't it be better for this block to not
>> use the
>> dictionary to avoid this problem?
> 
> breaking e2e integrity was a deliberate design choice for the bundle
> protocol.
> This appears to be a basic problem with the design of the dictionary and
> extensible blocks in the bundle protocol.
> 
>> #8 What if the forwarder has no clock?
> 
> not considering problems with clocks was a deliberate design choice
> bundle protocol.
> This appears to be a basic problem with design of time handling in the
> bundle protocol.
> 
> Good that you're recognizing these basic problems, at least - but I
> don't think that the previous hop block draft can take the blame for the
> constraints placed on it by the design it has to work within.
> 
> cheers,
> 
> L.
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 
> 
> 

From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 4 Mar 2009 11:02:08 +0000
Cc: DTN <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-previous-hop-block

On 4 Mar 2009, at 10:24, Stephen Farrell wrote:
> Sorry if these've come up before and I wasn't paying attention.
[..]

> Stephen.
>
> SF comments on draft-irtf-dtnrg-bundle-previous-hop-block-05

>
>
> #2 If a bundle with this is sent to a node that doesn't implement  
> this block
> then it'll delete the block before forwarding. However, the  
> dictionary in that
> forwarded bundle will still contain any EIDs inserted for this  
> block, thus
> breaking e2e integrity. Wouldn't it be better for this block to not  
> use the
> dictionary to avoid this problem?

breaking e2e integrity was a deliberate design choice for the bundle  
protocol.
This appears to be a basic problem with the design of the dictionary and
extensible blocks in the bundle protocol.

> #8 What if the forwarder has no clock?

not considering problems with clocks was a deliberate design choice  
bundle protocol.
This appears to be a basic problem with design of time handling in the  
bundle protocol.

Good that you're recognizing these basic problems, at least - but I  
don't think that the previous hop block draft can take the blame for  
the constraints placed on it by the design it has to work within.

cheers,

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

Date: Wed, 04 Mar 2009 10:24:45 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG "last call" on	draft-irtf-dtnrg-bundle-previous-hop-block

This is a multi-part message in MIME format.
--------------010309030706090204040402
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I have a few issues with this one that I think might warrant
discussion (attached).

Sorry if these've come up before and I wasn't paying attention.

Stephen.

--------------010309030706090204040402
Content-Type: text/plain;
 name="prev-hop-commments.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="prev-hop-commments.txt"

SF comments on draft-irtf-dtnrg-bundle-previous-hop-block-05

20090304

#1 IANA stuff.  Given that we'll probably want a block type registry, why make
this one exensible as well? I think I'd prefer that we not make this extensible
even though there're only 8 bits for block types. I guess I'm wondering why all
values added for single-hop purposes should use this block type, which seems to
be implied by the current scheme.

#2 If a bundle with this is sent to a node that doesn't implement this block
then it'll delete the block before forwarding. However, the dictionary in that
forwarded bundle will still contain any EIDs inserted for this block, thus
breaking e2e integrity. Wouldn't it be better for this block to not use the
dictionary to avoid this problem?

#3 The timestamp seems ambiguous - is it the time at which the bundle departs
the forwarder? Why not allow adding the time of arrival as well? 

#4 Is there really a use-case for the EID-only version of this? If not, or if
its a corner case, then changing this to make the timestamp (or two, see #2)
mandatory would be simpler.

#5 The timestamp has a 1second granularity, but in the BP we have a sequence
value as well to distinguish bundles sent in the same second. Suggest copying
that here too or (maybe better) having a timstamp that allows microseconds as
well.

#6 Given the 1s granularity and that the timestamp is an offset from the bundle
creation time, the text should give guidance on rounding up or down.

#7 Making the timestamp an offset means that if we define a way for
timeless-nodes to use the BP (e.g. with a "special" time value and some other
block/flag) then this offset scheme might be affected. If this timestamp were
the wall-clock time of the forwarder then the dependency wouldn't arise. 

#8 What if the forwarder has no clock?

#9 Why would a bundle ever have >1 of these blocks? (As is allowed by 3.1)

#10 Security considerations: what if the forwarder lies about its EID or the
time? This block could provide a nice way to subvert routing strategies, e.g.
to create a DoS against the EID named as the forwarder, if the receiver uses
that to decide to route bundles via that EID. There may be other security
issues as well but I think receivers should be warned to think about this.

#11 Security considerations: "If encryption of this block is desired..."
Another alternative would be to encapsulate which is probably worth a mention.

#12 If a BP implementation doesn't properly implement the "Discard block if it
can't be processed" then this block will persist unexpectedly.  Dunno if that's
a risk worth a mention in the sec. cons. section or not?  (If there are BP
implementations out there that don't do block discarding right, or at all, then
I suspect it should be mentioned.)

Nits:

#1 Intro says that the two formats are "mandatory" which is odd - presumably
that's mandatory-to-implement (if supporting this spec)?

#2 I think the text could be shortened, its a bit wordy.

--------------010309030706090204040402--

From: Hans Kruse <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>,  [email-masked], [email-masked]
Date: Tue, 3 Mar 2009 11:26:01 -0500
Subject: [dtn-interest] dtnbone web site

--Apple-Mail-9-92323690
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

As agreed at the last dtnrg meeting, I have assembled a wiki page for  
information of publicly accessible DTN nodes, the "dtnbone".   Thanks  
go to Stephen Farrell and Kevin Fall for allowing this to be hosted on  
the official dtnrg site.

Start at the main dtnrg page, http://www.dtnrg.org -- the link to the  
dtnbone page is near the bottom.  This is a wiki; you can register a  
login and request edit access if you are willing to help with updating  
the site.  Otherwise, please send me new or updated information, and I  
can make the changes.

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-9-92323690
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>As agreed at the last =
dtnrg meeting, I have assembled a wiki page for information of publicly =
accessible DTN nodes, the "dtnbone". &nbsp; Thanks go to Stephen Farrell =
and Kevin Fall for allowing this to be hosted on the official dtnrg =
site.</div><div><br></div><div>Start at the main dtnrg page, <a =
href=3D"http://www.dtnrg.org">http://www.dtnrg.org</a> -- the link to =
the dtnbone page is near the bottom. &nbsp;This is a wiki; you can =
register a login and request edit access if you are willing to help with =
updating the site. &nbsp;Otherwise, please send me new or updated =
information, and I can make the changes.</div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> </div><br></body></html>=

--Apple-Mail-9-92323690--

Date: Tue, 3 Mar 2009 13:27:20 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-retrans-block

This message starts the "last call" on the Retransmission
Block draft. [1]

Can you read and comment on this in the next month, i.e.
before the end of April 3rd, but ideally before March
19th so we can discuss any issues when we meet.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-retrans-block

Date: Tue, 3 Mar 2009 13:32:47 +0000
From: Stephen Farrell <[email-masked]>
To: Daniel Ellard <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] schedule for the DTNRG GooglePlex meetings?

I think we'd like to start at 9am on the 19th and go
until about 6pm.

On the 20th we can start at 9am again but have to
finish early (~3pm) as there's another event in the
venue that evening.

Stephen.

PS: I've not gotten many requests for slots. If you'd like
one, please mail Kevin and I. (If you asked ages ago, please
send a repeat - my filing system is imperfect:-)

Daniel Ellard wrote:
> I need to make my travel plans: what time are things going to start on
> 3/19, and what time are things going to wind down on 3/20?
> 
> Thanks,
> 	-Dan
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 3 Mar 2009 13:27:10 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-metadata-block

This message starts the "last call" on the Metadata
Extension Block draft. [1]

Can you read and comment on this in the next month, i.e.
before the end of April 3rd, but ideally before March
19th so we can discuss any issues when we meet.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-metadata-block

Date: Tue, 3 Mar 2009 13:27:05 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-previous-hop-block

(Susan Symmington reckons that three of her documents
are ready for RG "last call". I'll start separate threads
for each.)

This message starts the "last call" on the Previous Hop
Insertion Block draft. [1]

Can you read and comment on this in the next month, i.e.
before the end of April 3rd, but ideally before March
19th so we can discuss any issues when we meet.

Please bear in mind that as an IRTF RG, and not an
IETF WG, we do not need to establish rough consensus
for documents, but if we do have that its a good thing.
For the later stages of review, it's useful if folks have
said "I agree, its ok and its ready" or equivalent so
please do send a mail to the list saying that if it
applies. (Preserving the subject line so we can just
add a link in the tracker later.)

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-previous-hop-block

Date: Mon, 02 Mar 2009 14:04:32 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] schedule for the DTNRG GooglePlex meetings?

I need to make my travel plans: what time are things going to start on
3/19, and what time are things going to wind down on 3/20?

Thanks,
	-Dan

From: Marshall Eubanks <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 2 Mar 2009 13:58:06 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG GooglePlex meetings

On Mar 2, 2009, at 1:06 PM, Stephen Farrell wrote:

>
>
> Marshall Eubanks wrote:
>>
>> On Mar 2, 2009, at 12:50 PM, Stephen Farrell wrote:
>>
>>>
>>> Hi Will,
>>>
>>> I've passed on the request. Will get back when I find out.
>>>
>>> OTOH, I have to say that I'm not that sure that that kind
>>> of remote participation over two full days is very useful.
>>> If someone wants to step-up to say they'll do the work
>>> required (which, going by IETF meetings, is significant),
>>> then let Kevin & I know.
>>
>> It can be very useful, if available and if used.
>>
>> The Secretariat might be able to provide assistance if they are  
>> asked in
>> good time.
>
> This is for the meeting the week before the IETF (on March 19/20)
> so the IETF secretariat aren't in the picture.

I know when the meeting is, but the Secretariat could still (maybe)  
help with things like Webex support.
They are, of course, rather busy at present.

As things move forward, I think that remote participation will become  
ever more necessary, and
the Secretariat is going to have to help provide it.

Marshall

>
>
>> The crucial question is, are there people that would use it ?
>
> Two so far, for part(s) of the agenda,
> S.
>
>
>>
>> Regards
>> Marshall
>>
>>
>>>
>>>
>>> Anyway, we'll see.
>>> S.
>>>
>>>
>>> Ivancic, William D. (GRC-RHN0) wrote:
>>>> Stephen or Kevin,
>>>>
>>>> Do you know if there will there be any remote access either via Web
>>>> or audio conferencing or both?  I plan to be there, but everyone  
>>>> from
>>>> my group cannot afford to travel.
>>>>
>>>> Will
>>>>
>>>> ******************************
>>>> William D. Ivancic
>>>> Phone 216-433-3494
>>>> Fax 216-433-8705
>>>> Networking Lab 216-433-2620
>>>> DTN Lab 216-433-2981
>>>> Mobile 440-503-4892
>>>> http://roland.grc.nasa.gov/~ivancic
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, Marshall Eubanks <[email-masked]>
Date: Mon, 2 Mar 2009 12:41:48 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG GooglePlex meetings

If there is a speaker phone, I can provide a teleconference number - toll free in US only.

I also have a standing Webex account and can set that up if useful.

I agree, the entire two days is probably not warranted, but perhaps certain agenda items and if those can be grouped.

Perhaps we can ask the list who might participate via remote if we provide it and what portions of the agenda are of interest.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]] 
> Sent: Monday, March 02, 2009 1:07 PM
> To: Marshall Eubanks
> Cc: Ivancic, William D. (GRC-RHN0); [email-masked]
> Subject: Re: [dtn-interest] DTNRG GooglePlex meetings
> 
> 
> 
> Marshall Eubanks wrote:
> > 
> > On Mar 2, 2009, at 12:50 PM, Stephen Farrell wrote:
> > 
> >>
> >> Hi Will,
> >>
> >> I've passed on the request. Will get back when I find out.
> >>
> >> OTOH, I have to say that I'm not that sure that that kind 
> of remote 
> >> participation over two full days is very useful.
> >> If someone wants to step-up to say they'll do the work required 
> >> (which, going by IETF meetings, is significant), then let 
> Kevin & I 
> >> know.
> > 
> > It can be very useful, if available and if used.
> > 
> > The Secretariat might be able to provide assistance if they 
> are asked 
> > in good time.
> 
> This is for the meeting the week before the IETF (on March 
> 19/20) so the IETF secretariat aren't in the picture.
> 
> > The crucial question is, are there people that would use it ?
> 
> Two so far, for part(s) of the agenda,
> S.
> 
> 
> > 
> > Regards
> > Marshall
> > 
> > 
> >>
> >>
> >> Anyway, we'll see.
> >> S.
> >>
> >>
> >> Ivancic, William D. (GRC-RHN0) wrote:
> >>> Stephen or Kevin,
> >>>
> >>> Do you know if there will there be any remote access 
> either via Web 
> >>> or audio conferencing or both?  I plan to be there, but everyone 
> >>> from my group cannot afford to travel.
> >>>
> >>> Will
> >>>
> >>> ******************************
> >>> William D. Ivancic
> >>> Phone 216-433-3494
> >>> Fax 216-433-8705
> >>> Networking Lab 216-433-2620
> >>> DTN Lab 216-433-2981
> >>> Mobile 440-503-4892
> >>> http://roland.grc.nasa.gov/~ivancic
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> > 
> > 
> 

Date: Mon, 02 Mar 2009 18:06:32 +0000
From: Stephen Farrell <[email-masked]>
To: Marshall Eubanks <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG GooglePlex meetings

Marshall Eubanks wrote:
> 
> On Mar 2, 2009, at 12:50 PM, Stephen Farrell wrote:
> 
>>
>> Hi Will,
>>
>> I've passed on the request. Will get back when I find out.
>>
>> OTOH, I have to say that I'm not that sure that that kind
>> of remote participation over two full days is very useful.
>> If someone wants to step-up to say they'll do the work
>> required (which, going by IETF meetings, is significant),
>> then let Kevin & I know.
> 
> It can be very useful, if available and if used.
> 
> The Secretariat might be able to provide assistance if they are asked in
> good time.

This is for the meeting the week before the IETF (on March 19/20)
so the IETF secretariat aren't in the picture.

> The crucial question is, are there people that would use it ?

Two so far, for part(s) of the agenda,
S.

> 
> Regards
> Marshall
> 
> 
>>
>>
>> Anyway, we'll see.
>> S.
>>
>>
>> Ivancic, William D. (GRC-RHN0) wrote:
>>> Stephen or Kevin,
>>>
>>> Do you know if there will there be any remote access either via Web
>>> or audio conferencing or both?  I plan to be there, but everyone from
>>> my group cannot afford to travel.
>>>
>>> Will
>>>
>>> ******************************
>>> William D. Ivancic
>>> Phone 216-433-3494
>>> Fax 216-433-8705
>>> Networking Lab 216-433-2620
>>> DTN Lab 216-433-2981
>>> Mobile 440-503-4892
>>> http://roland.grc.nasa.gov/~ivancic
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> 

From: Marshall Eubanks <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 2 Mar 2009 12:58:51 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG GooglePlex meetings

On Mar 2, 2009, at 12:50 PM, Stephen Farrell wrote:

>
> Hi Will,
>
> I've passed on the request. Will get back when I find out.
>
> OTOH, I have to say that I'm not that sure that that kind
> of remote participation over two full days is very useful.
> If someone wants to step-up to say they'll do the work
> required (which, going by IETF meetings, is significant),
> then let Kevin & I know.

It can be very useful, if available and if used.

The Secretariat might be able to provide assistance if they are asked  
in good time.

The crucial question is, are there people that would use it ?

Regards
Marshall

>
>
> Anyway, we'll see.
> S.
>
>
> Ivancic, William D. (GRC-RHN0) wrote:
>> Stephen or Kevin,
>>
>> Do you know if there will there be any remote access either via Web  
>> or audio conferencing or both?  I plan to be there, but everyone  
>> from my group cannot afford to travel.
>>
>> Will
>>
>> ******************************
>> William D. Ivancic
>> Phone 216-433-3494
>> Fax 216-433-8705
>> Networking Lab 216-433-2620
>> DTN Lab 216-433-2981
>> Mobile 440-503-4892
>> http://roland.grc.nasa.gov/~ivancic
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 02 Mar 2009 17:50:46 +0000
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG GooglePlex meetings

Hi Will,

I've passed on the request. Will get back when I find out.

OTOH, I have to say that I'm not that sure that that kind
of remote participation over two full days is very useful.
If someone wants to step-up to say they'll do the work
required (which, going by IETF meetings, is significant),
then let Kevin & I know.

Anyway, we'll see.
S.

Ivancic, William D. (GRC-RHN0) wrote:
> Stephen or Kevin,
> 
> Do you know if there will there be any remote access either via Web or audio conferencing or both?  I plan to be there, but everyone from my group cannot afford to travel.
> 
> Will
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic 

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Fall, Kevin" <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Mon, 2 Mar 2009 11:01:59 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] DTNRG GooglePlex meetings

Stephen or Kevin,

Do you know if there will there be any remote access either via Web or audio conferencing or both?  I plan to be there, but everyone from my group cannot afford to travel.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

Date: Sun, 01 Mar 2009 05:13:35 -0500
From: "Omar Y. Tahboub" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] The First International Workshop on Concurrent Communication (ConCom 2009) Paper Submission Deadline is Extended

This is a multi-part message in MIME format.
--------------040503040400080008080005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Colleagues,

  I'd like to inform you that the paper submission deadline for ConCom 
2009 has been extended to March, 10th, 2009. The updated call for paper 
is enclosed with this message.

Best Regards,

  Omar.

--------------040503040400080008080005
Content-Type: application/pdf;
 name="ConCom2009.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="ConCom2009.pdf"

--------------040503040400080008080005--