Subject: [dtn-interest] Six drafts approved by IESG
From: Elwyn Davies <[email-masked]>
To: DTN <[email-masked]>
Date: Thu, 17 Feb 2011 21:41:12 +0000
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

Excellent news!

The IESG has approved the six drafts that were on today's agenda on the 
basis that they do not conflict with any IETF work.

Thanks to everybody for their hard work on these.
Several of them are ready to go to the RFC Editor immediately but we got 
a small number of comments from the ADs that  we should consider 
incorporating into the drafts before publication... so we may have just 
a little more to do on those (need to do on CBHE).

The drafts and the comments/situations are:

Tne Bundle Security protocol: 
http://datatracker.ietf.org/doc/draft-irtf-dtnrg-bundle-security
[Nits from Sean Turner: 
http://maillists.intel-research.net/pipermail/dtn-interest/2011-February/004992.html]

Using Self-Delimiting Numeric Values in Protocols
http://datatracker.ietf.org/doc/draft-irtf-dtnrg-sdnv
[Couple of minor nits - The Web Socket Protocol no longer uses SDNVs - 
need to remove the reference.  Also maybe improve later suggestion on 
best usage of SDNVs.]

Delay-Tolerant Networking Metadata Extension 
Blockhttp://datatracker.ietf.org/doc/draft-irtf-dtnrg-bundle-metadata-block
[Couple of minor comments from Peter St Andre.  See datatracker.]

Delay-Tolerant Networking Previous Hop Insertion Block
http://datatracker.ietf.org/doc/draft-irtf-dtnrg-bundle-previous-hop-block
[Good to go!]

Compressed Bundle Header Encoding (CBHE)
http://datatracker.ietf.org/doc/draft-irtf-dtnrg-cbhe
[Needs some improvements to formal registration request for ipn: URI scheme.
Still awaiting formal review/approval from Graham Klyne (appointed 
expert reviewer.)]

Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries
http://datatracker.ietf.org/doc/draft-irtf-dtnrg-iana-bp-registries
[Good to go.  Comments from Jari Arkko have been resolved.]

Let's try and get these wrapped up asap.

Regards,
Elwyn

Date: Thu, 17 Feb 2011 21:24:34 +0000
From: Elwyn Davies <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] [Fwd: Fwd: Nits on draft-irtf-dtnrg-bundle-security]
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------000602010102030909030309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Comments received during IESG review

--------------000602010102030909030309
Content-Type: message/rfc822;
	name="Fwd: Nits on draft-irtf-dtnrg-bundle-security.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename="Fwd: Nits on draft-irtf-dtnrg-bundle-security.eml"

Delivery-date: Sat, 29 Jan 2011 22:28:32 +0000
Date: Sat, 29 Jan 2011 17:28:27 -0500
From: Sean Turner <[email-masked]>
To: [email-masked], [email-masked]
Subject: Fwd: Nits on draft-irtf-dtnrg-bundle-security

Aaron and Elwyn,

I should have cced you on this.  That'll teach me to not read the 
history before I send these out.

spt

-------- Original Message --------
Subject: Nits on draft-irtf-dtnrg-bundle-security
Date: Sat, 29 Jan 2011 17:23:28 -0500
From: Sean Turner <[email-masked]>
To: [email-masked]
CC: [email-masked], The IESG <[email-masked]>

Hi,

Here's some comments/questions I have on this document (note this isn't
my RFC 5742 review):

- No 'Intended status' indicated for this document; I'm assuming
Experimental as per the datatracker.  I think you should probably add
the header line to make sure though.

- There are two unused references: RFC 3370 and RFC 4106.

I think 3370 could we worked in somewhere when describing the CMS bits.

For the 4106 I think the checker is barfing on the following from
Section 4.3 and 4.4:

[Note: parts of the following description are borrowed from RFC 4106].

Maybe replace it with:

Note: parts of the following description is borrowed from [RFC4106].

- Obsolete reference to [RFC3280].  Should be to [RFC5280].

- Couldn't find the [DTNRB] reference.  Did the document die a graceful
death?

- Expand DTN, EID, SDNV, BA, and PI on first use

- Authentication is mentioned for the first time in Sec 2 when
discussing the PIB.  Wouldn't it be better to mention it earlier?

- Section 2.1: When describing the two EIDs and cipher suite flags as
"(optional)" they should be "(OPTIONAL)" if conveying 2119 requirements.
  Same for the Figure 3 description (i.e., the paragraph before the figure).

- Section 2.3: r/the key information item Section 2.6 is optional, and
if not provided then the key should be/the key information item Section
2.6 is OPTIONAL, and if not provided then the key SHOULD be

- Sections 2.4 & 2.5: r/and that encryption-only ciphersuites NOT be
used/and it is NOT RECOMMENDED that encryption-only ciphersuites be used
Using NOT so far after the RECOMMENDED isn't "NOT RECOMMENDED".  Also if
you do this need to add "NOT RECOMMENDED" to the first para in section 1
like the errata 499:
http://www.rfc-editor.org/errata_search.php?rfc=2119

- Section 2.4: Some "SHOULDs":

    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.

- Section 2.4: "SHOULD NOT" instead of "should not":

    These multiple PCB instances, are
    not "related" and SHOULD NOT contain correlators.
                      ^^^^^^^^^^

- Section 2.8: In the paragraph about authenticated and encrypted
bundles, I think the last sentence should be "RECOMMENDED".  It's
interesting to note that you'd prefer encrypt then sign as opposed to
sign and then encrypt.  Looking forward to the security consideration
about why.

- Section 3.2: r/MUST not/MUST NOT ?

- Section 3.2: r/No other blocks are
    required to follow the payload block and it is RECOMMENDED that they
    NOT do so./No other blocks are
    required to follow the payload block and it is NOT RECOMMENDED
    that they do so.

- Section 3.4.2: r/This algorithm is intended to protect parts of the
bundle which should not be changed in-transit./This algorithm is
intended to protect parts of the bundle which SHOULD NOT be changed
in-transit.

- Sections 3.4.1 & 3.4.2: Need a reference for URI.

- Sections 4.1-4.4: What's the OIDs for these "eContents"?  I assume
id-data, but you should probably be explicit about it.

- Section 4.1: r/Security parameters are optional with this
scheme/Security parameters are OPTIONAL with this scheme

- Section 4.1: A couple of comments/questions on the following:

    Implementations MUST support use of "AuthenticatedData" type as
    defined in [RFC5652] section 9.1, with RecipientInfo type
    KeyTransRecipientInfo containing the issuer and serial number of a
    suitable certificate.  They MAY support additional RecipientInfo
    types.  They MAY additionally use the "SignedData" type described in
    [RFC5652] Section 5.1.  In either case, the "eContent" field in
    EncapsulatedContentInfo contains the encrypted HMAC key.

1. Normally, we'd use the SKI instead of the issuer/serial # combo.  Any
reason you chose differently?  Most certificates have SKIs (now) and
it's probably smaller than the issuer/serial # combo.

2. How is SignedData used here?  It says it MAY be used - is that in
addition to?  There's no RecipientInfo with SignedData so I am a little
confused.

- Section 4.1 and 4.2: Should probably say something about whether you'd
recommend no unsigned/unauthenticated and signed/authenticated
attributes.  I'm assuming you're not recommending any ;)

- Sections 4.2, 4.3, & 4.4: Normally, we'd use the SKI instead of the
issuer/serial # combo.  Any reason you chose differently?  Most
certificates have SKIs and it's probably smaller than the issuer/serial
# combo.

- Section 4.2: Had the following:

   RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
   signature scheme in [RFC4055].

Is this RSA with SHA-256 PKCS#1 Version 1.5 or RSA with SHA-256 using
RSASSA-PSS?  If it's the later is the id-sha256 the hashAlgorithm in the
RSASSA-PSS-params or something else.  Also wouldn't you have to say more
like what's the hashAlgorithm, maskGenAlgorithm, whether
RSASSA-PSS-params is included in certificates?

Also r/RSA with SHA256/RSA with SHA-256

- Sections 4.1-4.4: The eContent values for the CMS content types threw
me for a loop.  You're not using them to protect the BAB, PIB, etc. it's
just the encrypted HMAC key, signed checksum, and encrypted BEK.  It
reads like there are two sets of operation for each of the four Block
Types.  You do one for the BAB, PIB, etc. values and then another for
the CMS structures?  Am I reading that right?  The parts about the
"eContent" e.g.,:

The "eContent" field in EncapsulatedContentInfo contains the signed
checksum (SignatureValue) of the data.

That tells me the CMS processing generates a message digest over the PIB
SignatureValue and then signs the output of the message digest and put
it in the SignerInfo.signature value field.

Couldn't you just omit all the eContents?  They're optional in all cases
and can be gotten from elsewhere in the CMS blobs.

- Section 7: You should point to [RFC5652]/[RFC5280] for it's security
considerations when using CMS/certificates.  This save you recreating
text about keeping keys secret, etc.  Need some additional motherhood
and apple pie statements about randomly generating keys and point to
[RFC4106].  And a pointer to [RFC5084] for concerns about AES-GCM.

- Section 7: I didn't see a security consideration that addresses why
you'd prefer to encrypt then authenticate.  The text earlier implied and
attack of some kind.  RFC 5751 also had something to say about this:

    There are security ramifications to choosing whether to sign first or
    encrypt first.  A recipient of a message that is encrypted and then
    signed can validate that the encrypted block was unaltered, but
    cannot determine any relationship between the signer and the
    unencrypted contents of the message.  A recipient of a message that
    is signed then encrypted can assume that the signed message itself
    has not been altered, but that a careful attacker could have changed
    the unauthenticated portions of the encrypted message.

- IANA Considerations: When defining an IANA controlled registry the
document needs to indicate how the registry is updated (e.g., RFC
required, expert review, etc.).  See Section 4 of RFC 5226.

Cheers,

spt

--------------000602010102030909030309--

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, Joerg Ott <[email-masked]>
Date: Thu, 17 Feb 2011 09:06:21 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] LTPCL comments (was: Re: advance ECOS and LTPCL drafts?)

Stephen, some comments on your comments.

#1:  I'm not following you on why anything more needs to go in here.  The LTPCL spec is only trying to specify what the LTP convergence-layer adapter is supposed to do, not what the BPA is supposed to do; that's in RFC 5050.

The "upon reception of a green-part segment arrival notice" rules (a, b, c) say exactly what the LTPCL is supposed to do when a green segment arrives.

If it's for a block other than the one you're reassembling, you ditch the old partial block and start on the new one; nothing goes to the BPA at all.

Otherwise you add it to the block you're reassembling.  If you detect a gap, you remember it.  If this is the last segment of the block, you deliver the entire content of the block (which can only contain one bundle, per section 2.2) to the BPA, possibly with some report of the gaps you've detected in the block.

At that point it's up to the BPA to decide what to do, and that's mostly a BPA implementation matter.  Section 7.2 of RFC 5050 says the convergence layer is supposed to deliver received bundles to the BPA and section 5.6 says how the BPA is supposed to handle them.  It is possible that we should add more text to RFC 5050 to state more explicitly how the BPA should detect errors in the bundle and how it should respond to those errors, but I think that's a question to take up when we start on RFC 5050bis, not something to try to solve in this convergence-layer spec.  (I personally think reactively fragmenting the gap-ridden bundle would be very wrong, but that's a topic for another thread.)

#2:  Sure, a reference to CBHE would be fine here, but I thought Internet Drafts couldn't be referenced.  I guess we can insert a place-holder reference and wait for the CBHE RFC to come out, and certainly we can add an example.

#3:  Sure, I'll add a note.  It would save the reader the trouble of working this out from the rules.

#4:  Keith's comment is right, we need to standardize this demux for interoperability.  I thought about putting a note on this point into the "IANA Considerations" section but thought it might be overkill; it sounds like I need to do that after all.

I see your point, though, about preserving the ability to support multiple BPAs from a single LTP engine.  How about handling this a little like HTTP or SSH?  We can reserve a single standard well-known client service ID for "BP" (1) but change the language in 2.2 to SHOULD instead of MUST, so that it's okay to use a different client service ID that you've agreed on privately.  Maybe reserve client service IDs 0-1023 for well-known LTP client services, 1024-16383 for registered client services, and leave IDs above 16383 for private use?

#5:  No, this has nothing to do with the ION implementation, it's for alignment with RFC 5050.  Step 6 of section 5.4 of RFC 5050 identifies the BPA's dependence on this notification: "When all selected convergence layer adapters have informed the bundle protocol agent that they have concluded their data sending procedures with regard to this bundle...."  I figure the procedure at this point needs to be described in the language used in the BP spec so that an implementer looking at the two documents can make sense of them.  The manner in which this notification happens is, of course, completely a matter of implementation; the fact that LTPlib doesn't do this explicitly is fine.

#6:  Again, this language has nothing to do with the ION implementation; these notices are called out pretty clearly in sections 7.2 and 7.3 of RFC 5326.  I think the description of LTPCL procedures should be able to reference them in order to make the processing clear to the implementer.  The fact that LTPlib doesn't implement those notices doesn't make it non-conformant, I guess, because there's no MUST language in section 7 of RFC 5326, but I don't understand why the details of that implementation should constrain this specification.

#7:  I'd prefer not to hold up publication of an LTPCL RFC until we can complete the interoperability testing that you propose, but I'll leave that up to the Research Group.

#8:  Are you suggesting that the language in the security section be changed from "could reduce" to "MAY be used to reduce"?  That's fine with me.

#9:  Sure, I'll happily remove RFC 3986 from the list of normative references.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, February 17, 2011 4:56 AM
To: Joerg Ott
Cc: Burleigh, Scott C (313B); [email-masked]
Subject: LTPCL comments (was: Re: [dtn-interest] advance ECOS and LTPCL drafts?)

I didn't look at the ECOS one yet but I have some comments on LTPCL.

I think this is almost but not quite cooked.

I'd like if we (or someone, doesn't have to be us) had a chance to
do an ION interop with DTN2/LTPlib to validate this spec before the
RFC issues - anyone up for that? We probably won't have much time
in the next few weeks for that though, but that code is on
sourceforge now so anyone else is free to try (and we'll help:-).
If its not time-critical, we will be doing this in the next few
months, but that might lead to changes being required which could
bugger up CCSDS's plans.

Other than that, there are a few places where I think this is a
bit ION-specific, see the comments below. I expect we can fix those
with wordsmithing and a few s/MUST/MAY/ type changes.

The only really meaty comment is #1 below which needs more than
wordsmithing I think.

#1 I think we may need a bit more text on what to do if only
parts of the green block arrive - what should the BPA do in
that case? I guess also that the text in 2.3 that says "if and
when the bundle encapsulated in that block is received" is
a tad ambiguous in that case - does the BPA consider that
a bundle with a green-gap or two "has arrived" or not and
if it has "arrived" then what ought the BPA do with it? I
could envisage adding a new flag and gap-info or something
to such a bundle before you forward it further and padding
gaps with zeros. That'd have to go in a new extension
block. That new extension block could be defined here I
suppose. (This happened in some ESA tests we did, so I think
we do need to address the issue.)

#2 2.1 needs to reference cbhe and an example would be useful.

#3 2.2 essentially says that this doesn't support sending
more than one bundle with mixed red/green. I think it'd be
better to be explicit about that.

#4 2.2 says: "The client service ID number passed by LTPCLA to
LTP with each block MUST be 1, signifying that the client
service is the Bundle Protocol." Why is that needed? DTN2/LTPlib
doesn't do it that way. If we do do it that way, I suspect
we'll need to do some IANA stuff. I'd get rid of that I think.

#5 2.2 says: "Upon reception of a transmission-session completion
notice from the LTP receiver engine, LTPCLA MUST inform the bundle
protocol agent that data sending procedures with regard to all
bundles in the corresponding block have concluded." Again,
DTN2/LTPlib doesn't do that DTN2/LTPlib just calls ltp_sendto()
and then is done with the bundle. (In the normal case.)
I s/MUST/MAY/ for these I think since they're really to do
with the specific implementation.

#6 2.3 assumes that the BP/LTPCL api exposes the red part info,
DTN2/LTPlib doesn't do that, DTN2 just has a blocking ltp_recvfrom()
call in a thread, that is, there is no "red part reception notice."
Same for the "green part reception notice" in 2.3. So again
s/MUST/MAY/ here might be right.

#7 2.3 (b) - DTN2/LTPlib doesn't yet support receipt of >1 bundle,
but that can be added and the text is fine as-is I think. Adding
that code (should be easy) while doing that interop would be a
fine thing.

#8 I think you want to say that the LTP auth stuff "MAY" be used
in the security considerations.

#9 RFC3986 isn't referenced or needed as far as I can see

Cheers,
S.

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Thu, 17 Feb 2011 15:55:58 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: Re: [dtn-interest] LTPCL comments

> Issue there is that those fragments, when they arrive at 
> their ultimate destination (when that is not the LTP 
> receiver) won't ever be reassembled, so I still think you 
> need some marking.
> But yes, sending fragments is probably better than filling 
> gaps with zeros.
> 
> Since any good way to do this is probably hard (to 
> code/debug) ought we say that an implementation MAY just drop 
> a gappy bundle and define the further handling of gappy 
> bundles as an optional-to-implement thing?

looks like ATM early/partial packet discard has just been reinvented.

Date: Thu, 17 Feb 2011 15:04:49 +0000
From: Stephen Farrell <[email-masked]>
To: "Scott, Keith L." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] LTPCL comments

Hi Keith,

On 17/02/11 14:00, Scott, Keith L. wrote:
> Stephen,
> 
> #1: I would think that for #1 the option would be for the node receiving
> only parts of a green block containing one or more bundles to fragment the
> received bundle(s) before forwarding them.  There's another issue hiding
> there in that if a green block contains multiple concatenated bundles and if
> a segment containing an LTP header is lost, the rest of the block is (I
> think) un-processable since at that point the LTPCL has lost the 'framing'
> (if it's iterating down the bundles contained in the block, using the
> information in the bundle headers to determine lengths).

Issue there is that those fragments, when they arrive at their
ultimate destination (when that is not the LTP receiver) won't
ever be reassembled, so I still think you need some marking.
But yes, sending fragments is probably better than filling gaps
with zeros.

Since any good way to do this is probably hard (to code/debug)
ought we say that an implementation MAY just drop a gappy
bundle and define the further handling of gappy bundles as
an optional-to-implement thing?

As of now, DTN2/LTPlib just hands up the bundle with
zeros in the gaps and tells no-one, which is probably not
the right thing;-) LTPlib does have an API so the BPA
can find out about it, but I didn't write that code yet.

> #4: I think the text you mention in #4 is needed.  The LTPCL is one possible
> demux for LTP blocks, and needs to be unambiguously identified as such.  The
> text in the draft is just saying that the LTP service number for the LTPCL
> SHALL be 1 (I think).  An 'LTP Client Service ID' Registry might be a good
> thing, and its creation could be requested by the draft.

That could be a sensible thing anyway - I guess if you wanted
say CFDP/LTP directly then you'd want a different CSI. For the
DTN2/LTPlib its no deal though, we could add a sockopt that
allows the BPA to fix the CSI.

However, will there never be a reason to use two different CSI's
with BP/LTP at one node though? Why prevent an implementation
with one LTP engine and two BPAs? (Which I think the current
MUST implies.)

> #5: I believe the desire to inform the daemon that a block (set of bundles)
> has been successfully transmitted stems from the desire to use LTPCL as a
> reliable CL (i.e. treating it more like a TCP-CL than a UDP-CL).  Providing
> feedback that a set of bundles has been reliably transferred is very
> powerful, and if this can be gleaned from the CL (which presumably has a
> tightER control loop) so that the bundle daemon doesn't have to waste
> bandwidth doing it would be a good thing.  Just because the DTN2 LTPCL
> doesn't do this doesn't mean that it might not be a good requirement to levy
> on an LTPCL.  SHOULD might be a good middle ground?

Successfully transmitted != ack'd though since that could happen much
later. Not sure that the BPA should hang onto the bundle that long
waiting in all case. But a "SHOULD" with the right weasel words
could probably be figured out I guess.

> #6: I think the 'red-part reception notice' might be interpreted as the
> return from ltp_recvfrom(); not sure about green-part notices; I'll have to
> look at the code.

Not quite - ltp_recvfrom() will only return after the EOB (in the
nominal case) which could be much later than the EORP. Does a BPA
really need the EORP indicator anyway? How about saying that an
implementation MAY indicate EORP instead?

S.

> 
> Thanks to you and everyone else for having a look at these,
> 
> 		--keith
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> Stephen Farrell
> Sent: Thursday, February 17, 2011 7:56 AM
> To: Joerg Ott
> Cc: [email-masked]
> Subject: [dtn-interest] LTPCL comments (was: Re: advance ECOS and LTPCL
> drafts?)
> 
> 
> I didn't look at the ECOS one yet but I have some comments on LTPCL.
> 
> I think this is almost but not quite cooked.
> 
> I'd like if we (or someone, doesn't have to be us) had a chance to
> do an ION interop with DTN2/LTPlib to validate this spec before the
> RFC issues - anyone up for that? We probably won't have much time
> in the next few weeks for that though, but that code is on
> sourceforge now so anyone else is free to try (and we'll help:-).
> If its not time-critical, we will be doing this in the next few
> months, but that might lead to changes being required which could
> bugger up CCSDS's plans.
> 
> Other than that, there are a few places where I think this is a
> bit ION-specific, see the comments below. I expect we can fix those
> with wordsmithing and a few s/MUST/MAY/ type changes.
> 
> The only really meaty comment is #1 below which needs more than
> wordsmithing I think.
> 
> #1 I think we may need a bit more text on what to do if only
> parts of the green block arrive - what should the BPA do in
> that case? I guess also that the text in 2.3 that says "if and
> when the bundle encapsulated in that block is received" is
> a tad ambiguous in that case - does the BPA consider that
> a bundle with a green-gap or two "has arrived" or not and
> if it has "arrived" then what ought the BPA do with it? I
> could envisage adding a new flag and gap-info or something
> to such a bundle before you forward it further and padding
> gaps with zeros. That'd have to go in a new extension
> block. That new extension block could be defined here I
> suppose. (This happened in some ESA tests we did, so I think
> we do need to address the issue.)
> 
> #2 2.1 needs to reference cbhe and an example would be useful.
> 
> #3 2.2 essentially says that this doesn't support sending
> more than one bundle with mixed red/green. I think it'd be
> better to be explicit about that.
> 
> #4 2.2 says: "The client service ID number passed by LTPCLA to
> LTP with each block MUST be 1, signifying that the client
> service is the Bundle Protocol." Why is that needed? DTN2/LTPlib
> doesn't do it that way. If we do do it that way, I suspect
> we'll need to do some IANA stuff. I'd get rid of that I think.
> 
> #5 2.2 says: "Upon reception of a transmission-session completion
> notice from the LTP receiver engine, LTPCLA MUST inform the bundle
> protocol agent that data sending procedures with regard to all
> bundles in the corresponding block have concluded." Again,
> DTN2/LTPlib doesn't do that DTN2/LTPlib just calls ltp_sendto()
> and then is done with the bundle. (In the normal case.)
> I s/MUST/MAY/ for these I think since they're really to do
> with the specific implementation.
> 
> #6 2.3 assumes that the BP/LTPCL api exposes the red part info,
> DTN2/LTPlib doesn't do that, DTN2 just has a blocking ltp_recvfrom()
> call in a thread, that is, there is no "red part reception notice."
> Same for the "green part reception notice" in 2.3. So again
> s/MUST/MAY/ here might be right.
> 
> #7 2.3 (b) - DTN2/LTPlib doesn't yet support receipt of >1 bundle,
> but that can be added and the text is fine as-is I think. Adding
> that code (should be easy) while doing that interop would be a
> fine thing.
> 
> #8 I think you want to say that the LTP auth stuff "MAY" be used
> in the security considerations.
> 
> #9 RFC3986 isn't referenced or needed as far as I can see
> 
> Cheers,
> S.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Scott, Keith L." <[email-masked]>
To: Stephen Farrell <[email-masked]>, Joerg Ott <[email-masked]>
Date: Thu, 17 Feb 2011 09:00:05 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] LTPCL comments (was: Re: advance ECOS and LTPCL	drafts?)

------=_NextPart_000_0021_01CBCE81.11C11280
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stephen,

#1: I would think that for #1 the option would be for the node receiving
only parts of a green block containing one or more bundles to fragment the
received bundle(s) before forwarding them.  There's another issue hiding
there in that if a green block contains multiple concatenated bundles and if
a segment containing an LTP header is lost, the rest of the block is (I
think) un-processable since at that point the LTPCL has lost the 'framing'
(if it's iterating down the bundles contained in the block, using the
information in the bundle headers to determine lengths).

#4: I think the text you mention in #4 is needed.  The LTPCL is one possible
demux for LTP blocks, and needs to be unambiguously identified as such.  The
text in the draft is just saying that the LTP service number for the LTPCL
SHALL be 1 (I think).  An 'LTP Client Service ID' Registry might be a good
thing, and its creation could be requested by the draft.

#5: I believe the desire to inform the daemon that a block (set of bundles)
has been successfully transmitted stems from the desire to use LTPCL as a
reliable CL (i.e. treating it more like a TCP-CL than a UDP-CL).  Providing
feedback that a set of bundles has been reliably transferred is very
powerful, and if this can be gleaned from the CL (which presumably has a
tightER control loop) so that the bundle daemon doesn't have to waste
bandwidth doing it would be a good thing.  Just because the DTN2 LTPCL
doesn't do this doesn't mean that it might not be a good requirement to levy
on an LTPCL.  SHOULD might be a good middle ground?

#6: I think the 'red-part reception notice' might be interpreted as the
return from ltp_recvfrom(); not sure about green-part notices; I'll have to
look at the code.

Thanks to you and everyone else for having a look at these,

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Thursday, February 17, 2011 7:56 AM
To: Joerg Ott
Cc: [email-masked]
Subject: [dtn-interest] LTPCL comments (was: Re: advance ECOS and LTPCL
drafts?)

I didn't look at the ECOS one yet but I have some comments on LTPCL.

I think this is almost but not quite cooked.

I'd like if we (or someone, doesn't have to be us) had a chance to
do an ION interop with DTN2/LTPlib to validate this spec before the
RFC issues - anyone up for that? We probably won't have much time
in the next few weeks for that though, but that code is on
sourceforge now so anyone else is free to try (and we'll help:-).
If its not time-critical, we will be doing this in the next few
months, but that might lead to changes being required which could
bugger up CCSDS's plans.

Other than that, there are a few places where I think this is a
bit ION-specific, see the comments below. I expect we can fix those
with wordsmithing and a few s/MUST/MAY/ type changes.

The only really meaty comment is #1 below which needs more than
wordsmithing I think.

#1 I think we may need a bit more text on what to do if only
parts of the green block arrive - what should the BPA do in
that case? I guess also that the text in 2.3 that says "if and
when the bundle encapsulated in that block is received" is
a tad ambiguous in that case - does the BPA consider that
a bundle with a green-gap or two "has arrived" or not and
if it has "arrived" then what ought the BPA do with it? I
could envisage adding a new flag and gap-info or something
to such a bundle before you forward it further and padding
gaps with zeros. That'd have to go in a new extension
block. That new extension block could be defined here I
suppose. (This happened in some ESA tests we did, so I think
we do need to address the issue.)

#2 2.1 needs to reference cbhe and an example would be useful.

#3 2.2 essentially says that this doesn't support sending
more than one bundle with mixed red/green. I think it'd be
better to be explicit about that.

#4 2.2 says: "The client service ID number passed by LTPCLA to
LTP with each block MUST be 1, signifying that the client
service is the Bundle Protocol." Why is that needed? DTN2/LTPlib
doesn't do it that way. If we do do it that way, I suspect
we'll need to do some IANA stuff. I'd get rid of that I think.

#5 2.2 says: "Upon reception of a transmission-session completion
notice from the LTP receiver engine, LTPCLA MUST inform the bundle
protocol agent that data sending procedures with regard to all
bundles in the corresponding block have concluded." Again,
DTN2/LTPlib doesn't do that DTN2/LTPlib just calls ltp_sendto()
and then is done with the bundle. (In the normal case.)
I s/MUST/MAY/ for these I think since they're really to do
with the specific implementation.

#6 2.3 assumes that the BP/LTPCL api exposes the red part info,
DTN2/LTPlib doesn't do that, DTN2 just has a blocking ltp_recvfrom()
call in a thread, that is, there is no "red part reception notice."
Same for the "green part reception notice" in 2.3. So again
s/MUST/MAY/ here might be right.

#7 2.3 (b) - DTN2/LTPlib doesn't yet support receipt of >1 bundle,
but that can be added and the text is fine as-is I think. Adding
that code (should be easy) while doing that interop would be a
fine thing.

#8 I think you want to say that the LTP auth stuff "MAY" be used
in the security considerations.

#9 RFC3986 isn't referenced or needed as far as I can see

Cheers,
S.

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------=_NextPart_000_0021_01CBCE81.11C11280
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_0021_01CBCE81.11C11280--

Date: Thu, 17 Feb 2011 12:56:18 +0000
From: Stephen Farrell <[email-masked]>
To: Joerg Ott <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] LTPCL comments (was: Re: advance ECOS and LTPCL drafts?)

I didn't look at the ECOS one yet but I have some comments on LTPCL.

I think this is almost but not quite cooked.

I'd like if we (or someone, doesn't have to be us) had a chance to
do an ION interop with DTN2/LTPlib to validate this spec before the
RFC issues - anyone up for that? We probably won't have much time
in the next few weeks for that though, but that code is on
sourceforge now so anyone else is free to try (and we'll help:-).
If its not time-critical, we will be doing this in the next few
months, but that might lead to changes being required which could
bugger up CCSDS's plans.

Other than that, there are a few places where I think this is a
bit ION-specific, see the comments below. I expect we can fix those
with wordsmithing and a few s/MUST/MAY/ type changes.

The only really meaty comment is #1 below which needs more than
wordsmithing I think.

#1 I think we may need a bit more text on what to do if only
parts of the green block arrive - what should the BPA do in
that case? I guess also that the text in 2.3 that says "if and
when the bundle encapsulated in that block is received" is
a tad ambiguous in that case - does the BPA consider that
a bundle with a green-gap or two "has arrived" or not and
if it has "arrived" then what ought the BPA do with it? I
could envisage adding a new flag and gap-info or something
to such a bundle before you forward it further and padding
gaps with zeros. That'd have to go in a new extension
block. That new extension block could be defined here I
suppose. (This happened in some ESA tests we did, so I think
we do need to address the issue.)

#2 2.1 needs to reference cbhe and an example would be useful.

#3 2.2 essentially says that this doesn't support sending
more than one bundle with mixed red/green. I think it'd be
better to be explicit about that.

#4 2.2 says: "The client service ID number passed by LTPCLA to
LTP with each block MUST be 1, signifying that the client
service is the Bundle Protocol." Why is that needed? DTN2/LTPlib
doesn't do it that way. If we do do it that way, I suspect
we'll need to do some IANA stuff. I'd get rid of that I think.

#5 2.2 says: "Upon reception of a transmission-session completion
notice from the LTP receiver engine, LTPCLA MUST inform the bundle
protocol agent that data sending procedures with regard to all
bundles in the corresponding block have concluded." Again,
DTN2/LTPlib doesn't do that DTN2/LTPlib just calls ltp_sendto()
and then is done with the bundle. (In the normal case.)
I s/MUST/MAY/ for these I think since they're really to do
with the specific implementation.

#6 2.3 assumes that the BP/LTPCL api exposes the red part info,
DTN2/LTPlib doesn't do that, DTN2 just has a blocking ltp_recvfrom()
call in a thread, that is, there is no "red part reception notice."
Same for the "green part reception notice" in 2.3. So again
s/MUST/MAY/ here might be right.

#7 2.3 (b) - DTN2/LTPlib doesn't yet support receipt of >1 bundle,
but that can be added and the text is fine as-is I think. Adding
that code (should be easy) while doing that interop would be a
fine thing.

#8 I think you want to say that the LTP auth stuff "MAY" be used
in the security considerations.

#9 RFC3986 isn't referenced or needed as far as I can see

Cheers,
S.

Date: Thu, 17 Feb 2011 13:54:14 +0200
From: Joerg Ott <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] advance ECOS and LTPCL drafts?

Hi everyone,

just want to make sure that this does not get lost.

 > http://datatracker.ietf.org/doc/draft-burleigh-dtnrg-ltpcl/

The above draft has been around for a while, it saw a few
revisions, and got some discussion on the mailing list.

It solves a problem and there don't _seem_ to be any open issues.

Also, the draft fills a gap, especially since CCSDS would benefit
from being able to reference it (for which it should be an RFC
soon-ish).

So, please consider this an DTNRG last call for this draft.

It is short, so please go through the effort to read it and
comment to the list and the authors.

Please do so within the next two weeks (i.e., by 2 Marc 2011)
so that we can get any revisions in before the I-D deadline
and have the draft sent to the IRSG for review.

Joerg

Date: Wed, 16 Feb 2011 13:40:51 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: [email-masked], [email-masked], Frederic Guidec <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  DTN2 vs Haggle

There's also draft-farrell-dtnrg-bpq which is (yet another) way
we're looking at doing information centric networking with the BP.
We're (TCD) writing code for that btw. and should have some
feedback on how it works (or not:-) in a few months.

S.

On 16/02/11 13:20, Peter Lovell wrote:
> Hi Rui,
> 
> following on from Fred's comments ...
> 
> DTN does involve itself with the business of getting data from source to
> destination, and not much with the data content. However there are
> separate efforts under way that look at find-by-content, pre-positioning
> data, addressing bundles to users in a certain geographic area, and so
> on. This work is not part of the "messaging" part of DTN but you will
> find presentations included in the IETF proceedings (on-line) for example.
> 
> Regards.....Peter
> 
> 
> On Wed, Feb 16, 2011, Frederic Guidec <[email-masked]> wrote:
> 
>>
>> Hello Rui,
>>
>> The DTN2 approach is (at least currently) focused on destination-based 
>> networking: each bundle is adressed to a set destination, and is somehow 
>> routed toward that destination through DTN gateways.
>>
>> In contrast the Haggle platform supports content-based networking in 
>> disconnected MANETs: information (typically files) is "published" in the 
>> network, and it is received by hosts that have "subscribed" to receive 
>> this kind of information. The store-carry-and-forward approach is indeed 
>> used, as mobile hosts (or at least some of them) must store and carry 
>> messages while moving around in order to bridge the gap between 
>> non-connected parts of the network.
>>
>> You may find further information about the Haggle platform on 
>> http://code.google.com/p/haggle/wiki/FAQ, but you may also be interested 
>> to learn that there is another platform called DoDWAN (Document 
>> Dissemination in Wireless Ad hoc Networks), which is also devoted to 
>> content-based information dissemination in disconnected MANETs: 
>> http://www-valoria.univ-ubs.fr/CASA/DoDWAN
>>
>> Do not hesitate to contact me directly (or using this mailing-list) if 
>> you have any question about DoDWAN. For the Haggle platform, I'm afraid 
>> you'll have to wait until you can access their discussion list.  ;-)
>>
>> Best regards,
>>
>> Fred Guidec
>> --
>>
>>
>> On 02/15/2011 11:03 AM, Rui Quelhas wrote:
>>> Hi again,
>>>
>>> anything on my previous message? Am I really in the wrong place? :)
>>>
>>> On 2011/02/11, at 16:47, Rui Quelhas wrote:
>>>
>>>> Hi there,
>>>>
>>>> I'm currently working on a project that requires the deployment of
>> opportunistic and delay-tolerant services and I was wondering how can
>> the DTN2 implementation and Haggle match? I'm perfectly aware that DTN
>> adapts to a broad set of challenged environments like deep-space
>> communications and military networks but my focus is all about
>> terrestrial mobile networks (social and community based) and my concerns
>> are specially about how can Haggle handle store-carry-forward.
>>>>
>>>> I'm probably talking nonsense and I should try to make theses
>> questions using the Haggle lists but I guess they require some sort of
>> authorization, and I'm still waiting for it. So, hopping that i can
>> actually reach some Haggle users over here I would ask if anyone knows
>> any good resource that establishes some kind of comparison between the
>> two (DTN2 and Haggle)?
>>>>
>>>>
>>
>>
>> -- 
>> Dr. Frederic GUIDEC -------------------------------------
>> Laboratoire VALORIA -- Université de Bretagne Sud
>> Université Européenne de Bretagne
>> Campus de Tohannic
>> BP 573 - F-56017 Vannes, France
>> mailto:Frederic.Guidec%AT%univ-ubs.fr
>> http://www-valoria.univ-ubs.fr/Frederic.Guidec
>> tel : +33 (0)2 97 01 72 16
>> fax : +33 (0)2 97 01 72 79
>> ---------------------------------------------------------
>> _______________________________________________
>> 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: Frederic Guidec <[email-masked]>, Rui Quelhas <[email-masked]>
Date: Wed, 16 Feb 2011 08:20:42 -0500
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re(2):  DTN2 vs Haggle

Hi Rui,

following on from Fred's comments ...

DTN does involve itself with the business of getting data from source to
destination, and not much with the data content. However there are
separate efforts under way that look at find-by-content, pre-positioning
data, addressing bundles to users in a certain geographic area, and so
on. This work is not part of the "messaging" part of DTN but you will
find presentations included in the IETF proceedings (on-line) for example.

Regards.....Peter

On Wed, Feb 16, 2011, Frederic Guidec <[email-masked]> wrote:

>
>Hello Rui,
>
>The DTN2 approach is (at least currently) focused on destination-based 
>networking: each bundle is adressed to a set destination, and is somehow 
>routed toward that destination through DTN gateways.
>
>In contrast the Haggle platform supports content-based networking in 
>disconnected MANETs: information (typically files) is "published" in the 
>network, and it is received by hosts that have "subscribed" to receive 
>this kind of information. The store-carry-and-forward approach is indeed 
>used, as mobile hosts (or at least some of them) must store and carry 
>messages while moving around in order to bridge the gap between 
>non-connected parts of the network.
>
>You may find further information about the Haggle platform on 
>http://code.google.com/p/haggle/wiki/FAQ, but you may also be interested 
>to learn that there is another platform called DoDWAN (Document 
>Dissemination in Wireless Ad hoc Networks), which is also devoted to 
>content-based information dissemination in disconnected MANETs: 
>http://www-valoria.univ-ubs.fr/CASA/DoDWAN
>
>Do not hesitate to contact me directly (or using this mailing-list) if 
>you have any question about DoDWAN. For the Haggle platform, I'm afraid 
>you'll have to wait until you can access their discussion list.  ;-)
>
>Best regards,
>
>Fred Guidec
>--
>
>
>On 02/15/2011 11:03 AM, Rui Quelhas wrote:
>> Hi again,
>>
>> anything on my previous message? Am I really in the wrong place? :)
>>
>> On 2011/02/11, at 16:47, Rui Quelhas wrote:
>>
>>> Hi there,
>>>
>>> I'm currently working on a project that requires the deployment of
>opportunistic and delay-tolerant services and I was wondering how can
>the DTN2 implementation and Haggle match? I'm perfectly aware that DTN
>adapts to a broad set of challenged environments like deep-space
>communications and military networks but my focus is all about
>terrestrial mobile networks (social and community based) and my concerns
>are specially about how can Haggle handle store-carry-forward.
>>>
>>> I'm probably talking nonsense and I should try to make theses
>questions using the Haggle lists but I guess they require some sort of
>authorization, and I'm still waiting for it. So, hopping that i can
>actually reach some Haggle users over here I would ask if anyone knows
>any good resource that establishes some kind of comparison between the
>two (DTN2 and Haggle)?
>>>
>>>
>
>
>-- 
>Dr. Frederic GUIDEC -------------------------------------
>Laboratoire VALORIA -- Université de Bretagne Sud
>Université Européenne de Bretagne
>Campus de Tohannic
>BP 573 - F-56017 Vannes, France
>mailto:Frederic.Guidec%AT%univ-ubs.fr
>http://www-valoria.univ-ubs.fr/Frederic.Guidec
>tel : +33 (0)2 97 01 72 16
>fax : +33 (0)2 97 01 72 79
>---------------------------------------------------------
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Rui Quelhas <[email-masked]>
Date: Wed, 16 Feb 2011 10:23:37 +0000
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN2 vs Haggle

--Apple-Mail-16--430445768
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks for the help (including the off-list replies).

Keep up the good work.

On 02/15/2011 11:03 AM, Rui Quelhas wrote:
> Hi again,
>=20
> anything on my previous message? Am I really in the wrong place? :)
>=20
> On 2011/02/11, at 16:47, Rui Quelhas wrote:
>=20
>> Hi there,
>>=20
>> I'm currently working on a project that requires the deployment of =
opportunistic and delay-tolerant services and I was wondering how can =
the DTN2 implementation and Haggle match? I'm perfectly aware that DTN =
adapts to a broad set of challenged environments like deep-space =
communications and military networks but my focus is all about =
terrestrial mobile networks (social and community based) and my concerns =
are specially about how can Haggle handle store-carry-forward.
>>=20
>> I'm probably talking nonsense and I should try to make theses =
questions using the Haggle lists but I guess they require some sort of =
authorization, and I'm still waiting for it. So, hopping that i can =
actually reach some Haggle users over here I would ask if anyone knows =
any good resource that establishes some kind of comparison between the =
two (DTN2 and Haggle)?
>>=20
>>=20

---
Best regards,
Rui Quelhas.

--Apple-Mail-16--430445768
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Thanks for the help (including the off-list =
replies).</div><div><br></div><div>Keep up the good =
work.</div><div><br><div><div>On 02/15/2011 11:03 AM, Rui Quelhas =
wrote:<br><blockquote type=3D"cite">Hi =
again,<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">anything on my =
previous message? Am I really in the wrong place? =
:)<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">On 2011/02/11, at 16:47, Rui Quelhas =
wrote:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">Hi there,<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I'm currently working on a =
project that requires the deployment of opportunistic and delay-tolerant =
services and I was wondering how can the DTN2 implementation and Haggle =
match? I'm perfectly aware that DTN adapts to a broad set of challenged =
environments like deep-space communications and military networks but my =
focus is all about terrestrial mobile networks (social and community =
based) and my concerns are specially about how can Haggle handle =
store-carry-forward.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I'm probably talking nonsense =
and I should try to make theses questions using the Haggle lists but I =
guess they require some sort of authorization, and I'm still waiting for =
it. So, hopping that i can actually reach some Haggle users over here I =
would ask if anyone knows any good resource that establishes some kind =
of comparison between the two (DTN2 and =
Haggle)?<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><font class=3D"Apple-style-span" =
color=3D"#144FAE"><font class=3D"Apple-style-span" =
color=3D"#540000"><br></font></font></blockquote></blockquote></div></div>=
</div><br><div>
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Helvetica; 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: 0px; font-size: medium; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; 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: 0px; font-size: medium; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: 2; =
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: 0px; font-size: medium; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><br></div><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">---<br>Best regards,<br>Rui =
Quelhas.</div></span></div></span></span>
</div>
<br></body></html>=

--Apple-Mail-16--430445768--

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, dtn interest <[email-masked]>
Date: Tue, 15 Feb 2011 21:19:10 -0500
Subject: Re: [dtn-interest] An IPR reminder (sadly)

On Tue, Feb 15, 2011, Stephen Farrell <[email-masked]> wrote:

>Someone just forwarded me the fairly irritating links
>below. [1-5] (I didn't read 'em all in detail because
>life is just too short for that when its not unavoidable;-)
>
>I guess we should be aware that people are filing at least
>a few patents related to DTN and so I remind you all that
>if you're aware of patents affecting any DTNRG Internet
>Drafts then you should make an IPR declaration. The
>relevant rules for us are in RFC 5743, [6] section 3.2.
>The IPR declaration system is at [7]. First party
>declarations are required and 3rd party declarations
>(if you know of someone else's relevant IPR) are
>allowed.
>
>Incidentally, I don't know the process in the US, but
>frankly that first one seems to be a particularly stupid
>filing (with no apologies to the inventor) and the
>DTN2 TCP-proxy seems to me to be near-perfect prior
>art that pre-dates the filing date by I would guess
>quite a bit. I guess someone who knew how could maybe
>tell the USPTO about that.
>
>Stephen.
>
>[1] http://www.freepatentsonline.com/y2010/0125901.html
>[2] http://www.freepatentsonline.com/7835285.html
>[3] http://www.freepatentsonline.com/7764622.html
>[4] http://www.freepatentsonline.com/7881217.html
>[5] http://www.freepatentsonline.com/y2008/0155070.html

Hi Stephen,

I didn't have time either to read them but I note that [1] is from
Raytheon and the others are Boeing.

Raytheon is the company that acquired BBN, and thereby the DARPA
contracts on DTN that they had. I wasn't involved in those but some
other people at SPARTA were (in the past).

What's the best prior-art reference for the TCP-proxy?

Cheers.....Peter

Date: Wed, 16 Feb 2011 00:09:44 +0100
From: Frederic Guidec <[email-masked]>
To: Rui Quelhas <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN2 vs Haggle

Hello Rui,

The DTN2 approach is (at least currently) focused on destination-based 
networking: each bundle is adressed to a set destination, and is somehow 
routed toward that destination through DTN gateways.

In contrast the Haggle platform supports content-based networking in 
disconnected MANETs: information (typically files) is "published" in the 
network, and it is received by hosts that have "subscribed" to receive 
this kind of information. The store-carry-and-forward approach is indeed 
used, as mobile hosts (or at least some of them) must store and carry 
messages while moving around in order to bridge the gap between 
non-connected parts of the network.

You may find further information about the Haggle platform on 
http://code.google.com/p/haggle/wiki/FAQ, but you may also be interested 
to learn that there is another platform called DoDWAN (Document 
Dissemination in Wireless Ad hoc Networks), which is also devoted to 
content-based information dissemination in disconnected MANETs: 
http://www-valoria.univ-ubs.fr/CASA/DoDWAN

Do not hesitate to contact me directly (or using this mailing-list) if 
you have any question about DoDWAN. For the Haggle platform, I'm afraid 
you'll have to wait until you can access their discussion list.  ;-)

Best regards,

Fred Guidec
--

On 02/15/2011 11:03 AM, Rui Quelhas wrote:
> Hi again,
>
> anything on my previous message? Am I really in the wrong place? :)
>
> On 2011/02/11, at 16:47, Rui Quelhas wrote:
>
>> Hi there,
>>
>> I'm currently working on a project that requires the deployment of opportunistic and delay-tolerant services and I was wondering how can the DTN2 implementation and Haggle match? I'm perfectly aware that DTN adapts to a broad set of challenged environments like deep-space communications and military networks but my focus is all about terrestrial mobile networks (social and community based) and my concerns are specially about how can Haggle handle store-carry-forward.
>>
>> I'm probably talking nonsense and I should try to make theses questions using the Haggle lists but I guess they require some sort of authorization, and I'm still waiting for it. So, hopping that i can actually reach some Haggle users over here I would ask if anyone knows any good resource that establishes some kind of comparison between the two (DTN2 and Haggle)?
>>
>>

-- 
Dr. Frederic GUIDEC -------------------------------------
Laboratoire VALORIA -- Université de Bretagne Sud
Université Européenne de Bretagne
Campus de Tohannic
BP 573 - F-56017 Vannes, France
mailto:Frederic.Guidec%AT%univ-ubs.fr
http://www-valoria.univ-ubs.fr/Frederic.Guidec
tel : +33 (0)2 97 01 72 16
fax : +33 (0)2 97 01 72 79
---------------------------------------------------------

Date: Tue, 15 Feb 2011 22:52:03 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] An IPR reminder (sadly)

Hi all,

Someone just forwarded me the fairly irritating links
below. [1-5] (I didn't read 'em all in detail because
life is just too short for that when its not unavoidable;-)

I guess we should be aware that people are filing at least
a few patents related to DTN and so I remind you all that
if you're aware of patents affecting any DTNRG Internet
Drafts then you should make an IPR declaration. The
relevant rules for us are in RFC 5743, [6] section 3.2.
The IPR declaration system is at [7]. First party
declarations are required and 3rd party declarations
(if you know of someone else's relevant IPR) are
allowed.

Incidentally, I don't know the process in the US, but
frankly that first one seems to be a particularly stupid
filing (with no apologies to the inventor) and the
DTN2 TCP-proxy seems to me to be near-perfect prior
art that pre-dates the filing date by I would guess
quite a bit. I guess someone who knew how could maybe
tell the USPTO about that.

Stephen.

[1] http://www.freepatentsonline.com/y2010/0125901.html
[2] http://www.freepatentsonline.com/7835285.html
[3] http://www.freepatentsonline.com/7764622.html
[4] http://www.freepatentsonline.com/7881217.html
[5] http://www.freepatentsonline.com/y2008/0155070.html
[6] http://www.rfc-editor.org/rfc/rfc5743.txt
[6] http://www.ietf.org/ipr/

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 15 Feb 2011 09:14:53 -0800
To: Rui Quelhas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN2 vs Haggle

I don't think it's the wrong place, but I know nothing of Haggle.

On Feb 15, 2011, at 2:03 AM, Rui Quelhas wrote:

> Hi again,
> 
> anything on my previous message? Am I really in the wrong place? :)
> 
> On 2011/02/11, at 16:47, Rui Quelhas wrote:
> 
>> Hi there,
>> 
>> I'm currently working on a project that requires the deployment of opportunistic and delay-tolerant services and I was wondering how can the DTN2 implementation and Haggle match? I'm perfectly aware that DTN adapts to a broad set of challenged environments like deep-space communications and military networks but my focus is all about terrestrial mobile networks (social and community based) and my concerns are specially about how can Haggle handle store-carry-forward. 
>> 
>> I'm probably talking nonsense and I should try to make theses questions using the Haggle lists but I guess they require some sort of authorization, and I'm still waiting for it. So, hopping that i can actually reach some Haggle users over here I would ask if anyone knows any good resource that establishes some kind of comparison between the two (DTN2 and Haggle)?
>> 
>> 
>> 
>> ---
>> Best regards,
>> Rui Quelhas
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> 
> 
> ---
> Best regards,
> Rui Quelhas.
> 
> 
> _______________________________________________
> 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: Rui Quelhas <[email-masked]>
Date: Tue, 15 Feb 2011 10:03:36 +0000
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTN2 vs Haggle

Hi again,

anything on my previous message? Am I really in the wrong place? :)

On 2011/02/11, at 16:47, Rui Quelhas wrote:

> Hi there,
> 
> I'm currently working on a project that requires the deployment of opportunistic and delay-tolerant services and I was wondering how can the DTN2 implementation and Haggle match? I'm perfectly aware that DTN adapts to a broad set of challenged environments like deep-space communications and military networks but my focus is all about terrestrial mobile networks (social and community based) and my concerns are specially about how can Haggle handle store-carry-forward. 
> 
> I'm probably talking nonsense and I should try to make theses questions using the Haggle lists but I guess they require some sort of authorization, and I'm still waiting for it. So, hopping that i can actually reach some Haggle users over here I would ask if anyone knows any good resource that establishes some kind of comparison between the two (DTN2 and Haggle)?
> 
> 
> 
> ---
> Best regards,
> Rui Quelhas
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

---
Best regards,
Rui Quelhas.

Date: Sat, 12 Feb 2011 13:18:02 -0800 (PST)
From: =?iso-8859-1?Q?Jayram_D=E9shpand=E9?= <[email-masked]>
To: Elwyn Davies <[email-masked]>, Ma Xuebin <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] about QoS

--0-1320484613-1297545482=:4898
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Here's some of the QoS Related research activities performed at Ohio Univer=
sity back in '05/06.=20

Based upon the priority paradigm presented at SpaceOps2006 [1] , a Thesis w=
ork [2] was conducted to look at=A0 the problem of satisfying the the end t=
o end quality of service requirements in DTN environments.=20

Regards,
-Jay.

[1] http://irg.cs.ohiou.edu/ocp/papers.html
[2] http://etd.ohiolink.edu/view.cgi?acc_num=3Dohiou1163644692=0A   =20

--- On Sat, 2/12/11, Elwyn Davies <[email-masked]> wrote:

From: Elwyn Davies <[email-masked]>
Subject: Re: [dtn-interest] about QoS
To: "Ma Xuebin" <[email-masked]>
Cc: "dtn-interest" <[email-masked]>
Date: Saturday, February 12, 2011, 10:41 AM

Hi.

I wrote a previous state of the art document which has a pretty complete
list of ongoing projects as of early 2009.=A0 You can download it from
http://www.n4c.eu/Download/n4c-wp2-012-state-of-the-art-101.pdf.

A number of other papers and stuff about projects since then can be
found on the DTNRG wiki http://www.dtnrg.org/wiki/Docs.

A quick Google search gets you some other papers, e.g.
http://www.scribd.com/doc/43092916/T-Drop-An-optimal-buffer-management-poli=
cy-to-improve-QOS-in-DTN-routing-protocols
http://www.mecs-press.com/ijcnis/ijcnis-200901005.pdf
http://portal.acm.org/citation.cfm?id=3D1815559
http://ieeexplore.ieee.org/Xplore/login.jsp?url=3Dhttp%3A%2F%
2Fieeexplore.ieee.org%2Fiel5%2F5576746%2F5586844%2F05586899.pdf%
3Farnumber%3D5586899&authDecision=3D-203

Regards,
Elwyn

On Sat, 2011-02-12 at 17:56 +0800, Ma Xuebin wrote:
> Hello,
> who knows the papers or project about the QoS in DTN or opportunistic
> networks, I need these information to introduce the state-of-art.
> thanks a lot.
>=A0=20
> 2011-02-12=20
>=20
> ______________________________________________________________________
> Ma Xuebin=20
> _______________________________________________
> 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
=0A=0A=0A      
--0-1320484613-1297545482=:4898
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">Hi,<br><br>Here's some of the QoS Related res=
earch activities performed at Ohio University back in '05/06. <br><br>Based=
 upon the priority paradigm presented at SpaceOps2006 [1] , a Thesis work [=
2] was conducted to look at&nbsp; the problem of satisfying the the end to =
end quality of service requirements in DTN environments. <br><br>Regards,<b=
r>-Jay.<br><br><br>[1] http://irg.cs.ohiou.edu/ocp/papers.html<br>[2] http:=
//etd.ohiolink.edu/view.cgi?acc_num=3Dohiou1163644692=0A    <br><br><br><br=
><br>--- On <b>Sat, 2/12/11, Elwyn Davies <i>&lt;[email-masked]&gt;</i=
></b> wrote:<br><blockquote style=3D"border-left: 2px solid rgb(16, 16, 255=
); margin-left: 5px; padding-left: 5px;"><br>From: Elwyn Davies &lt;elwynd@=
folly.org.uk&gt;<br>Subject: Re: [dtn-interest] about QoS<br>To: "Ma Xuebin=
" &lt;[email-masked]&gt;<br>Cc: "dtn-interest" &lt;dtn-interest@maillis=
ts.intel-research.net&gt;<br>Date: Saturday, February 12, 2011, 10:41 AM<br=
><br><div class=3D"plainMail">Hi.<br><br>I wrote a previous state of the ar=
t document which has a pretty complete<br>list of ongoing projects as of ea=
rly 2009.&nbsp; You can download it from<br><a href=3D"http://www.n4c.eu/Do=
wnload/n4c-wp2-012-state-of-the-art-101.pdf" target=3D"_blank">http://www.n=
4c.eu/Download/n4c-wp2-012-state-of-the-art-101.pdf</a>.<br><br>A number of=
 other papers and stuff about projects since then can be<br>found on the DT=
NRG wiki <a href=3D"http://www.dtnrg.org/wiki/Docs"
 target=3D"_blank">http://www.dtnrg.org/wiki/Docs</a>.<br><br>A quick Googl=
e search gets you some other papers, e.g.<br><a href=3D"http://www.scribd.c=
om/doc/43092916/T-Drop-An-optimal-buffer-management-policy-to-improve-QOS-i=
n-DTN-routing-protocols" target=3D"_blank">http://www.scribd.com/doc/430929=
16/T-Drop-An-optimal-buffer-management-policy-to-improve-QOS-in-DTN-routing=
-protocols</a><br><a href=3D"http://www.mecs-press.com/ijcnis/ijcnis-200901=
005.pdf" target=3D"_blank">http://www.mecs-press.com/ijcnis/ijcnis-20090100=
5.pdf</a><br><a href=3D"http://portal.acm.org/citation.cfm?id=3D1815559" ta=
rget=3D"_blank">http://portal.acm.org/citation.cfm?id=3D1815559</a><br><a h=
ref=3D"http://ieeexplore.ieee.org/Xplore/login.jsp?url=3Dhttp%3A%2F%" targe=
t=3D"_blank">http://ieeexplore.ieee.org/Xplore/login.jsp?url=3Dhttp%3A%2F%<=
/a><br>2Fieeexplore.ieee.org%2Fiel5%2F5576746%2F5586844%2F05586899.pdf%<br>=
3Farnumber%3D5586899&amp;authDecision=3D-203<br><br>Regards,<br>Elwyn<br><b=
r>On Sat, 2011-02-12
 at 17:56 +0800, Ma Xuebin wrote:<br>&gt; Hello,<br>&gt; who knows the pape=
rs or project about the QoS in DTN or opportunistic<br>&gt; networks, I nee=
d these information to introduce the state-of-art.<br>&gt; thanks a lot.<br=
>&gt;&nbsp; <br>&gt; 2011-02-12 <br>&gt; <br>&gt; _________________________=
_____________________________________________<br>&gt; Ma Xuebin <br>&gt; __=
_____________________________________________<br>&gt; dtn-interest mailing =
list<br>&gt; <a ymailto=3D"mailto:[email-masked]=
" href=3D"/mc/compose?to=[email-masked]">dtn-i=
[email-masked]</a><br>&gt; <a href=3D"http://maillist=
s.intel-research.net/mailman/listinfo/dtn-interest" target=3D"_blank">http:=
//maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br><br>___=
____________________________________________<br>dtn-interest mailing list<b=
r><a ymailto=3D"mailto:[email-masked]"
 href=3D"/mc/compose?to=[email-masked]">dtn-in=
[email-masked]</a><br><a href=3D"http://maillists.inte=
l-research.net/mailman/listinfo/dtn-interest" target=3D"_blank">http://mail=
lists.intel-research.net/mailman/listinfo/dtn-interest</a><br></div></block=
quote></td></tr></table><br>=0A=0A      
--0-1320484613-1297545482=:4898--

From: Elwyn Davies <[email-masked]>
To: Ma Xuebin <[email-masked]>
Organization: Folly Consulting
Date: Sat, 12 Feb 2011 18:41:31 +0000
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] about QoS

Hi.

I wrote a previous state of the art document which has a pretty complete
list of ongoing projects as of early 2009.  You can download it from
http://www.n4c.eu/Download/n4c-wp2-012-state-of-the-art-101.pdf.

A number of other papers and stuff about projects since then can be
found on the DTNRG wiki http://www.dtnrg.org/wiki/Docs.

A quick Google search gets you some other papers, e.g.
http://www.scribd.com/doc/43092916/T-Drop-An-optimal-buffer-management-policy-to-improve-QOS-in-DTN-routing-protocols
http://www.mecs-press.com/ijcnis/ijcnis-200901005.pdf
http://portal.acm.org/citation.cfm?id=1815559
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%
2Fieeexplore.ieee.org%2Fiel5%2F5576746%2F5586844%2F05586899.pdf%
3Farnumber%3D5586899&authDecision=-203

Regards,
Elwyn

On Sat, 2011-02-12 at 17:56 +0800, Ma Xuebin wrote:
> Hello,
> who knows the papers or project about the QoS in DTN or opportunistic
> networks, I need these information to introduce the state-of-art.
> thanks a lot.
>  
> 2011-02-12 
> 
> ______________________________________________________________________
> Ma Xuebin 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Sat, 12 Feb 2011 11:36:11 -0500
From: Brenton Walker <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Call for papers: The 3rd ACM Workshop on Hot Topics in Planet-scale Measurement (HorPlanet 2011)

We apologies if you receive multiple copies.

=========================================================================
                          CALL FOR PAPERS
    The 3rd ACM Workshop on Hot Topics in Planet-scale Measurement
                          HOT PLANET 2011
   Co-located with ACM MobiSys 2011, 28 June 2011, Washington DC USA
                    http://www.hotplanetconf.net/
=========================================================================

It is well-known that successfully researching, designing and building
new mobile, ad-hoc, mesh and opportunistic networking systems and
algorithms requires access to large-scale data on human mobility,
encounter, and social network patterns. Unfortunately, the wireless and
mobile research communities lack such data, with typical human contact
traces consisting of less than 100 nodes. We believe that large-scale
datasets are important, not only in communication network design, but
also for fundamental study in other academic disciplines, e.g.,
epidemiology, urban planning, and social science. Complex networks
research has flourished since 1989 when the first large Internet (and
later WWW) datasets became available. To achieve similar improvements in
mobile networking and related fields, large-scale, and ideally
planet-scale, datasets must be collected and made available.

Following two successful editions of the workshop at ACM MobiSys 2009
and 2010, the third HotPlanet workshop will not only challenge the
community to collect large-scale human mobility traces but also to
propose novel mobility data processing and knowledge discovery techniques.

To make the whole event even more interesting, we will hold a
competition for all the workshop participants. The contest will be about
the mobility data - the details will be unveiled soon. The ceremony for
the winners will take place during the last day of the ACM MobiSys
conference.

Important dates:
----------------
Paper registration deadline: March 24, 2011
Submission deadline: March 31, 2011
Authors notification: May 1, 2011
Camera ready: May 10, 2011
Workshop date: June 28, 2011

Topics for the workshop include, but are not limited to:
--------------------------------------------------------
- Motivating applications for large-scale human mobility data
collection, especially from other disciplines, e.g., epidemiology, sociology
- Methods for collecting large-scale human mobility datasets
- Techniques for mobility data storage and processing
- Knowledge discovery from mobility data
- Novel applications of large-scale human mobility datasets, e.g., human
dynamics characterization and modeling
- Planet-scale data collection infrastructures
- Testbed federation for planet-scale data collection
- Incentive models for encouraging users and businesses to collect and
contribute data on a planet-wide scale
- Enabling security, privacy and anonymity for large-scale data collection
- Regulatory, legal and ethical issues in planet-wide data collection

Workshop Chairs:
----------------
Michal Piorkowski, USI Lugano, Switzerland
Brenton Walker, LTS University of Maryland, USA

Program Committee:
------------------
Imad Aad, Nokia Research Center Lausanne, Switzerland
David J. Crandall, Indiana University, USA
Philippe Cudre-Mauroux, University of Fribourg, Switzerland
Michael Doering, Technische Universität Braunschweig, Germany
Vassilis Kostakos, Carnegie Mellon University, USA
Marco Mamei, Universita' di Modena e Reggio Emilia, Italy
Mirco Nanni, ISTI-CNR Pisa, Italy
Arjan Peddemors, Telematica Instituut, Netherlands
Michal Piorkowski, USI Lugano, Switzerland
Balaji Rengarajan, IMDEA Networks, Spain
Dirk VanBruggen, University of Notre Dame, USA
Brenton Walker, LTS Univeristy of Maryland, USA
John Whitbeck, UPMC Sorbonne Universities, France
Zhixian Yan, EPFL, Switzerland
Lin Zhong, Rice University, USA

Date: Sat, 12 Feb 2011 17:56:32 +0800
From: "Ma Xuebin" <[email-masked]>
To: "dtn-interest" <[email-masked]>
Organization: Inner Mongolia University
Subject: [dtn-interest] about QoS

This is a multi-part message in MIME format.

--=====003_Dragon035841170643_=====
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,
who knows the papers or project about the QoS in DTN or opportunistic networks, I need these information to introduce the state-of-art. thanks a lot.

2011-02-12 

Ma Xuebin 

--=====003_Dragon035841170643_=====
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.6058" name=GENERATOR><LINK 
href="BLOCKQUOTE{margin-Top: 0px; margin-Bottom: 0px; margin-Left: 2em}" 
rel=stylesheet></HEAD>
<BODY style="FONT-SIZE: 10pt; MARGIN: 10px; FONT-FAMILY: verdana">
<DIV><FONT size=2>Hello,</FONT></DIV>
<DIV>who&nbsp;knows the papers or project about the QoS in DTN or opportunistic 
networks, I need these information to introduce the state-of-art. thanks a 
lot.</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV align=left><FONT color=#c0c0c0 size=2>2011-02-12 </FONT></DIV><FONT size=2>
<HR style="WIDTH: 122px; HEIGHT: 2px" align=left SIZE=2>

<DIV><FONT color=#c0c0c0 size=2><SPAN>Ma Xuebin</SPAN> 
</FONT></DIV></FONT></BODY></HTML>

--=====003_Dragon035841170643_=====--

Date: Fri, 11 Feb 2011 22:24:01 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>, DTN Security Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Migrating mailing list and wiki

Hi again,

Just an FYI, we've now migrated the wiki to its new
home. Please let Alex (cc'd) and I know if you spot
anything odd or broken. All current write access etc
should be just the same (mine worked anyway;-).

More on the mailing list next week, but the current
plan is to move to e.g. [email-masked] so when
we're ready we'll subscribe all the current list members
to the new list(s), send out a last message to each
of the lists being migrated (see the To: line above)
and then shut these lists. List archives (both old
and new) will be hosted at the new list info site.

Again, any issues there please let us know. Sorry
that you'll have to adjust your filters, but there
ya go. I hope that'll all happen next week.

Regards,
Stephen.

On 04/02/11 10:28, Stephen Farrell wrote:
> 
> Hi all,
> 
> Due to some machine changes with the current infrastructure
> we're planning to migrate the DTNRG related lists (dtn-interest,
> dtn-security and dtn-users) to the IETF/IRTF infrastructure in
> the next few weeks. That'll mean you'll need to change filters
> etc. but everything else should be the same.
> 
> We're also planning to move the wiki, which, all going well,
> should just result in a little downtime.
> 
> Once we're all set, we'll send another mail with the final
> details.
> 
> If there're any issues with the above please mail Kevin and
> I, and also cc Alex McMahon ([email-masked]) who'll
> be doing most of the real work involved.
> 
> Regards,
> Stephen.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Fri, 11 Feb 2011 22:14:02 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

Hi all,

So thanks again for welcoming Jörg. Aaron fully agreed
and so Jörg is now officially our 3rd RG co-chair. [1,2]

Cheers,
Stephen.

[1] http://www.irtf.org/charter?gtype=rg&group=dtnrg
[2] http://www.dtnrg.org/

On 07/02/11 11:34, Stephen Farrell wrote:
> 
> Hi all,
> 
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
> 
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
> 
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
> 
> Thanks,
> Stephen and Kevin.
> 
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Golding, Len" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 11 Feb 2011 13:43:47 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] unsubscribe

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

--_000_E48B962F2B71EC4C97EF42A839D0F2DE05747BC3B1IMCMBX1MITREO_
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"Micros=
oft 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 WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></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 vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><o:p>&nbsp;</o:p=
></p></div></body></html>=

--_000_E48B962F2B71EC4C97EF42A839D0F2DE05747BC3B1IMCMBX1MITREO_--

From: Rui Quelhas <[email-masked]>
Date: Fri, 11 Feb 2011 16:47:26 +0000
To: [email-masked], [email-masked]
Subject: [dtn-interest] DTN2 vs Haggle

Hi there,

I'm currently working on a project that requires the deployment of opportunistic and delay-tolerant services and I was wondering how can the DTN2 implementation and Haggle match? I'm perfectly aware that DTN adapts to a broad set of challenged environments like deep-space communications and military networks but my focus is all about terrestrial mobile networks (social and community based) and my concerns are specially about how can Haggle handle store-carry-forward. 

I'm probably talking nonsense and I should try to make theses questions using the Haggle lists but I guess they require some sort of authorization, and I'm still waiting for it. So, hopping that i can actually reach some Haggle users over here I would ask if anyone knows any good resource that establishes some kind of comparison between the two (DTN2 and Haggle)?

---
Best regards,
Rui Quelhas

From: Darren Long <[email-masked]>
Date: Fri, 11 Feb 2011 09:01:12 +0000
To: Stephen Farrell <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] AX.25, LTP and LEO amateur satellites ( was Re: [dtn-users] DTN, QNX, ground stations?)

On 9 Feb 2011, at 10:19, Stephen Farrell wrote:

> Interesting problems. It sounds like you could use the LTP state machine
> and message types, but with different handling of cues and rate control
> compared to the deep-space cases folks have previously considered.
> 
> I guess that some fair rate control could be figured out from watching
> the channel, but to try to be fair you'd need to know what other senders
> are doing (and I don't know that) but I don't see any protocol changes
> needed for that. (Running LTP/UDP in any case needs some rate control,
> so this isn't really new.)

Being absolutely fair isn't really what we're aiming for, fair-ish is probably good enough :) 
We will probably be happy with simply attempting to use as much bandwidth as a typical APRS user would (perhaps slightly more due to overheads), and we'd like to spread out our transmissions across most of the pass.  Most APRS stations beacon at about 30 secs to 60 secs intervals with perhaps one or two short text messages or a bulletin report.

> Similarly, for the cues, if a sender pauses his timers for 2xLTT plus
> 2x the expected CSMA delay it sees, plus a bit of processing overhead,
> then that should work. (Assuming both sender and receiver will
> experience the same CSMA delay.)

It is perhaps unlikely that the block sender and receiver will experience a similar delay, as they're hopefully not accessing the channel at the same time (and thus avoid acting as mutually hidden transmitters). Also there may or may not be a reverse path flow between the same nodes and the link utilisation can vary substantially on a pass as the geospatial coverage shifts. 

Having read Scotts response, I've started to realise that most of what I need to tweak belongs in a Link Service Adaptor shim beneath LTP in the CL. Its also becoming clearer how to do it.

> 
> I'm not clear if you're saying that the sender doesn't get to know
> the delay due to CSMA though, is that what you mean about the KISS
> modem interface?

That's right.  JR elaborated on this.  

> If you had any way to get a reasonable estimate of
> that delay, then wouldn't LTP just work?

I guess it probably would. I'm starting to think differently about how best to do this and think that timers are possibly an aspect that I shouldn't dwell on.  I guess years of listening to connected mode AX.25 running in a lock-step fashion has clouded my judgement :)

> 
> (I'm not sure how ION handles this stuff, but there's an interface
> in LTPlib ("ltp_cue_whos_talking") that could maybe be changed to
> handle cues like this once you figure what to do - but you would
> need code changes/additions. LTPlib's rate control would also need
> to be more complex than the current code too and you might have to
> do some code changes to better handle subsecond timers as well,
> but those are all doable I reckon.)

As it goes, I'm thinking of implementing LTP from scratch to run over AX.25 for this new CL.  I've got a fair bit of code to use from the AX.25 socket abstractions I've put in oasys, and I'm working on adding raw socket support for AX.25 so I can get a discovery mechanism implemented and support receiver diversity on multiple interfaces in the new CL. I think it will be easier to put a new LTP and shim implementation on top of that than to combine AX.25 support with LTPlib. There seems to be a token bucket filter implemented in oasys too, so that should help. 

Having read and thought about both yours and Scott's responses, I feel I've not got a better grasp on how to do this. Thanks for the input.

Cheers,

Darren

From: Darren Long <[email-masked]>
Date: Fri, 11 Feb 2011 09:01:03 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] AX.25, LTP and LEO amateur satellites ( was Re: [dtn-users] DTN, QNX, ground stations?)

On 9 Feb 2011, at 16:44, Burleigh, Scott C (313B) wrote:

> Thanks for this, Darren.  I think I understand the issues, but I'll suggest that LTP itself may still be an okay fit.  The problem (I think) is that LTP alone won't do the job: you need what RFC 5326 calls a "local data-link layer" that is suited to your environment.
> 
> If you read section 5 of the spec literally you might be persuaded that LTP in APRS would be required to run directly on top of AX.25;

We're not really seeking to run LTP over APRS, but must use the same service from AX.25 that it does, on the same channels.  That's mostly besides the point, I guess.

> I think that would be looking at the problem too narrowly.  In the same way that UDP/IP can be considered a valid "local data-link layer" for the purposes of LTP, there's no reason you couldn't use some sort of APRS-suitable layer of additional protocol -- encapsulating AX.25 -- as the local data-link layer for amateur satellite communications.

Agreed. I'm now beginning to realise that there are other factors that are best handled in a shim in the CL below LTP and above AX.25, and the tweaks I'd considered making to LTP itself can be handled better by that shim layer.

> 
> You always have to have something at this layer anyway, if only to implement the interface between LTP and the link protocol.  If the LTP state machine is useful in APRS but you need rate control, I'd say the best approach would be to use LTP but write a rate-control wrapper around disconnected-mode AX.25 to run at the local data-link layer.
> 
> The ION implementation of LTP is pretty heavily built on this notion: there's an API provided for building any number of "link service adapters" that can run under LTP.  The ION package currently ships with only one link service adapter implementation (the one for UDP), but we're about to add a DCCP link service adapter developed at Ohio University -- actually a pretty good analog for what you need, in that it gives LTP congestion control in an Internet environment where it's needed.

Interesting.

> For the DINET experiment on the Deep Impact spacecraft we used standard LTP but built a weird link service adapter that tunneled LTP segments through CFDP, to avoid having to modify the flight software in place.  For the upcoming operational deployment of ION on Deep Impact (in October, if all goes well) we'll be using yet another link service adapter that wraps the LTP segments in CCSDS packets.  This is all much cheaper and safer that hacking LTP itself to behave differently in each of these !
> environments.

A cunning plan indeed.  I feel an interesting Link service adapter coming on.

> 
> The unpredictable latency on your round-trip paths is a little tougher, but again I think this is an implementation concern rather than a protocol issue.  It sounds like the LTP state machine still works for you; you just need a mechanism for setting retransmission deadlines that is a lot more elaborate than just looking at a clock.  We'll have a similar problem when we start using LTP for DTN communications with the International Space Station, but I'm pretty confident that it's solvable.

Thanks for the advice Scott.  If you hear anything more about that rumoured LTP/AX.25 implementation for ION, I'd love to hear more.

Cheers,

Darren

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Wed, 9 Feb 2011 08:44:55 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] AX.25, LTP and LEO amateur satellites ( was Re: [dtn-users] DTN, QNX, ground stations?)

Thanks for this, Darren.  I think I understand the issues, but I'll suggest that LTP itself may still be an okay fit.  The problem (I think) is that LTP alone won't do the job: you need what RFC 5326 calls a "local data-link layer" that is suited to your environment.

If you read section 5 of the spec literally you might be persuaded that LTP in APRS would be required to run directly on top of AX.25; I think that would be looking at the problem too narrowly.  In the same way that UDP/IP can be considered a valid "local data-link layer" for the purposes of LTP, there's no reason you couldn't use some sort of APRS-suitable layer of additional protocol -- encapsulating AX.25 -- as the local data-link layer for amateur satellite communications.

You always have to have something at this layer anyway, if only to implement the interface between LTP and the link protocol.  If the LTP state machine is useful in APRS but you need rate control, I'd say the best approach would be to use LTP but write a rate-control wrapper around disconnected-mode AX.25 to run at the local data-link layer.

The ION implementation of LTP is pretty heavily built on this notion: there's an API provided for building any number of "link service adapters" that can run under LTP.  The ION package currently ships with only one link service adapter implementation (the one for UDP), but we're about to add a DCCP link service adapter developed at Ohio University -- actually a pretty good analog for what you need, in that it gives LTP congestion control in an Internet environment where it's needed.  For the DINET experiment on the Deep Impact spacecraft we used standard LTP but built a weird link service adapter that tunneled LTP segments through CFDP, to avoid having to modify the flight software in place.  For the upcoming operational deployment of ION on Deep Impact (in October, if all goes well) we'll be using yet another link service adapter that wraps the LTP segments in CCSDS packets.  This is all much cheaper and safer that hacking LTP itself to behave differently in each of these environments.

The unpredictable latency on your round-trip paths is a little tougher, but again I think this is an implementation concern rather than a protocol issue.  It sounds like the LTP state machine still works for you; you just need a mechanism for setting retransmission deadlines that is a lot more elaborate than just looking at a clock.  We'll have a similar problem when we start using LTP for DTN communications with the International Space Station, but I'm pretty confident that it's solvable.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Darren Long
Sent: Wednesday, February 09, 2011 1:05 AM
To: Delay Tolerant Networking Interest List
Subject: [dtn-interest] AX.25, LTP and LEO amateur satellites ( was Re: [dtn-users] DTN, QNX, ground stations?)

I've brought this thread spinoff over from users as requested :)

Content below ...

On 8 Feb 2011, at 16:59, Stephen Farrell wrote:

> 
> 
> On 08/02/11 16:49, Burleigh, Scott C (313B) wrote:
>> If someone is working on an AX.25 link service adapter for LTP in ION, I too would be very interested to hear about it; it would be most welcome.
> 
> Ditto.
> 
>> Darren, can you say a little more about which aspects of LTP make it ill-suited for the environment you're looking at?
> 
> Be v. interested in that too. If you do that though I think moving
> the thread to dtn-interest would be better since its (presumably)
> protocol-design that'd discussed and not code.

Firstly, I'd like to correct my previous post when I said:
> The existing AX.25 connected mode CL I've implemented is better suited for terrestrial links.
It shouldn't really be a problem for appropriate space/ground links, but we're thinking about rather specific use-cases here, and its not such a good match for those.

Back to the newly on-topic topic. I was chatting with John Ronan about our desire to pass bundles through amateur satellites that are principally designed to act as bent pipe relays for the Amateur Position Reporting System (http://en.wikipedia.org/wiki/Automatic_Packet_Reporting_System) the other week and we started thinking about the specific issues involved, especially when using KISS TNCs.  

These LEO AX.25 relays have heavily congested uplinks.  The aim under these circumstances is to pass at least some traffic (perhaps a few small frames), at 1200 baud, on each pass of say 10 minutes duration. There may be two or three usable passes per bird per day between nodes that have mutual intervisibility in the footprint.  This should work with 5W FM handheld transceivers and simple omni antennas in the ground segment, although more welly doesn't hurt :) 

The application layer may not be all that different from current simple APRS text messaging, though while we're looking for the advantages of BP to overcome limitations in the direct use of the APRS network, our CL should operate concurrently with it on a shared channel. 

We'd like to try moving bundles over these birds and we've concluded that attempting to use AX.25 Connected Mode would be the wrong way to do it.  There are obvious issues regarding the need to establish a connection over 2 hops initially prior to bundle transfer and to either re-establish a connection on each pass or to do something inappropriate with timers implemented in kernel space.  We feel that using disconnected mode AX.25 under an appropriate CL shim with scheduled connectivity managed by a predict client script is the way forward.

The plan is to provide two service types in the CL, and using LTP terminology, one for fully red blocks and one for fully green, both with rate control, and thus to support either reliable unicast or best effort broadcast link types to the bundling agent.

LTP itself has some motivations and design aspects that are contrary to the environment we believe we're going to operate in, yet its close enough 

Firstly the lightspeed delays aren't a significant factor, but head of line blocking due to CSMA is likely to be a bigger and more unpredictable contribution to latency (at least for half-duplex channels, i.e. the ISS digipeater), as is the radiation time.  This head-of-line blocking has an adverse effect on kernel timers in Connected Mode AX.25, as the sending AX.25 state machine is decoupled from the KISS TNC and there is no back-presure. With large Go-Back-N ARQ windows in connected mode an unpredictable channel can cause retransmissions to be initiated even before the first instance of the frame has actually been transmitted.  We hope to avoid these kinds of problems inherent with connected mode operation using KISS TNCs by switching to disconnected mode and working around them in the CL protocol. This decoupling also means that LTP on disconnected mode would not have accurate cuing for the management of timers, so we still have issues to resolve there.  For full duplex !
 links this is not so much of an issue, although there is scope for collision avoidance in the KISS TNC to cock things up when ground segments are within LOS range but this is uncommon AFAIK.

We think that we can best work around the issues of timer cuing and channel access fairness by adopting a stop-and-wait policy when sending LTP checkpoints in red part transfers.  These would cover a similar volume of data as a connected mode ARQ window, and for half-duplex bent-pipe channels, probably default to single segments between checkpoints.

We'd like to support receiver diversity in the CL in both modes, so we will need to deal with duplicate UI-Frames and out-of-order reception.

Some APRS applications support a "Satellite Ack" mode for the short messaging service, as an alternative to the end-to-end ack, which terminates the retransmission cycle.  The "Satellite Ack" mode simply relies on hearing a transmitted frame sent via the uplink appear on the downlink, and assuming that a terrestrial gateway will hear and forward it.  We think that this could be used to provide a "better best effort" service to the bundling agent for LTP green blocks, by allowing for a small number of segment retransmissions until the "Satellite Ack" was heard on the downlink, or the limit is hit.  I'm wondering if these should be called Yellow Blocks instead :)

Similarly, hearing a sent red-part segment relayed on the downlink would perhaps help us evaluate the latency due to head-of-line blocking and allow us to mitigate some of the anticipated issues with timers.

So, to recap (and probably add some last minute thoughts), the main aspects of LTP we seek to change are:

1) LTP has timer cuing mechanisms that require tight coupling with the KISS modem that we can't satisfy.
2) We have to share the channel with competing users and be fair to them.  LTP isn't intended to accommodate this. Terrestrial APRS networks use flood routing on a single channel and are near saturation. If this works and is fair enough, there's no real theoretical reason why it couldn't overlay the terrestrial APRS network too.
3) The links are likely to be either interactive full or half duplex or unidirectional.
4) The links do not suffer from significant light speed delays.
5) The links may use a bent-pipe relay with receiver diversity in the CL, so some other assumptions of LTP don't hold true. Alternatively, I think that the CL would also work nicely with a bundling agent in LEO.

I'm currently implementing the LTP state machines (with tweaks) in UML (using BOUML) with a view to generating generic/reusable C++ source.

I'm sorry, you asked for a little and I've gone on a bit. I'd certainly be interested in getting some feedback on these thoughts.

Cheers,

Darren

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: John Ronan <[email-masked]>
Date: Wed, 9 Feb 2011 11:08:57 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] AX.25, LTP and LEO amateur satellites ( was Re: [dtn-users] DTN, QNX, ground stations?)

On 9 Feb 2011, at 10:19, Stephen Farrell wrote:

> 
> Hi Darren,
> 
> On 09/02/11 09:05, Darren Long wrote:
>> So, to recap (and probably add some last minute thoughts), the main aspects of LTP we seek to change are:
>> 
>> 1) LTP has timer cuing mechanisms that require tight coupling with the KISS modem that we can't satisfy.
>> 2) We have to share the channel with competing users and be fair to them.  LTP isn't intended to accommodate this. Terrestrial APRS networks use flood routing on a single channel and are near saturation. If this works and is fair enough, there's no real theoretical reason why it couldn't overlay the terrestrial APRS network too.
>> 3) The links are likely to be either interactive full or half duplex or unidirectional.
>> 4) The links do not suffer from significant light speed delays.
>> 5) The links may use a bent-pipe relay with receiver diversity in the CL, so some other assumptions of LTP don't hold true. Alternatively, I think that the CL would also work nicely with a bundling agent in LEO.
>> 
>> I'm currently implementing the LTP state machines (with tweaks) in UML (using BOUML) with a view to generating generic/reusable C++ source.
>> 
>> I'm sorry, you asked for a little and I've gone on a bit. I'd certainly be interested in getting some feedback on these thoughts.
> 
> Interesting problems. It sounds like you could use the LTP state machine
> and message types, but with different handling of cues and rate control
> compared to the deep-space cases folks have previously considered.
> 
> I guess that some fair rate control could be figured out from watching
> the channel, but to try to be fair you'd need to know what other senders
> are doing (and I don't know that) but I don't see any protocol changes
> needed for that. (Running LTP/UDP in any case needs some rate control,
> so this isn't really new.)

Watching the channel won't help, as you can't hear them, you can only hear a packet after it has been re-broadcast. And then you can't infer that no one else transmitted in that time period, only that the one that was re-broadcast, was strong enough to 'capture' the receiver.

Also, it will change depending on the time of day. I would assume that nighttime passes will have less traffic, but I've not done a proper analysis to see if that is actually the case.
> 
> Similarly, for the cues, if a sender pauses his timers for 2xLTT plus
> 2x the expected CSMA delay it sees, plus a bit of processing overhead,
> then that should work. (Assuming both sender and receiver will
> experience the same CSMA delay.)
Unfortunately, that also cannot be assumed, as I can set my channel access parameters different to someone else.  And some people, will always set it more aggressively than others.  It doesn't help that there is at least two different channel access (CSMA) mechanisms.
> 
> I'm not clear if you're saying that the sender doesn't get to know
> the delay due to CSMA though, is that what you mean about the KISS
> modem interface? If you had any way to get a reasonable estimate of
> that delay, then wouldn't LTP just work?
When you chuck data at a KISS modem interface (http://www.ka9q.net/papers/kiss.html) it transmits when it thinks it should based on persistence parameters (one of the CSMA mechanisms), you can't really tell when it has transmitted.

Regards
John

--
John Ronan <[email-masked]>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org

Date: Wed, 09 Feb 2011 10:19:30 +0000
From: Stephen Farrell <[email-masked]>
To: Darren Long <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] AX.25, LTP and LEO amateur satellites ( was Re: [dtn-users] DTN, QNX, ground stations?)

Hi Darren,

On 09/02/11 09:05, Darren Long wrote:
> So, to recap (and probably add some last minute thoughts), the main aspects of LTP we seek to change are:
> 
> 1) LTP has timer cuing mechanisms that require tight coupling with the KISS modem that we can't satisfy.
> 2) We have to share the channel with competing users and be fair to them.  LTP isn't intended to accommodate this. Terrestrial APRS networks use flood routing on a single channel and are near saturation. If this works and is fair enough, there's no real theoretical reason why it couldn't overlay the terrestrial APRS network too.
> 3) The links are likely to be either interactive full or half duplex or unidirectional.
> 4) The links do not suffer from significant light speed delays.
> 5) The links may use a bent-pipe relay with receiver diversity in the CL, so some other assumptions of LTP don't hold true. Alternatively, I think that the CL would also work nicely with a bundling agent in LEO.
> 
> I'm currently implementing the LTP state machines (with tweaks) in UML (using BOUML) with a view to generating generic/reusable C++ source.
> 
> I'm sorry, you asked for a little and I've gone on a bit. I'd certainly be interested in getting some feedback on these thoughts.

Interesting problems. It sounds like you could use the LTP state machine
and message types, but with different handling of cues and rate control
compared to the deep-space cases folks have previously considered.

I guess that some fair rate control could be figured out from watching
the channel, but to try to be fair you'd need to know what other senders
are doing (and I don't know that) but I don't see any protocol changes
needed for that. (Running LTP/UDP in any case needs some rate control,
so this isn't really new.)

Similarly, for the cues, if a sender pauses his timers for 2xLTT plus
2x the expected CSMA delay it sees, plus a bit of processing overhead,
then that should work. (Assuming both sender and receiver will
experience the same CSMA delay.)

I'm not clear if you're saying that the sender doesn't get to know
the delay due to CSMA though, is that what you mean about the KISS
modem interface? If you had any way to get a reasonable estimate of
that delay, then wouldn't LTP just work?

(I'm not sure how ION handles this stuff, but there's an interface
in LTPlib ("ltp_cue_whos_talking") that could maybe be changed to
handle cues like this once you figure what to do - but you would
need code changes/additions. LTPlib's rate control would also need
to be more complex than the current code too and you might have to
do some code changes to better handle subsecond timers as well,
but those are all doable I reckon.)

S.

> 
> Cheers,
> 
> Darren
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Darren Long <[email-masked]>
Date: Wed, 09 Feb 2011 09:05:28 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] AX.25, LTP and LEO amateur satellites ( was Re: [dtn-users] DTN, QNX, ground stations?)

I've brought this thread spinoff over from users as requested :)

Content below ...

On 8 Feb 2011, at 16:59, Stephen Farrell wrote:

> 
> 
> On 08/02/11 16:49, Burleigh, Scott C (313B) wrote:
>> If someone is working on an AX.25 link service adapter for LTP in ION, I too would be very interested to hear about it; it would be most welcome.
> 
> Ditto.
> 
>> Darren, can you say a little more about which aspects of LTP make it ill-suited for the environment you're looking at?
> 
> Be v. interested in that too. If you do that though I think moving
> the thread to dtn-interest would be better since its (presumably)
> protocol-design that'd discussed and not code.

Firstly, I'd like to correct my previous post when I said:
> The existing AX.25 connected mode CL I've implemented is better suited for terrestrial links.
It shouldn't really be a problem for appropriate space/ground links, but we're thinking about rather specific use-cases here, and its not such a good match for those.

Back to the newly on-topic topic. I was chatting with John Ronan about our desire to pass bundles through amateur satellites that are principally designed to act as bent pipe relays for the Amateur Position Reporting System (http://en.wikipedia.org/wiki/Automatic_Packet_Reporting_System) the other week and we started thinking about the specific issues involved, especially when using KISS TNCs.  

These LEO AX.25 relays have heavily congested uplinks.  The aim under these circumstances is to pass at least some traffic (perhaps a few small frames), at 1200 baud, on each pass of say 10 minutes duration. There may be two or three usable passes per bird per day between nodes that have mutual intervisibility in the footprint.  This should work with 5W FM handheld transceivers and simple omni antennas in the ground segment, although more welly doesn't hurt :) 

The application layer may not be all that different from current simple APRS text messaging, though while we're looking for the advantages of BP to overcome limitations in the direct use of the APRS network, our CL should operate concurrently with it on a shared channel. 

We'd like to try moving bundles over these birds and we've concluded that attempting to use AX.25 Connected Mode would be the wrong way to do it.  There are obvious issues regarding the need to establish a connection over 2 hops initially prior to bundle transfer and to either re-establish a connection on each pass or to do something inappropriate with timers implemented in kernel space.  We feel that using disconnected mode AX.25 under an appropriate CL shim with scheduled connectivity managed by a predict client script is the way forward.

The plan is to provide two service types in the CL, and using LTP terminology, one for fully red blocks and one for fully green, both with rate control, and thus to support either reliable unicast or best effort broadcast link types to the bundling agent.

LTP itself has some motivations and design aspects that are contrary to the environment we believe we're going to operate in, yet its close enough 

Firstly the lightspeed delays aren't a significant factor, but head of line blocking due to CSMA is likely to be a bigger and more unpredictable contribution to latency (at least for half-duplex channels, i.e. the ISS digipeater), as is the radiation time.  This head-of-line blocking has an adverse effect on kernel timers in Connected Mode AX.25, as the sending AX.25 state machine is decoupled from the KISS TNC and there is no back-presure. With large Go-Back-N ARQ windows in connected mode an unpredictable channel can cause retransmissions to be initiated even before the first instance of the frame has actually been transmitted.  We hope to avoid these kinds of problems inherent with connected mode operation using KISS TNCs by switching to disconnected mode and working around them in the CL protocol. This decoupling also means that LTP on disconnected mode would not have accurate cuing for the management of timers, so we still have issues to resolve there.  For full duplex links this is not so much of an issue, although there is scope for collision avoidance in the KISS TNC to cock things up when ground segments are within LOS range but this is uncommon AFAIK.

We think that we can best work around the issues of timer cuing and channel access fairness by adopting a stop-and-wait policy when sending LTP checkpoints in red part transfers.  These would cover a similar volume of data as a connected mode ARQ window, and for half-duplex bent-pipe channels, probably default to single segments between checkpoints.

We'd like to support receiver diversity in the CL in both modes, so we will need to deal with duplicate UI-Frames and out-of-order reception.

Some APRS applications support a "Satellite Ack" mode for the short messaging service, as an alternative to the end-to-end ack, which terminates the retransmission cycle.  The "Satellite Ack" mode simply relies on hearing a transmitted frame sent via the uplink appear on the downlink, and assuming that a terrestrial gateway will hear and forward it.  We think that this could be used to provide a "better best effort" service to the bundling agent for LTP green blocks, by allowing for a small number of segment retransmissions until the "Satellite Ack" was heard on the downlink, or the limit is hit.  I'm wondering if these should be called Yellow Blocks instead :)

Similarly, hearing a sent red-part segment relayed on the downlink would perhaps help us evaluate the latency due to head-of-line blocking and allow us to mitigate some of the anticipated issues with timers.

So, to recap (and probably add some last minute thoughts), the main aspects of LTP we seek to change are:

1) LTP has timer cuing mechanisms that require tight coupling with the KISS modem that we can't satisfy.
2) We have to share the channel with competing users and be fair to them.  LTP isn't intended to accommodate this. Terrestrial APRS networks use flood routing on a single channel and are near saturation. If this works and is fair enough, there's no real theoretical reason why it couldn't overlay the terrestrial APRS network too.
3) The links are likely to be either interactive full or half duplex or unidirectional.
4) The links do not suffer from significant light speed delays.
5) The links may use a bent-pipe relay with receiver diversity in the CL, so some other assumptions of LTP don't hold true. Alternatively, I think that the CL would also work nicely with a bundling agent in LEO.

I'm currently implementing the LTP state machines (with tweaks) in UML (using BOUML) with a view to generating generic/reusable C++ source.

I'm sorry, you asked for a little and I've gone on a bit. I'd certainly be interested in getting some feedback on these thoughts.

Cheers,

Darren

Date: Tue, 08 Feb 2011 22:03:54 +0200
From: Joerg Ott <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

Thanks, folks, for all the support!  Let's hope that things work out.

Cheers,
Joerg

On 08.02.2011 14:38, Stephen Farrell wrote:
>
> Ok, thanks all. I think we've a clear consensus that Joerg
> has the backing of the RG. Just to be safe, we'll wait
> until Friday and then formally ask the IRTF chair to add
> Joerg as an RG chair, but there's no real need for further
> support messages on this.
>
> Regards,
> Stephen.
>
> On 07/02/11 11:34, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> As some of you may know I've recently been selected
>> to be an IETF security area director. That means that I
>> won't have so much time to help out here, so Kevin and
>> I chatted about that and have asked Joerg Ott [1] if
>> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
>> has said he'd be willing, which is great news. As I'm
>> sure most of you already know, Joerg does a lot of
>> fine DTN work and has the IETF and IRTF experience
>> that's needed for the job.
>>
>> The process here is that Kevin and I should propose
>> someone that the RG finds acceptable to the IRTF chair,
>> who then appoints that person (or not I guess;-).
>>
>> So can you please respond to this if you do agree
>> that Joerg would (as Kevin and I both think) be a
>> fine DTNRG  co-chair. (Just a few "oks" will be
>> enough.)
>>
>> Thanks,
>> Stephen and Kevin.
>>
>> [1] http://www.netlab.tkk.fi/~jo/
>> _______________________________________________
>> 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, 08 Feb 2011 12:03:34 -0800
From: "Bradley D. Thornton" <[email-masked]>
Organization: NorthTech Computer
To: [email-masked]
Subject: Re: [dtn-interest] Additional DTNRG chair

I think Joerg will make a fine co-chair.

He gets my nod of approval :)

On 02/07/2011 03:34 AM, Stephen Farrell wrote:
> 
> Hi all,
> 
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
> 
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
> 
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
> 
> Thanks,
> Stephen and Kevin.
> 
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

- -- 
Bradley D. Thornton
Manager Network Services
NorthTech Computer
TEL: +1.760.666.2703  (US)
TEL: +44.702.405.1909 (UK)
http://NorthTech.US

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Feb 2011 13:49:20 -0500
To: ashish makani <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

<aol>
Me too!
</aol>
On Feb 7, 2011, at 10:10 PM, ashish makani wrote:

> +1
> 
> Congratulations to Joerg & you Stephen, on your new jobs :)
> 
> Wishing you both all the very best
> 
> Best,
> ashish
> 
> On Mon, Feb 7, 2011 at 6:46 PM, Avri Doria <[email-masked]> wrote:
> good choice.
> 
> a.
> 
> On 7 Feb 2011, at 03:34, Stephen Farrell wrote:
> 
> >
> > Hi all,
> >
> > As some of you may know I've recently been selected
> > to be an IETF security area director. That means that I
> > won't have so much time to help out here, so Kevin and
> > I chatted about that and have asked Joerg Ott [1] if
> > he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> > has said he'd be willing, which is great news. As I'm
> > sure most of you already know, Joerg does a lot of
> > fine DTN work and has the IETF and IRTF experience
> > that's needed for the job.
> >
> > The process here is that Kevin and I should propose
> > someone that the RG finds acceptable to the IRTF chair,
> > who then appoints that person (or not I guess;-).
> >
> > So can you please respond to this if you do agree
> > that Joerg would (as Kevin and I both think) be a
> > fine DTNRG  co-chair. (Just a few "oks" will be
> > enough.)
> >
> > Thanks,
> > Stephen and Kevin.
> >
> > [1] http://www.netlab.tkk.fi/~jo/
> > _______________________________________________
> > 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
> 
> 
> 
> "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about." 
> -- Albert Einstein
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Elwyn Davies <[email-masked]>
To: Stephen Farrell <[email-masked]>
Organization: Folly Consulting
Date: Tue, 08 Feb 2011 14:20:32 +0000
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

yes.. a good choice.

Elwyn

On Mon, 2011-02-07 at 11:34 +0000, Stephen Farrell wrote:
> Hi all,
> 
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
> 
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
> 
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
> 
> Thanks,
> Stephen and Kevin.
> 
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 08 Feb 2011 12:38:22 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

Ok, thanks all. I think we've a clear consensus that Joerg
has the backing of the RG. Just to be safe, we'll wait
until Friday and then formally ask the IRTF chair to add
Joerg as an RG chair, but there's no real need for further
support messages on this.

Regards,
Stephen.

On 07/02/11 11:34, Stephen Farrell wrote:
> 
> Hi all,
> 
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
> 
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
> 
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
> 
> Thanks,
> Stephen and Kevin.
> 
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Fred Bourbour" <[email-masked]>
To: "HUANG, CHIN-TSER" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "DTN" <[email-masked]>
Date: Mon, 7 Feb 2011 22:29:31 -0600
Subject: Re: [dtn-interest] Additional DTNRG chair

excellent choice.

----- Original Message ----- 
From: "HUANG, CHIN-TSER" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>; "DTN" 
<[email-masked]>
Sent: Monday, February 07, 2011 10:18 AM
Subject: Re: [dtn-interest] Additional DTNRG chair

> supportive. I think Joerg will do a great job for DTNRG!
> ________________________________________
> From: [email-masked] 
> [[email-masked]] On Behalf Of Stephen 
> Farrell [[email-masked]]
> Sent: Monday, February 07, 2011 6:34 AM
> To: DTN
> Subject: [dtn-interest] Additional DTNRG chair
>
> Hi all,
>
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
>
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
>
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
>
> Thanks,
> Stephen and Kevin.
>
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> 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, 7 Feb 2011 19:10:33 -0800
From: ashish makani <[email-masked]>
To: Avri Doria <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

--20cf3054a2d1095d57049bbcb1af
Content-Type: text/plain; charset=ISO-8859-1

+1

Congratulations to Joerg & you Stephen, on your new jobs :)

Wishing you both all the very best

Best,
ashish

On Mon, Feb 7, 2011 at 6:46 PM, Avri Doria <[email-masked]> wrote:

> good choice.
>
> a.
>
> On 7 Feb 2011, at 03:34, Stephen Farrell wrote:
>
> >
> > Hi all,
> >
> > As some of you may know I've recently been selected
> > to be an IETF security area director. That means that I
> > won't have so much time to help out here, so Kevin and
> > I chatted about that and have asked Joerg Ott [1] if
> > he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> > has said he'd be willing, which is great news. As I'm
> > sure most of you already know, Joerg does a lot of
> > fine DTN work and has the IETF and IRTF experience
> > that's needed for the job.
> >
> > The process here is that Kevin and I should propose
> > someone that the RG finds acceptable to the IRTF chair,
> > who then appoints that person (or not I guess;-).
> >
> > So can you please respond to this if you do agree
> > that Joerg would (as Kevin and I both think) be a
> > fine DTNRG  co-chair. (Just a few "oks" will be
> > enough.)
> >
> > Thanks,
> > Stephen and Kevin.
> >
> > [1] http://www.netlab.tkk.fi/~jo/
> > _______________________________________________
> > 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
>

*"We act as though comfort and luxury were the chief requirements of life,
when all that we need to make us happy is something to be enthusiastic
about."
-- Albert Einstein*

--20cf3054a2d1095d57049bbcb1af
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1<br><br>Congratulations to Joerg &amp; you Stephen, on your new jobs :)<b=
r><br>Wishing you both all the very best<br><br>Best,<br>ashish<br><br><div=
 class=3D"gmail_quote">On Mon, Feb 7, 2011 at 6:46 PM, Avri Doria <span dir=
=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">good choice.<br>
<font color=3D"#888888"><br>
a.<br>
</font><div><div></div><div class=3D"h5"><br>
On 7 Feb 2011, at 03:34, Stephen Farrell wrote:<br>
<br>
&gt;<br>
&gt; Hi all,<br>
&gt;<br>
&gt; As some of you may know I&#39;ve recently been selected<br>
&gt; to be an IETF security area director. That means that I<br>
&gt; won&#39;t have so much time to help out here, so Kevin and<br>
&gt; I chatted about that and have asked Joerg Ott [1] if<br>
&gt; he&#39;d be willing to be a 3rd co-chair for DTNRG. Joerg<br>
&gt; has said he&#39;d be willing, which is great news. As I&#39;m<br>
&gt; sure most of you already know, Joerg does a lot of<br>
&gt; fine DTN work and has the IETF and IRTF experience<br>
&gt; that&#39;s needed for the job.<br>
&gt;<br>
&gt; The process here is that Kevin and I should propose<br>
&gt; someone that the RG finds acceptable to the IRTF chair,<br>
&gt; who then appoints that person (or not I guess;-).<br>
&gt;<br>
&gt; So can you please respond to this if you do agree<br>
&gt; that Joerg would (as Kevin and I both think) be a<br>
&gt; fine DTNRG =A0co-chair. (Just a few &quot;oks&quot; will be<br>
&gt; enough.)<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Stephen and Kevin.<br>
&gt;<br>
&gt; [1] <a href=3D"http://www.netlab.tkk.fi/%7Ejo/" target=3D"_blank">http=
://www.netlab.tkk.fi/~jo/</a><br>
&gt; _______________________________________________<br>
&gt; dtn-interest mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">dtn-inter=
[email-masked]</a><br>
&gt; <a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-in=
terest" target=3D"_blank">http://maillists.intel-research.net/mailman/listi=
nfo/dtn-interest</a><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><i>&quot;We act as=
 though comfort and luxury were the chief requirements of life, when all th=
at we need to make us happy is something to be enthusiastic about.&quot; <b=
r>
-- Albert Einstein</i><br>

--20cf3054a2d1095d57049bbcb1af--

From: Avri Doria <[email-masked]>
Date: Mon, 7 Feb 2011 18:46:07 -0800
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

good choice.

a.

On 7 Feb 2011, at 03:34, Stephen Farrell wrote:

> 
> Hi all,
> 
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
> 
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
> 
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
> 
> Thanks,
> Stephen and Kevin.
> 
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 07 Feb 2011 18:26:13 +0000
From: Stephen Farrell <[email-masked]>
To: Elwyn Davies <[email-masked]>
Cc: Peter Lovell <[email-masked]>, DTN interest <[email-masked]>, Sean Turner <[email-masked]>
Subject: Re: [dtn-interest] Fwd: Nits on draft-irtf-dtnrg-bundle-security

So I still reckon we should hang on. Either other ADs will read
it and comment or else none will and we can just handle Sean's
comments. Either way, seems like waiting a week is less work:-)
OTOH, if someone has the cycles this week to work on this, then
don't let me stop you!

S.

On 07/02/11 13:38, Elwyn Davies wrote:
> On Mon, 2011-01-31 at 11:14 +0000, Stephen Farrell wrote:
>> I suspect that we won't get to do those before the IESG chat so
>> lets see if any other ADs have useful comments and then address
>> 'em then.
>>
>> S.
> Since the draft got moved to the next IESG meeting and there hasn't been
> any extra comment, is it desirable to do any improvements (or at least
> discuss possible changes before the IESG meeting)?
> 
> Regards,
> Elwyn
>>
>> PS: If Peter doesn't have time, I can probably take a stab at
>> this.
>>
>> On 31/01/11 10:50, Elwyn Davies wrote:
>>> Hi
>>>
>>> Thanks to Sean for the review.  I see from the datatracker that you
>>> don't think these are blocking issues.
>>>
>>> Authors:  any responses to the comments?  I guess we need to fix up the
>>> nits anyway.  I think Peter has the editorial pencil at the moment.. do
>>> you have cycles to do the fixes?
>>>
>>> Regards,
>>> Elwyn
>>> Document Shepherd
>>>
>>> Couple of (trivial) comments in line below...
>>>
>>> On Sat, 2011-01-29 at 17:28 -0500, Sean Turner wrote:
>>>
>>>> -------- Original Message --------
>>>> Subject: Nits on draft-irtf-dtnrg-bundle-security
>>>> Date: Sat, 29 Jan 2011 17:23:28 -0500
>>>> From: Sean Turner <[email-masked]>
>>>> To: [email-masked]
>>>> CC: [email-masked], The IESG <[email-masked]>
>>>>
>>>> Hi,
>>>>
>>>> Here's some comments/questions I have on this document (note this isn't
>>>> my RFC 5742 review):
>>>>
>>>> - No 'Intended status' indicated for this document; I'm assuming
>>>> Experimental as per the datatracker.  I think you should probably add
>>>> the header line to make sure though.
>>>>
>>>> - There are two unused references: RFC 3370 and RFC 4106.
>>>>
>>>> I think 3370 could we worked in somewhere when describing the CMS bits.
>>>>
>>>> For the 4106 I think the checker is barfing on the following from
>>>> Section 4.3 and 4.4:
>>>>
>>>> [Note: parts of the following description are borrowed from RFC 4106].
>>>>
>>>> Maybe replace it with:
>>>>
>>>> Note: parts of the following description is borrowed from [RFC4106].
>>>>
>>>> - Obsolete reference to [RFC3280].  Should be to [RFC5280].
>>>>
>>>> - Couldn't find the [DTNRB] reference.  Did the document die a graceful
>>>> death?
>>> No.  The version is out of date.  Version 06 exists.
>>>>
>>>> - Expand DTN, EID, SDNV, BA, and PI on first use
>>>>
>>>> - Authentication is mentioned for the first time in Sec 2 when
>>>> discussing the PIB.  Wouldn't it be better to mention it earlier?
>>>>
>>>> - Section 2.1: When describing the two EIDs and cipher suite flags as
>>>> "(optional)" they should be "(OPTIONAL)" if conveying 2119 requirements.
>>>>   Same for the Figure 3 description (i.e., the paragraph before the figure).
>>>>
>>>> - Section 2.3: r/the key information item Section 2.6 is optional, and
>>>> if not provided then the key should be/the key information item Section
>>>> 2.6 is OPTIONAL, and if not provided then the key SHOULD be
>>>>
>>>> - Sections 2.4 & 2.5: r/and that encryption-only ciphersuites NOT be
>>>> used/and it is NOT RECOMMENDED that encryption-only ciphersuites be used
>>>> Using NOT so far after the RECOMMENDED isn't "NOT RECOMMENDED".  Also if
>>>> you do this need to add "NOT RECOMMENDED" to the first para in section 1
>>>> like the errata 499:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=2119
>>>>
>>>> - Section 2.4: Some "SHOULDs":
>>>>
>>>>     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.
>>>>
>>>> - Section 2.4: "SHOULD NOT" instead of "should not":
>>>>
>>>>     These multiple PCB instances, are
>>>>     not "related" and SHOULD NOT contain correlators.
>>>>                       ^^^^^^^^^^
>>>>
>>>> - Section 2.8: In the paragraph about authenticated and encrypted
>>>> bundles, I think the last sentence should be "RECOMMENDED".  It's
>>>> interesting to note that you'd prefer encrypt then sign as opposed to
>>>> sign and then encrypt.  Looking forward to the security consideration
>>>> about why.
>>>>
>>>> - Section 3.2: r/MUST not/MUST NOT ?
>>>>
>>>> - Section 3.2: r/No other blocks are
>>>>     required to follow the payload block and it is RECOMMENDED that they
>>>>     NOT do so./No other blocks are
>>>>     required to follow the payload block and it is NOT RECOMMENDED
>>>>     that they do so.
>>>>
>>>> - Section 3.4.2: r/This algorithm is intended to protect parts of the
>>>> bundle which should not be changed in-transit./This algorithm is
>>>> intended to protect parts of the bundle which SHOULD NOT be changed
>>>> in-transit.
>>>>
>>>> - Sections 3.4.1 & 3.4.2: Need a reference for URI.
>>>>
>>>> - Sections 4.1-4.4: What's the OIDs for these "eContents"?  I assume
>>>> id-data, but you should probably be explicit about it.
>>>>
>>>> - Section 4.1: r/Security parameters are optional with this
>>>> scheme/Security parameters are OPTIONAL with this scheme
>>>>
>>>> - Section 4.1: A couple of comments/questions on the following:
>>>>
>>>>     Implementations MUST support use of "AuthenticatedData" type as
>>>>     defined in [RFC5652] section 9.1, with RecipientInfo type
>>>>     KeyTransRecipientInfo containing the issuer and serial number of a
>>>>     suitable certificate.  They MAY support additional RecipientInfo
>>>>     types.  They MAY additionally use the "SignedData" type described in
>>>>     [RFC5652] Section 5.1.  In either case, the "eContent" field in
>>>>     EncapsulatedContentInfo contains the encrypted HMAC key.
>>>>
>>>> 1. Normally, we'd use the SKI instead of the issuer/serial # combo.  Any
>>>> reason you chose differently?  Most certificates have SKIs (now) and
>>>> it's probably smaller than the issuer/serial # combo.
>>>>
>>>> 2. How is SignedData used here?  It says it MAY be used - is that in
>>>> addition to?  There's no RecipientInfo with SignedData so I am a little
>>>> confused.
>>>>
>>>> - Section 4.1 and 4.2: Should probably say something about whether you'd
>>>> recommend no unsigned/unauthenticated and signed/authenticated
>>>> attributes.  I'm assuming you're not recommending any ;)
>>>>
>>>> - Sections 4.2, 4.3, & 4.4: Normally, we'd use the SKI instead of the
>>>> issuer/serial # combo.  Any reason you chose differently?  Most
>>>> certificates have SKIs and it's probably smaller than the issuer/serial
>>>> # combo.
>>>>
>>>> - Section 4.2: Had the following:
>>>>
>>>>    RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
>>>>    signature scheme in [RFC4055].
>>>>
>>>> Is this RSA with SHA-256 PKCS#1 Version 1.5 or RSA with SHA-256 using
>>>> RSASSA-PSS?  If it's the later is the id-sha256 the hashAlgorithm in the
>>>> RSASSA-PSS-params or something else.  Also wouldn't you have to say more
>>>> like what's the hashAlgorithm, maskGenAlgorithm, whether
>>>> RSASSA-PSS-params is included in certificates?
>>>>
>>>> Also r/RSA with SHA256/RSA with SHA-256
>>>>
>>>> - Sections 4.1-4.4: The eContent values for the CMS content types threw
>>>> me for a loop.  You're not using them to protect the BAB, PIB, etc. it's
>>>> just the encrypted HMAC key, signed checksum, and encrypted BEK.  It
>>>> reads like there are two sets of operation for each of the four Block
>>>> Types.  You do one for the BAB, PIB, etc. values and then another for
>>>> the CMS structures?  Am I reading that right?  The parts about the
>>>> "eContent" e.g.,:
>>>>
>>>> The "eContent" field in EncapsulatedContentInfo contains the signed
>>>> checksum (SignatureValue) of the data.
>>>>
>>>> That tells me the CMS processing generates a message digest over the PIB
>>>> SignatureValue and then signs the output of the message digest and put
>>>> it in the SignerInfo.signature value field.
>>>>
>>>> Couldn't you just omit all the eContents?  They're optional in all cases
>>>> and can be gotten from elsewhere in the CMS blobs.
>>>>
>>>> - Section 7: You should point to [RFC5652]/[RFC5280] for it's security
>>>> considerations when using CMS/certificates.  This save you recreating
>>>> text about keeping keys secret, etc.  Need some additional motherhood
>>>> and apple pie statements about randomly generating keys and point to
>>>> [RFC4106].  And a pointer to [RFC5084] for concerns about AES-GCM.
>>>>
>>>> - Section 7: I didn't see a security consideration that addresses why
>>>> you'd prefer to encrypt then authenticate.  The text earlier implied and
>>>> attack of some kind.  RFC 5751 also had something to say about this:
>>>>
>>>>     There are security ramifications to choosing whether to sign first or
>>>>     encrypt first.  A recipient of a message that is encrypted and then
>>>>     signed can validate that the encrypted block was unaltered, but
>>>>     cannot determine any relationship between the signer and the
>>>>     unencrypted contents of the message.  A recipient of a message that
>>>>     is signed then encrypted can assume that the signed message itself
>>>>     has not been altered, but that a careful attacker could have changed
>>>>     the unauthenticated portions of the encrypted message.
>>>>
>>> (The following comment was withdrawn.. all new ones have 'specification
>>> required' quoted.)
>>>> - IANA Considerations: When defining an IANA controlled registry the
>>>> document needs to indicate how the registry is updated (e.g., RFC
>>>> required, expert review, etc.).  See Section 4 of RFC 5226.
>>>>
>>>> Cheers,
>>>>
>>>> spt
>>>>
>>>
> 

To: <[email-masked]>
Date: Mon, 7 Feb 2011 13:04:39 -0500
From: Gilbert Clark <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

Sounds good :)

--Gilbert

> On Feb 7, 2011, at 12:02 PM, David Young wrote:
>
>> Joerg has my support.
>>
>> On Mon, Feb 7, 2011 at 6:34 AM, Stephen Farrell
>> <[email-masked]> wrote:
>>>
>>> Hi all,
>>>
>>> As some of you may know I've recently been selected
>>> to be an IETF security area director. That means that I
>>> won't have so much time to help out here, so Kevin and
>>> I chatted about that and have asked Joerg Ott [1] if
>>> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
>>> has said he'd be willing, which is great news. As I'm
>>> sure most of you already know, Joerg does a lot of
>>> fine DTN work and has the IETF and IRTF experience
>>> that's needed for the job.
>>>
>>> The process here is that Kevin and I should propose
>>> someone that the RG finds acceptable to the IRTF chair,
>>> who then appoints that person (or not I guess;-).
>>>
>>> So can you please respond to this if you do agree
>>> that Joerg would (as Kevin and I both think) be a
>>> fine DTNRG  co-chair. (Just a few "oks" will be
>>> enough.)
>>>
>>> Thanks,
>>> Stephen and Kevin.
>>>
>>> [1] http://www.netlab.tkk.fi/~jo/
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

From: Marshall Eubanks <[email-masked]>
Date: Mon, 7 Feb 2011 12:09:31 -0500
To: David Young <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

I think he would make a great co-chair.

Regards
Marshall

On Feb 7, 2011, at 12:02 PM, David Young wrote:

> Joerg has my support.
> 
> On Mon, Feb 7, 2011 at 6:34 AM, Stephen Farrell
> <[email-masked]> wrote:
>> 
>> Hi all,
>> 
>> As some of you may know I've recently been selected
>> to be an IETF security area director. That means that I
>> won't have so much time to help out here, so Kevin and
>> I chatted about that and have asked Joerg Ott [1] if
>> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
>> has said he'd be willing, which is great news. As I'm
>> sure most of you already know, Joerg does a lot of
>> fine DTN work and has the IETF and IRTF experience
>> that's needed for the job.
>> 
>> The process here is that Kevin and I should propose
>> someone that the RG finds acceptable to the IRTF chair,
>> who then appoints that person (or not I guess;-).
>> 
>> So can you please respond to this if you do agree
>> that Joerg would (as Kevin and I both think) be a
>> fine DTNRG  co-chair. (Just a few "oks" will be
>> enough.)
>> 
>> Thanks,
>> Stephen and Kevin.
>> 
>> [1] http://www.netlab.tkk.fi/~jo/
>> _______________________________________________
>> 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
> 

Date: Mon, 7 Feb 2011 12:02:32 -0500
From: David Young <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

Joerg has my support.

On Mon, Feb 7, 2011 at 6:34 AM, Stephen Farrell
<[email-masked]> wrote:
>
> Hi all,
>
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
>
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
>
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
>
> Thanks,
> Stephen and Kevin.
>
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
David Young

From: "HUANG, CHIN-TSER" <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Mon, 7 Feb 2011 11:18:53 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Additional DTNRG chair

supportive. I think Joerg will do a great job for DTNRG!
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: Monday, February 07, 2011 6:34 AM
To: DTN
Subject: [dtn-interest] Additional DTNRG chair

Hi all,

As some of you may know I've recently been selected
to be an IETF security area director. That means that I
won't have so much time to help out here, so Kevin and
I chatted about that and have asked Joerg Ott [1] if
he'd be willing to be a 3rd co-chair for DTNRG. Joerg
has said he'd be willing, which is great news. As I'm
sure most of you already know, Joerg does a lot of
fine DTN work and has the IETF and IRTF experience
that's needed for the job.

The process here is that Kevin and I should propose
someone that the RG finds acceptable to the IRTF chair,
who then appoints that person (or not I guess;-).

So can you please respond to this if you do agree
that Joerg would (as Kevin and I both think) be a
fine DTNRG  co-chair. (Just a few "oks" will be
enough.)

Thanks,
Stephen and Kevin.

[1] http://www.netlab.tkk.fi/~jo/
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 7 Feb 2011 23:18:46 +0700
From: anh-minh nguyen <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

--90e6ba4fc2321bc7e9049bb396a2
Content-Type: text/plain; charset=UTF-8

absolutely support for Joerg!

On Mon, Feb 7, 2011 at 6:34 PM, Stephen Farrell
<[email-masked]>wrote:

>
> Hi all,
>
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
>
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
>
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
>
> Thanks,
> Stephen and Kevin.
>
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--90e6ba4fc2321bc7e9049bb396a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

absolutely support for Joerg!<br><br><div class=3D"gmail_quote">On Mon, Feb=
 7, 2011 at 6:34 PM, Stephen Farrell <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email-masked]">[email-masked]</a>&gt;</span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Hi all,<br>
<br>
As some of you may know I&#39;ve recently been selected<br>
to be an IETF security area director. That means that I<br>
won&#39;t have so much time to help out here, so Kevin and<br>
I chatted about that and have asked Joerg Ott [1] if<br>
he&#39;d be willing to be a 3rd co-chair for DTNRG. Joerg<br>
has said he&#39;d be willing, which is great news. As I&#39;m<br>
sure most of you already know, Joerg does a lot of<br>
fine DTN work and has the IETF and IRTF experience<br>
that&#39;s needed for the job.<br>
<br>
The process here is that Kevin and I should propose<br>
someone that the RG finds acceptable to the IRTF chair,<br>
who then appoints that person (or not I guess;-).<br>
<br>
So can you please respond to this if you do agree<br>
that Joerg would (as Kevin and I both think) be a<br>
fine DTNRG =C2=A0co-chair. (Just a few &quot;oks&quot; will be<br>
enough.)<br>
<br>
Thanks,<br>
Stephen and Kevin.<br>
<br>
[1] <a href=3D"http://www.netlab.tkk.fi/%7Ejo/" target=3D"_blank">http://ww=
w.netlab.tkk.fi/~jo/</a><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>
</blockquote></div>

--90e6ba4fc2321bc7e9049bb396a2--

From: "Kruse, Hans" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 7 Feb 2011 10:46:37 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

Very appropriate.   Joerg, thanks for taking on this task!

On Feb 7, 2011, at 6:34 AM, Stephen Farrell wrote:

> 
> Hi all,
> 
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
> 
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
> 
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
> 
> Thanks,
> Stephen and Kevin.
> 
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> 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
Chief Operating Officer, GRID Lab
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

Date: Mon, 7 Feb 2011 10:38:23 -0500
From: Vint Cerf <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair

works for me!

On Mon, Feb 7, 2011 at 6:34 AM, Stephen Farrell
<[email-masked]> wrote:
>
> Hi all,
>
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
>
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
>
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
>
> Thanks,
> Stephen and Kevin.
>
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Mon, 07 Feb 2011 10:26:20 -0500
Subject: Re: [dtn-interest] Additional DTNRG chair

Joerg certainly has my support.

Regards.....Peter

On Mon, Feb 7, 2011, Stephen Farrell <[email-masked]> wrote:

>
>Hi all,
>
>As some of you may know I've recently been selected
>to be an IETF security area director. That means that I
>won't have so much time to help out here, so Kevin and
>I chatted about that and have asked Joerg Ott [1] if
>he'd be willing to be a 3rd co-chair for DTNRG. Joerg
>has said he'd be willing, which is great news. As I'm
>sure most of you already know, Joerg does a lot of
>fine DTN work and has the IETF and IRTF experience
>that's needed for the job.
>
>The process here is that Kevin and I should propose
>someone that the RG finds acceptable to the IRTF chair,
>who then appoints that person (or not I guess;-).
>
>So can you please respond to this if you do agree
>that Joerg would (as Kevin and I both think) be a
>fine DTNRG  co-chair. (Just a few "oks" will be
>enough.)
>
>Thanks,
>Stephen and Kevin.
>
>[1] http://www.netlab.tkk.fi/~jo/
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Elwyn Davies <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 07 Feb 2011 13:38:47 +0000
Cc: Peter Lovell <[email-masked]>, DTN interest <[email-masked]>, Sean Turner <[email-masked]>
Subject: Re: [dtn-interest] Fwd: Nits on draft-irtf-dtnrg-bundle-security

On Mon, 2011-01-31 at 11:14 +0000, Stephen Farrell wrote:
> I suspect that we won't get to do those before the IESG chat so
> lets see if any other ADs have useful comments and then address
> 'em then.
> 
> S.
Since the draft got moved to the next IESG meeting and there hasn't been
any extra comment, is it desirable to do any improvements (or at least
discuss possible changes before the IESG meeting)?

Regards,
Elwyn
> 
> PS: If Peter doesn't have time, I can probably take a stab at
> this.
> 
> On 31/01/11 10:50, Elwyn Davies wrote:
> > Hi
> > 
> > Thanks to Sean for the review.  I see from the datatracker that you
> > don't think these are blocking issues.
> > 
> > Authors:  any responses to the comments?  I guess we need to fix up the
> > nits anyway.  I think Peter has the editorial pencil at the moment.. do
> > you have cycles to do the fixes?
> > 
> > Regards,
> > Elwyn
> > Document Shepherd
> > 
> > Couple of (trivial) comments in line below...
> > 
> > On Sat, 2011-01-29 at 17:28 -0500, Sean Turner wrote:
> > 
> >> -------- Original Message --------
> >> Subject: Nits on draft-irtf-dtnrg-bundle-security
> >> Date: Sat, 29 Jan 2011 17:23:28 -0500
> >> From: Sean Turner <[email-masked]>
> >> To: [email-masked]
> >> CC: [email-masked], The IESG <[email-masked]>
> >>
> >> Hi,
> >>
> >> Here's some comments/questions I have on this document (note this isn't
> >> my RFC 5742 review):
> >>
> >> - No 'Intended status' indicated for this document; I'm assuming
> >> Experimental as per the datatracker.  I think you should probably add
> >> the header line to make sure though.
> >>
> >> - There are two unused references: RFC 3370 and RFC 4106.
> >>
> >> I think 3370 could we worked in somewhere when describing the CMS bits.
> >>
> >> For the 4106 I think the checker is barfing on the following from
> >> Section 4.3 and 4.4:
> >>
> >> [Note: parts of the following description are borrowed from RFC 4106].
> >>
> >> Maybe replace it with:
> >>
> >> Note: parts of the following description is borrowed from [RFC4106].
> >>
> >> - Obsolete reference to [RFC3280].  Should be to [RFC5280].
> >>
> >> - Couldn't find the [DTNRB] reference.  Did the document die a graceful
> >> death?
> > No.  The version is out of date.  Version 06 exists.
> >>
> >> - Expand DTN, EID, SDNV, BA, and PI on first use
> >>
> >> - Authentication is mentioned for the first time in Sec 2 when
> >> discussing the PIB.  Wouldn't it be better to mention it earlier?
> >>
> >> - Section 2.1: When describing the two EIDs and cipher suite flags as
> >> "(optional)" they should be "(OPTIONAL)" if conveying 2119 requirements.
> >>   Same for the Figure 3 description (i.e., the paragraph before the figure).
> >>
> >> - Section 2.3: r/the key information item Section 2.6 is optional, and
> >> if not provided then the key should be/the key information item Section
> >> 2.6 is OPTIONAL, and if not provided then the key SHOULD be
> >>
> >> - Sections 2.4 & 2.5: r/and that encryption-only ciphersuites NOT be
> >> used/and it is NOT RECOMMENDED that encryption-only ciphersuites be used
> >> Using NOT so far after the RECOMMENDED isn't "NOT RECOMMENDED".  Also if
> >> you do this need to add "NOT RECOMMENDED" to the first para in section 1
> >> like the errata 499:
> >> http://www.rfc-editor.org/errata_search.php?rfc=2119
> >>
> >> - Section 2.4: Some "SHOULDs":
> >>
> >>     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.
> >>
> >> - Section 2.4: "SHOULD NOT" instead of "should not":
> >>
> >>     These multiple PCB instances, are
> >>     not "related" and SHOULD NOT contain correlators.
> >>                       ^^^^^^^^^^
> >>
> >> - Section 2.8: In the paragraph about authenticated and encrypted
> >> bundles, I think the last sentence should be "RECOMMENDED".  It's
> >> interesting to note that you'd prefer encrypt then sign as opposed to
> >> sign and then encrypt.  Looking forward to the security consideration
> >> about why.
> >>
> >> - Section 3.2: r/MUST not/MUST NOT ?
> >>
> >> - Section 3.2: r/No other blocks are
> >>     required to follow the payload block and it is RECOMMENDED that they
> >>     NOT do so./No other blocks are
> >>     required to follow the payload block and it is NOT RECOMMENDED
> >>     that they do so.
> >>
> >> - Section 3.4.2: r/This algorithm is intended to protect parts of the
> >> bundle which should not be changed in-transit./This algorithm is
> >> intended to protect parts of the bundle which SHOULD NOT be changed
> >> in-transit.
> >>
> >> - Sections 3.4.1 & 3.4.2: Need a reference for URI.
> >>
> >> - Sections 4.1-4.4: What's the OIDs for these "eContents"?  I assume
> >> id-data, but you should probably be explicit about it.
> >>
> >> - Section 4.1: r/Security parameters are optional with this
> >> scheme/Security parameters are OPTIONAL with this scheme
> >>
> >> - Section 4.1: A couple of comments/questions on the following:
> >>
> >>     Implementations MUST support use of "AuthenticatedData" type as
> >>     defined in [RFC5652] section 9.1, with RecipientInfo type
> >>     KeyTransRecipientInfo containing the issuer and serial number of a
> >>     suitable certificate.  They MAY support additional RecipientInfo
> >>     types.  They MAY additionally use the "SignedData" type described in
> >>     [RFC5652] Section 5.1.  In either case, the "eContent" field in
> >>     EncapsulatedContentInfo contains the encrypted HMAC key.
> >>
> >> 1. Normally, we'd use the SKI instead of the issuer/serial # combo.  Any
> >> reason you chose differently?  Most certificates have SKIs (now) and
> >> it's probably smaller than the issuer/serial # combo.
> >>
> >> 2. How is SignedData used here?  It says it MAY be used - is that in
> >> addition to?  There's no RecipientInfo with SignedData so I am a little
> >> confused.
> >>
> >> - Section 4.1 and 4.2: Should probably say something about whether you'd
> >> recommend no unsigned/unauthenticated and signed/authenticated
> >> attributes.  I'm assuming you're not recommending any ;)
> >>
> >> - Sections 4.2, 4.3, & 4.4: Normally, we'd use the SKI instead of the
> >> issuer/serial # combo.  Any reason you chose differently?  Most
> >> certificates have SKIs and it's probably smaller than the issuer/serial
> >> # combo.
> >>
> >> - Section 4.2: Had the following:
> >>
> >>    RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
> >>    signature scheme in [RFC4055].
> >>
> >> Is this RSA with SHA-256 PKCS#1 Version 1.5 or RSA with SHA-256 using
> >> RSASSA-PSS?  If it's the later is the id-sha256 the hashAlgorithm in the
> >> RSASSA-PSS-params or something else.  Also wouldn't you have to say more
> >> like what's the hashAlgorithm, maskGenAlgorithm, whether
> >> RSASSA-PSS-params is included in certificates?
> >>
> >> Also r/RSA with SHA256/RSA with SHA-256
> >>
> >> - Sections 4.1-4.4: The eContent values for the CMS content types threw
> >> me for a loop.  You're not using them to protect the BAB, PIB, etc. it's
> >> just the encrypted HMAC key, signed checksum, and encrypted BEK.  It
> >> reads like there are two sets of operation for each of the four Block
> >> Types.  You do one for the BAB, PIB, etc. values and then another for
> >> the CMS structures?  Am I reading that right?  The parts about the
> >> "eContent" e.g.,:
> >>
> >> The "eContent" field in EncapsulatedContentInfo contains the signed
> >> checksum (SignatureValue) of the data.
> >>
> >> That tells me the CMS processing generates a message digest over the PIB
> >> SignatureValue and then signs the output of the message digest and put
> >> it in the SignerInfo.signature value field.
> >>
> >> Couldn't you just omit all the eContents?  They're optional in all cases
> >> and can be gotten from elsewhere in the CMS blobs.
> >>
> >> - Section 7: You should point to [RFC5652]/[RFC5280] for it's security
> >> considerations when using CMS/certificates.  This save you recreating
> >> text about keeping keys secret, etc.  Need some additional motherhood
> >> and apple pie statements about randomly generating keys and point to
> >> [RFC4106].  And a pointer to [RFC5084] for concerns about AES-GCM.
> >>
> >> - Section 7: I didn't see a security consideration that addresses why
> >> you'd prefer to encrypt then authenticate.  The text earlier implied and
> >> attack of some kind.  RFC 5751 also had something to say about this:
> >>
> >>     There are security ramifications to choosing whether to sign first or
> >>     encrypt first.  A recipient of a message that is encrypted and then
> >>     signed can validate that the encrypted block was unaltered, but
> >>     cannot determine any relationship between the signer and the
> >>     unencrypted contents of the message.  A recipient of a message that
> >>     is signed then encrypted can assume that the signed message itself
> >>     has not been altered, but that a careful attacker could have changed
> >>     the unauthenticated portions of the encrypted message.
> >>
> > (The following comment was withdrawn.. all new ones have 'specification
> > required' quoted.)
> >> - IANA Considerations: When defining an IANA controlled registry the
> >> document needs to indicate how the registry is updated (e.g., RFC
> >> required, expert review, etc.).  See Section 4 of RFC 5226.
> >>
> >> Cheers,
> >>
> >> spt
> >>
> > 

From: "Scott, Keith L." <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Mon, 7 Feb 2011 08:01:42 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Additional DTNRG chair

------=_NextPart_000_0000_01CBC69D.3EEB3C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I think Joerg would be an excellent co-chair.  Congrats to you and thanks to
Jeorg!

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Monday, February 07, 2011 6:35 AM
To: DTN
Subject: [dtn-interest] Additional DTNRG chair

Hi all,

As some of you may know I've recently been selected
to be an IETF security area director. That means that I
won't have so much time to help out here, so Kevin and
I chatted about that and have asked Joerg Ott [1] if
he'd be willing to be a 3rd co-chair for DTNRG. Joerg
has said he'd be willing, which is great news. As I'm
sure most of you already know, Joerg does a lot of
fine DTN work and has the IETF and IRTF experience
that's needed for the job.

The process here is that Kevin and I should propose
someone that the RG finds acceptable to the IRTF chair,
who then appoints that person (or not I guess;-).

So can you please respond to this if you do agree
that Joerg would (as Kevin and I both think) be a
fine DTNRG  co-chair. (Just a few "oks" will be
enough.)

Thanks,
Stephen and Kevin.

[1] http://www.netlab.tkk.fi/~jo/
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------=_NextPart_000_0000_01CBC69D.3EEB3C40
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_0000_01CBC69D.3EEB3C40--

From: Dirk Kutscher <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Mon, 7 Feb 2011 12:44:55 +0000
Accept-Language: de-DE, en-US
Subject: Re: [dtn-interest] Additional DTNRG chair

OK.

Best regards,
Dirk

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Stephen
> Farrell
> Sent: Monday, February 07, 2011 12:35 PM
> To: DTN
> Subject: [dtn-interest] Additional DTNRG chair
> 
> 
> Hi all,
> 
> As some of you may know I've recently been selected
> to be an IETF security area director. That means that I
> won't have so much time to help out here, so Kevin and
> I chatted about that and have asked Joerg Ott [1] if
> he'd be willing to be a 3rd co-chair for DTNRG. Joerg
> has said he'd be willing, which is great news. As I'm
> sure most of you already know, Joerg does a lot of
> fine DTN work and has the IETF and IRTF experience
> that's needed for the job.
> 
> The process here is that Kevin and I should propose
> someone that the RG finds acceptable to the IRTF chair,
> who then appoints that person (or not I guess;-).
> 
> So can you please respond to this if you do agree
> that Joerg would (as Kevin and I both think) be a
> fine DTNRG  co-chair. (Just a few "oks" will be
> enough.)
> 
> Thanks,
> Stephen and Kevin.
> 
> [1] http://www.netlab.tkk.fi/~jo/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 7 Feb 2011 04:08:13 -0800 (PST)
From: Hadi <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] Additional DTNRG chair
Reply-To: Hadi <[email-masked]>

--0-2091826962-1297080493=:82247
Content-Type: text/plain; charset=us-ascii

OK

Best Regards,Hadi

From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Cc: 
Sent: Monday, February 7, 2011 3:34 AM
Subject: [dtn-interest] Additional DTNRG chair

Hi all,

As some of you may know I've recently been selected
to be an IETF security area director. That means that I
won't have so much time to help out here, so Kevin and
I chatted about that and have asked Joerg Ott [1] if
he'd be willing to be a 3rd co-chair for DTNRG. Joerg
has said he'd be willing, which is great news. As I'm
sure most of you already know, Joerg does a lot of
fine DTN work and has the IETF and IRTF experience
that's needed for the job.

The process here is that Kevin and I should propose
someone that the RG finds acceptable to the IRTF chair,
who then appoints that person (or not I guess;-).

So can you please respond to this if you do agree
that Joerg would (as Kevin and I both think) be a
fine DTNRG  co-chair. (Just a few "oks" will be
enough.)

Thanks,
Stephen and Kevin.

[1] http://www.netlab.tkk.fi/~jo/
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

      
--0-2091826962-1297080493=:82247
Content-Type: text/html; charset=us-ascii

<html><body><div style="color:#000; background-color:#fff, font-family:verdana, helvetica, sans-serif;font-size:10pt"><span>OK<br class="yui-cursor"></span><div>&nbsp;</div><div><font size="2"><font color="#000000" face="verdana, helvetica, sans-serif">Best Regards,</font></font></div>Hadi<br><div style="font-family: inherit; font-size: 10pt;"><div style="font-family: inherit; font-size: 12pt;"><font face="Arial" size="2"><div style="border: 1px solid rgb(204, 204, 204); line-height: 0pt; font-size: 0pt; margin: 5px 0px; padding: 0pt;" readonly="true" class="hr" contenteditable="false"></div><b><span style="font-weight: bold;">From:</span></b> Stephen Farrell &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">To:</span></b> DTN &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">Cc:</span></b> <br><b><span style="font-weight: bold;">Sent:</span></b> Monday, February 7, 2011 3:34 AM<br><b><span
 style="font-weight: bold;">Subject:</span></b> [dtn-interest] Additional DTNRG chair<br></font><br> 
<br>Hi all,<br><br>As some of you may know I've recently been selected<br>to be an IETF security area director. That means that I<br>won't have so much time to help out here, so Kevin and<br>I chatted about that and have asked Joerg Ott [1] if<br>he'd be willing to be a 3rd co-chair for DTNRG. Joerg<br>has said he'd be willing, which is great news. As I'm<br>sure most of you already know, Joerg does a lot of<br>fine DTN work and has the IETF and IRTF experience<br>that's needed for the job.<br><br>The process here is that Kevin and I should propose<br>someone that the RG finds acceptable to the IRTF chair,<br>who then appoints that person (or not I guess;-).<br><br>So can you please respond to this if you do agree<br>that Joerg would (as Kevin and I both think) be a<br>fine DTNRG&nbsp; co-chair. (Just a few "oks" will be<br>enough.)<br><br>Thanks,<br>Stephen and Kevin.<br><br>[1]
 http://www.netlab.tkk.fi/~jo/<br>_______________________________________________<br>dtn-interest mailing list<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>http://maillists.intel-research.net/mailman/listinfo/dtn-interest<br><br><br></div></div></div><br>

      </body></html>
--0-2091826962-1297080493=:82247--

From: "Durst, Robert C." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Mon, 7 Feb 2011 06:54:29 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Additional DTNRG chair

Enthusiastically "OK"
--------------------------
Sent from my BlackBerry Wireless Handheld

----- Original Message -----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Monday, February 07, 2011 06:34 AM
To: DTN <[email-masked]>
Subject: [dtn-interest] Additional DTNRG chair

Hi all,

As some of you may know I've recently been selected
to be an IETF security area director. That means that I
won't have so much time to help out here, so Kevin and
I chatted about that and have asked Joerg Ott [1] if
he'd be willing to be a 3rd co-chair for DTNRG. Joerg
has said he'd be willing, which is great news. As I'm
sure most of you already know, Joerg does a lot of
fine DTN work and has the IETF and IRTF experience
that's needed for the job.

The process here is that Kevin and I should propose
someone that the RG finds acceptable to the IRTF chair,
who then appoints that person (or not I guess;-).

So can you please respond to this if you do agree
that Joerg would (as Kevin and I both think) be a
fine DTNRG  co-chair. (Just a few "oks" will be
enough.)

Thanks,
Stephen and Kevin.

[1] http://www.netlab.tkk.fi/~jo/
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 07 Feb 2011 11:34:59 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Additional DTNRG chair

Hi all,

As some of you may know I've recently been selected
to be an IETF security area director. That means that I
won't have so much time to help out here, so Kevin and
I chatted about that and have asked Joerg Ott [1] if
he'd be willing to be a 3rd co-chair for DTNRG. Joerg
has said he'd be willing, which is great news. As I'm
sure most of you already know, Joerg does a lot of
fine DTN work and has the IETF and IRTF experience
that's needed for the job.

The process here is that Kevin and I should propose
someone that the RG finds acceptable to the IRTF chair,
who then appoints that person (or not I guess;-).

So can you please respond to this if you do agree
that Joerg would (as Kevin and I both think) be a
fine DTNRG  co-chair. (Just a few "oks" will be
enough.)

Thanks,
Stephen and Kevin.

[1] http://www.netlab.tkk.fi/~jo/

From: "Scott, Keith L." <[email-masked]>
To: Shoaib Malik <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 4 Feb 2011 08:23:25 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-security] hop-by-hop authentication

------=_NextPart_000_00B8_01CBC444.CB46DBF0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00B9_01CBC444.CB46DBF0"

------=_NextPart_001_00B9_01CBC444.CB46DBF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The hop-by-hop authentication is designed to keep 'bogus' traffic out of the
network by providing a mechanism to prevent un-authenticated sources from
injecting it.  Hop-by-hop security assumes that the appropriate keys and
policy are in the network.  You're right in that *if* a malicious node can
forge a signature for a bundle and inject it into the network, then after
the first hop there's nothing in the BAB machinery to restrict that bundle's
movement (though other security policies that use non-single-hop mechanisms
like the payload security block might be in place).

The notion was that some networks may have very constrained, expensive, or
critical links and that it would be desirable to deter someone who could
connect to the network from being able to inject traffic that would cross
those links, consuming resources.  End-to-end security like IPSec doesn't do
this, e.g., because the traffic isn't thrown away until the destination
(after it's consumed resources on the critical link(s)).

                                --keith

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Shoaib Malik
Sent: Friday, February 04, 2011 6:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-security] hop-by-hop authentication

Hi All, 

I have a question about the hop-by-hop authentication in BSP.. 

On each hop, the receiving node validates the integrity of bundle and
performs authentication of forwarder (source or intermediate forwarder)...
What benefits we get from this process ? What level of trust we have to
assume ? ... This security feature can only provide integrity of data and
nothing more than that ? 

If a malicious node can sign the bundle and forward it, then the forwarder
can verify the integrity but, still it will forward... 

In short, What are the assumptions on which BSP works ? .. 

many thanks.. 

kind regards,

Shoaib

------=_NextPart_001_00B9_01CBC444.CB46DBF0
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:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-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-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=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.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" 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;}
@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;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></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=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>The hop-by-hop authentication is designed to keep &#8216;bogus&#8217; =
traffic out of the network by providing a mechanism to prevent =
un-authenticated sources from injecting it.&nbsp; Hop-by-hop security =
assumes that the appropriate keys and policy are in the network.&nbsp; =
You&#8217;re right in that *<b>if</b>* a malicious node can forge a =
signature for a bundle and inject it into the network, then after the =
first hop there&#8217;s nothing in the BAB machinery to restrict that =
bundle&#8217;s movement (though other security policies that use =
non-single-hop mechanisms like the payload security block might be in =
place).<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>The notion was that some networks may have very constrained, =
expensive, or critical links and that it would be desirable to deter =
someone who could connect to the network from being able to inject =
traffic that would cross those links, consuming resources.&nbsp; =
End-to-end security like IPSec doesn&#8217;t do this, e.g., because the =
traffic isn&#8217;t thrown away until the destination (after it&#8217;s =
consumed resources on the critical link(s)).<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--keith<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'><p class=3DMsoNormal style=3D'margin-left:.5in'><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>Shoaib Malik<br><b>Sent:</b> Friday, February 04, 2011 6:27 =
AM<br><b>To:</b> [email-masked]<br><b>Cc:</b> =
[email-masked]<br><b>Subject:</b> =
[dtn-security] hop-by-hop authentication<o:p></o:p></span></p></div><p =
class=3DMsoNormal style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal style=3D'margin-left:.5in'>Hi =
All,&nbsp;<o:p></o:p></p><div><p class=3DMsoNormal =
style=3D'margin-left:.5in'>I have a question about the hop-by-hop =
authentication in BSP..&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal =
style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal style=3D'margin-left:.5in'>On each hop, the receiving =
node validates the integrity of bundle and performs authentication of =
forwarder (source or intermediate forwarder)... What benefits we get =
from this process ? What level of trust we have to assume ? ... This =
security feature can only provide integrity of data and nothing more =
than that ?&nbsp;<o:p></o:p></p></div><div><p class=3DMsoNormal =
style=3D'margin-left:.5in'>If a malicious node can sign the bundle and =
forward it, then the forwarder can verify the integrity but, still it =
will forward...&nbsp;<o:p></o:p></p></div><div><p class=3DMsoNormal =
style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal style=3D'margin-left:.5in'>In short, What are the =
assumptions on which BSP works ? ..&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal =
style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal style=3D'margin-left:.5in'>many =
thanks..&nbsp;<o:p></o:p></p></div><div><p class=3DMsoNormal =
style=3D'margin-left:.5in'><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal style=3D'margin-left:.5in'>kind =
regards,<o:p></o:p></p></div><div><p class=3DMsoNormal =
style=3D'margin-left:.5in'>Shoaib<o:p></o:p></p></div></div></body></html=
>
------=_NextPart_001_00B9_01CBC444.CB46DBF0--

------=_NextPart_000_00B8_01CBC444.CB46DBF0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_00B8_01CBC444.CB46DBF0--

Date: Fri, 4 Feb 2011 11:26:30 +0000
From: Shoaib Malik <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-interest] hop-by-hop authentication

--0016364c43ed5ee7b4049b73276f
Content-Type: text/plain; charset=ISO-8859-1

Hi All,
I have a question about the hop-by-hop authentication in BSP..

On each hop, the receiving node validates the integrity of bundle and
performs authentication of forwarder (source or intermediate forwarder)...
What benefits we get from this process ? What level of trust we have to
assume ? ... This security feature can only provide integrity of data and
nothing more than that ?
If a malicious node can sign the bundle and forward it, then the forwarder
can verify the integrity but, still it will forward...

In short, What are the assumptions on which BSP works ? ..

many thanks..

kind regards,
Shoaib

--0016364c43ed5ee7b4049b73276f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi All,=A0<div>I have a question about the hop-by-hop authentication in BSP=
..=A0</div><div><br></div><div>On each hop, the receiving node validates th=
e integrity of bundle and performs authentication of forwarder (source or i=
ntermediate forwarder)... What benefits we get from this process ? What lev=
el of trust we have to assume ? ... This security feature can only provide =
integrity of data and nothing more than that ?=A0</div>
<div>If a malicious node can sign the bundle and forward it, then the forwa=
rder can verify the integrity but, still it will forward...=A0</div><div><b=
r></div><div>In short, What are the assumptions on which BSP works ? ..=A0<=
/div>
<div><br></div><div>many thanks..=A0</div><div><br></div><div>kind regards,=
</div><div>Shoaib</div>

--0016364c43ed5ee7b4049b73276f--

Date: Fri, 04 Feb 2011 10:28:22 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>, DTN Security Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Migrating mailing list and wiki

Hi all,

Due to some machine changes with the current infrastructure
we're planning to migrate the DTNRG related lists (dtn-interest,
dtn-security and dtn-users) to the IETF/IRTF infrastructure in
the next few weeks. That'll mean you'll need to change filters
etc. but everything else should be the same.

We're also planning to move the wiki, which, all going well,
should just result in a little downtime.

Once we're all set, we'll send another mail with the final
details.

If there're any issues with the above please mail Kevin and
I, and also cc Alex McMahon ([email-masked]) who'll
be doing most of the real work involved.

Regards,
Stephen.

Date: Thu, 03 Feb 2011 23:20:58 +0200
From: Jari Arkko <[email-masked]>
To: [email-masked], [email-masked], Kevin Fall <[email-masked]>, Stephen Farrell <[email-masked]>, IESG <[email-masked]>
Subject: [dtn-interest] IESG review of draft-irtf-dtnrg-iana-bp-registries

I was assigned the task of review draft-irtf-dtnrg-iana-bp-registries 
for the IESG. The purpose is to make the RFC 5742 check for non-IETF 
RFCs, i.e., to ensure that the documents do not allocate IANA numbers 
reserved for standards track RFCs, collide with IETF WG work, etc. My 
recommendation to the IESG is the following:

   1. The IESG has concluded that there is no conflict between this
      document and IETF work.

Note that this review is not a technical review, the IRTF is entirely 
responsible for the technical content. However, as a personal feedback I 
noted the following:

Section 2 should probably mention that there are values represented as 
normal bit fields as well, not just SDNVs. (I was confused at first when 
you talked about the 64 bit limit but the first few values were 8 bit 
entities.)

In Section 3.3 you list only the allocated values, but in other sections 
you list also what values are for private use or unallocated. I would 
use the latter style even in Section 3.3 (even if it is sort of variable 
length, it still has an upper limit of 64). Same for 3.4.

Section 3.5 uses binary format for numbers without explicitly stating 
that its binary. Kind of obvious, but I would use 0b in front.

> concensus
> custidy
Typos.

Jari

From: "HUANG, CHIN-TSER" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 3 Feb 2011 09:42:14 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-security] Security for DTN

Hi Shoaib,

Your assumptions, from the starting point, are confusing.
First, if you are talking about physical confidentiality, it's always possible that N1, S, and perhaps another node N2, are all within each other's radio range at one moment. In this case, what do you mean by saying "there exists a confidential channel between N1 and S"? The transmission between N1 and S is also open to N2.
Second, if you are talking about communication confidentiality, there cannot be any confidentiality of the message contents unless they have pre-established shared secret for encryption purpose, or they set up a shared secret on demand. But what's your assumption on that?
My suggestion is that you think about these fundamental issues first before you proceed.

Hope it helps and good luck,
Chin-Tser
--
Chin-Tser Huang
Associate Professor
Department of Computer Science
   and Engineering
University of South Carolina
Columbia, SC 29208
+1-803-777-4635 voice
+1-803-777-3767 fax
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Shoaib Malik [[email-masked]]
Sent: Wednesday, February 02, 2011 3:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-security] Security for DTN

hi,
I am working on a secure DTN network.

In the DTN network, Suppose a node, say N1, opportunistically becomes available to any other already existing node S, then at that time can we assume that there exist a confidential channel between N1 and S.
In general, "Can we assume that there exist a confidential channel between each hop nodes, in a multi hop network".

Is taking this assumption good or bad while working on security for DTN.

regards,
Shoaib

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Shoaib Malik <[email-masked]>
Date: Thu, 3 Feb 2011 07:40:00 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-security] Security for DTN

Shoaib,

>From the question, I believe you are new to network security.  It is a painful subject that many do not understand well - at least in practical deployments. 

DTN is a network overlay.  So, you have the security, or lack of security on each of the underlying networks (convergence layers) which may include IPv4, IPv6, CCSDS (google it), bluetooth, thumb drive policy, radio link security etcetera.  In addition, you have DTN security.  You can assume nothing  on any of these links.  DTN bundle authentication(between hop security) requires some type of policy configuration and most often, a shared key.  Key distribution has not yet been addressed, nor has there been much work in policy.

The best way to understand the above is  to setup a four hop network and attempt to secure it.  Assuming you are working on an IP network, if you have never setup IPsec, I suggest starting there.  Secure the IP and wireless and then do the DTN.  It will be difficult, but easier to learn the IP network and the concepts with translate to DTN.  I suggest keeping the network fully connected to start.  Once you get everything working, you can add disconnection.  At which point you may decide to turn off IPsec as much of that may break.

This is a lot of work, but when you are done, you will have a fairly decent understanding of security and why it is difficult to deploy in multi-organizational networks.  Note, the vast amount of DTN research to date in the open community has been performed without security.

- Will
On Feb 2, 2011, at 3:00 PM, Shoaib Malik wrote:

> hi, 
> I am working on a secure DTN network. 
> 
> In the DTN network, Suppose a node, say N1, opportunistically becomes available to any other already existing node S, then at that time can we assume that there exist a confidential channel between N1 and S. 
> In general, "Can we assume that there exist a confidential channel between each hop nodes, in a multi hop network". 
> 
> Is taking this assumption good or bad while working on security for DTN. 
> 
> regards,
> Shoaib
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-security

******************************
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: Peter Lovell <[email-masked]>
To: Shoaib Malik <[email-masked]>, [email-masked]
Date: Wed, 02 Feb 2011 17:04:48 -0500
Cc: [email-masked]
Subject: Re: [dtn-interest] [dtn-security] Security for DTN

On Wed, Feb 2, 2011, Shoaib Malik <[email-masked]> wrote:

>hi, 
>I am working on a secure DTN network. 
>
>In the DTN network, Suppose a node, say N1, opportunistically becomes
>available to any other already existing node S, then at that time can we
>assume that there exist a confidential channel between N1 and S. 
>In general, "Can we assume that there exist a confidential channel
>between each hop nodes, in a multi hop network". 
>
>Is taking this assumption good or bad while working on security for DTN. 
>
>regards,
>Shoaib

HI Shoaib,

you can't assume that any particular node implements the security
protocol, or any particular ciphersuite. There is no "automatic"
confidential or secure channel - it depends entirely upon the deployment.

Regards.....Peter

From: Rohit <[email-masked]>
Date: Wed, 2 Feb 2011 15:19:56 -0500
To: Shoaib Malik <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Security for DTN

--0016368e1aa18c86fa049b526073
Content-Type: text/plain; charset=ISO-8859-1

We can consider it as initial secure-context establishment problem. I have
recently come across a paper related to this topic. check the link below...

http://www.ics.uci.edu/~jsolis/publications/dtn_compsac09.pdf

<http://www.ics.uci.edu/~jsolis/publications/dtn_compsac09.pdf>I think the
question you raised by itself is a problem to address. So taking it as an
assumption really depends on the problem you are trying to address.

I am completely new to security in DTN. There are lot of experts in this
mailing list, who can give you better suggestion.

Regards,
Rohit Mullangi,
Graduate Student,
The University of Georgia,
Athens GA.

On Wed, Feb 2, 2011 at 3:00 PM, Shoaib Malik <[email-masked]>wrote:

> hi,
> I am working on a secure DTN network.
>
> In the DTN network, Suppose a node, say N1, opportunistically becomes
> available to any other already existing node S, then at that time can we
> assume that there exist a confidential channel between N1 and S.
> In general, "Can we assume that there exist a confidential channel between
> each hop nodes, in a multi hop network".
>
> Is taking this assumption good or bad while working on security for DTN.
>
> regards,
> Shoaib
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

--0016368e1aa18c86fa049b526073
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We can consider it as initial secure-context establishment problem. I have =
recently come across a paper related to this topic. check the link below...=
=A0<div><br></div><div><a href=3D"http://www.ics.uci.edu/~jsolis/publicatio=
ns/dtn_compsac09.pdf">http://www.ics.uci.edu/~jsolis/publications/dtn_comps=
ac09.pdf</a></div>

<div><br></div><div><a href=3D"http://www.ics.uci.edu/~jsolis/publications/=
dtn_compsac09.pdf"></a>I think the question you raised by itself is a probl=
em to address. So taking it as an assumption really depends on the problem =
you are trying to address.</div>

<div><br></div><div>I am=A0completely=A0new to security in DTN. There are l=
ot of experts in this mailing list, who can give you better suggestion.</di=
v><div><br></div><div>Regards,</div><div>Rohit Mullangi,</div><div>Graduate=
 Student,</div>

<div>The University of Georgia,</div><div>Athens GA.</div><div><br><br><div=
 class=3D"gmail_quote">On Wed, Feb 2, 2011 at 3:00 PM, Shoaib Malik <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">shoaibmalik1981=
@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div>hi,=A0</div><div>I am working on a sec=
ure DTN network.=A0</div><div><br></div>In the DTN network, Suppose a node,=
 say N1, opportunistically becomes available to any other already existing =
node S, then at that time can we assume that there exist a confidential cha=
nnel between N1 and S.=A0<div>

In general, &quot;Can we assume that there exist a confidential channel bet=
ween each hop nodes, in a multi hop network&quot;.=A0</div><div><br></div><=
div>Is taking this assumption good or bad while working on security for DTN=
.=A0</div>

<div><br></div><div>regards,</div><div>Shoaib</div>
<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>
<br></blockquote></div><br></div>

--0016368e1aa18c86fa049b526073--

Date: Wed, 2 Feb 2011 20:00:32 +0000
From: Shoaib Malik <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-interest] Security for DTN

--0016e649d994ff24c4049b5219e1
Content-Type: text/plain; charset=ISO-8859-1

hi,
I am working on a secure DTN network.

In the DTN network, Suppose a node, say N1, opportunistically becomes
available to any other already existing node S, then at that time can we
assume that there exist a confidential channel between N1 and S.
In general, "Can we assume that there exist a confidential channel between
each hop nodes, in a multi hop network".

Is taking this assumption good or bad while working on security for DTN.

regards,
Shoaib

--0016e649d994ff24c4049b5219e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>hi,=A0</div><div>I am working on a secure DTN network.=A0</div><div><b=
r></div>In the DTN network, Suppose a node, say N1, opportunistically becom=
es available to any other already existing node S, then at that time can we=
 assume that there exist a confidential channel between N1 and S.=A0<div>
In general, &quot;Can we assume that there exist a confidential channel bet=
ween each hop nodes, in a multi hop network&quot;.=A0</div><div><br></div><=
div>Is taking this assumption good or bad while working on security for DTN=
.=A0</div>
<div><br></div><div>regards,</div><div>Shoaib</div>

--0016e649d994ff24c4049b5219e1--

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 2 Feb 2011 08:34:16 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Call for papers - IEEE GLOBECOM 2011

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

DTN is one of the identified Topics of Interest for the IEEE GLOBECOM 2011 =
track on Satellite and Space Communications, 5-9 December 2011 in Houston. =
 The Call For Papers is attached.

Scott

--_002_F25A909AA776104A92E2780BFCB3AEA81D5B4FA9ALTPHYEMBEVSP40_
Content-Type: application/pdf; name="GC11_SAC_SSC.pdf"
Content-Description: GC11_SAC_SSC.pdf
Content-Disposition: attachment; filename="GC11_SAC_SSC.pdf"; size=18451;
	creation-date="Wed, 02 Feb 2011 07:39:38 GMT";
	modification-date="Wed, 02 Feb 2011 07:39:38 GMT"
Content-Transfer-Encoding: base64

--_002_F25A909AA776104A92E2780BFCB3AEA81D5B4FA9ALTPHYEMBEVSP40_--

Date: Tue, 01 Feb 2011 18:00:57 +0000
From: Stephen Farrell <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] advance ECOS and LTPCL drafts?

Folks. Please read these drafts and send your comments and
opinions as to readiness in the next two weeks (by 2011-02-15).

Thanks,
S.

On 01/02/11 17:51, Burleigh, Scott C (313B) wrote:
> Do we have consensus that the ECOS and LTPCL Internet Drafts are ready to start through IRSG review?
> 
> http://datatracker.ietf.org/doc/draft-irtf-dtnrg-ecos/
> http://datatracker.ietf.org/doc/draft-burleigh-dtnrg-ltpcl/
> 
> Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 1 Feb 2011 09:51:36 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] advance ECOS and LTPCL drafts?

Do we have consensus that the ECOS and LTPCL Internet Drafts are ready to start through IRSG review?

http://datatracker.ietf.org/doc/draft-irtf-dtnrg-ecos/
http://datatracker.ietf.org/doc/draft-burleigh-dtnrg-ltpcl/

Scott