Subject: [dtn-interest] Comments on RFC 5050

From: Michael Noisternig <[email-masked]>
Date: Tue, 18 Jun 2013 11:08:44 +0200

Continuing my review (part 2/3) with RFC 5050...

4. Bundle Format:
"At most one of the blocks in the sequence may be a payload block." 
Would it be advanteous to allow more payload blocks with different 
(e.g., security) processing?

4.1. SDNVs:
I am not convinced this is the best solution. Even if we acknowledge 
that some flexible way to encode variable-length data is needed protocol 
designers are still faced with the decision whether to directly 
SDNV-encode some data field or instead SDNV-encode a length field such 
as to more efficiently carry lengthy data. Why not combine the current 
SDNV solution with some UTF-8-like encoding, such that the length of the 
data field is implicitly encoded?

The protocol also includes several byte values that are not 
SDNV-encoded: Version field, Block Type code, etc. These could easily be 
declared SDNV values without loosing backwards compatibility (to 
currently defined values) or processing efficiency.

4.2. Bundle Processing Control Flags:
"if fields are added
    in the future, the SDNV will grow to the left, and using this
    representation allows the references here to remain valid."
I see no reason why references should become invalid if the field would 
grow to the right with bit number 0 put on the left. The present 
representation has the disadvantage that the whole field needs to be 
received first before standard flags (those in earlier versions) can be 
parsed.

Flag 0 "Bundle is a fragment.": This flag obviously refers to the 
payload block, only, but could it be desirable to support fragmentation 
in other blocks as well such as in "optional" extension blocks?

Flag 4 "Destination endpoint is a singleton.": Requiring this knowledge 
seems to be in direct conflict with late binding.

4.3., last paragraph:
Why the restriction that "the block processing flags must be set to zero 
on all blocks that follow the payload block"?

4.4. Endpoint EIDs:
"Each endpoint ID conveyed in any bundle block takes the form of a 
Uniform Resource Identifier (URI; [URI])."
URIs are nice in being human-readable but they are also very wordy. It 
would be beneficial to generalize the current notion to support any kind 
of encoding (including binary) for the scheme-specific part given an 
(ASCII) scheme name. This is crucial for bandwidth-constrained 
environments, and definitely sufficient for applications that don't span 
multiple networks.

"This array is simply the concatenation of any number of null-terminated 
scheme names and SSPs."
Instead of null-terminating strings, why not encode them with prefixed 
SDNV length values? This seems to make the design more consistent and 
may improve string copy operations. But that's a minor comment.

4.7. Dictionary Revision:
"Any [unreferenced] strings (scheme names and SSPs) in a bundle's 
dictionary ... may be removed from the
    dictionary at the time the bundle is forwarded."
...subject to that authenticity is not lost.

5.2. Bundle Transmission, step 2:
"... with current custodian endpoint ID set to the null endpoint ID 
"dtn:none"
It should be up to the source to decide whether to support custody 
transfer, i.e., whether to set the current custodian EID to the source 
EID or to dtn:none.

5.6. Bundle Reception, step 4:
"If [a duplicate bundle has been received that] has the
       retention constraint "Custody accepted", custody transfer
       redundancy must be handled."
Why are processing steps 2 and 3, which generate bundle reception status 
reports, being executed before step 4?

---

From: Amy Alford <[email-masked]>
Date: Thu, 20 Jun 2013 20:38:36 -0400

> on all blocks that follow the payload block"?

I can answer this little detail.

The sentence is "The 'Block must be replicated in every fragment' bit in
the block
   processing flags must be set to zero on all blocks that follow the
   payload block"

Reactive fragmentation is impossible if post-payload blocks might have the
"block must be replicated in every fragment" bit set.  A receiving node
wouldn't know if the partial bundle it had received was missing any blocks
with this bit set.  Any time a node receives a partial bundle which
includes some payload, it may turn it into a fragment (unless the "do not
fragment" flag is set on the primary block).

---

From: Michael Noisternig <[email-masked]>
Date: Fri, 21 Jun 2013 08:58:01 +0200

Thanks, Amy, that makes it clear!

Michael

Am 21.06.2013 02:38, schrieb Amy Alford:
>
>
>
> On Tue, Jun 18, 2013 at 5:08 AM, Michael Noisternig
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>       4.3., last paragraph:
>     Why the restriction that "the block processing flags must be set to
>     zero on all blocks that follow the payload block"?
>
>
> Reactive fragmentation is impossible if post-payload blocks might have
> the "block must be replicated in every fragment" bit set.  A receiving
> node wouldn't know if the partial bundle it had received was missing any
> blocks with this bit set.  Any time a node receives a partial bundle
> which includes some payload, it may turn it into a fragment (unless the
> "do not fragment" flag is set on the primary block).
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 21 Jun 2013 15:26:19 +0000

Michael, a few comments in-line below.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Noisternig
Sent: Tuesday, June 18, 2013 2:09 AM
To: [email-masked]
Subject: [dtn-interest] Comments on RFC 5050

4. Bundle Format:
"At most one of the blocks in the sequence may be a payload block."
Would it be advanteous to allow more payload blocks with different (e.g., security) processing?

>       We've considered this several times but I think we've never seen enough advantage to justify the additional complexity.  It would enable aggregation of multiple application data units into a single bundle, thereby saving the overhead of multiple primary blocks.  However, that aggregation could just as readily - and possibly even more efficiently - be done above BP (in the application, or in the Delay-Tolerant Payload Conditioning layer we're standardizing in CCSDS).  At the same time, supporting multiple payload blocks would seem to make fragmentation and reassembly more complicated.  So it's not an obvious improvement.

4.1. SDNVs:
I am not convinced this is the best solution. Even if we acknowledge that some flexible way to encode variable-length data is needed protocol designers are still faced with the decision whether to directly SDNV-encode some data field or instead SDNV-encode a length field such as to more efficiently carry lengthy data. Why not combine the current SDNV solution with some UTF-8-like encoding, such that the length of the data field is implicitly encoded?

>       Can you describe in more detail the specific alternative you are proposing?  That would give us a basis for comparison, which might answer this question.

The protocol also includes several byte values that are not
SDNV-encoded: Version field, Block Type code, etc. These could easily be declared SDNV values without loosing backwards compatibility (to currently defined values) or processing efficiency.

>       Sure, but while SDNVs are not extremely processor-intensive to handle they always consume more cycles than simply operating on a byte.  If there's a significant likelihood that a field will need to be of different sizes under different circumstances, defining it as an SDNV makes sense; otherwise it doesn't.

4.2. Bundle Processing Control Flags:
"if fields are added
    in the future, the SDNV will grow to the left, and using this
    representation allows the references here to remain valid."
I see no reason why references should become invalid if the field would grow to the right with bit number 0 put on the left. The present representation has the disadvantage that the whole field needs to be received first before standard flags (those in earlier versions) can be parsed.

>       This doesn't seem like a significant disadvantage.  Even if a BP agent received its bundles one byte at a time, it probably shouldn't act on the basis of bundle processing control flags until at least the entire primary block has been received.

Flag 0 "Bundle is a fragment.": This flag obviously refers to the payload block, only, but could it be desirable to support fragmentation in other blocks as well such as in "optional" extension blocks?

>       Nobody has identified a requirement to fragment extension blocks.  If such a requirement were identified we would need to revisit fragmentation and the meaning of this flag might well have to change.

Flag 4 "Destination endpoint is a singleton.": Requiring this knowledge seems to be in direct conflict with late binding.

>       I don't think so.  Late binding is about not requiring the source node to know the topological location of the destination.  Endpoint cardinality is about constraining the processing performed at forwarding nodes.

4.3., last paragraph:
Why the restriction that "the block processing flags must be set to zero on all blocks that follow the payload block"?

4.4. Endpoint EIDs:
"Each endpoint ID conveyed in any bundle block takes the form of a Uniform Resource Identifier (URI; [URI])."
URIs are nice in being human-readable but they are also very wordy.

>       I personally agree with you on this point.  URIs are a great external representation of endpoint IDs but not necessarily a good internal representation; sort of like the difference between 32-bit IPv4 addresses and dotted-string IP address representations.

It would be beneficial to generalize the current notion to support any kind of encoding (including binary) for the scheme-specific part given an
(ASCII) scheme name. This is crucial for bandwidth-constrained environments, and definitely sufficient for applications that don't span multiple networks.

>       This is why there's an RFC for CBHE.

"This array is simply the concatenation of any number of null-terminated scheme names and SSPs."
Instead of null-terminating strings, why not encode them with prefixed SDNV length values? This seems to make the design more consistent and may improve string copy operations. But that's a minor comment.

4.7. Dictionary Revision:
"Any [unreferenced] strings (scheme names and SSPs) in a bundle's dictionary ... may be removed from the
    dictionary at the time the bundle is forwarded."
...subject to that authenticity is not lost.

>       Yes, but that's implicit.  Strings that are needed in order to verify authenticity are referenced, so they can't be removed from the dictionary.

5.2. Bundle Transmission, step 2:
"... with current custodian endpoint ID set to the null endpoint ID "dtn:none"
It should be up to the source to decide whether to support custody transfer, i.e., whether to set the current custodian EID to the source EID or to dtn:none.

>       The custodian EID is initialized to "dtn:none" at bundle creation time, regardless of whether or not the source node subsequently chooses to take custody.  Initial acceptance of custody at the source node happens later in the procedure, in step 4 of 5.4, subject to the decision made in 5.2 step 1.  But I do think the language could be clarified a bit here.

Why are processing steps 2 and 3, which generate bundle reception status reports, being executed before step 4?

>       Can you say a little more about why they shouldn't be?

_______________________________________________
dtn-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Michael Noisternig <[email-masked]>
Date: Mon, 24 Jun 2013 11:37:20 +0200

Thanks again, Scott. See my replies inline.

Michael

>   * Can you describe in more detail the specific alternative you are
>     proposing?  That would give us a basis for comparison, which might
>     answer this question.

Well, there are various solutions though they may not be as pretty. One 
is as such, with bits in standard order (msb first):

  0....... data preceded by length value, where
  00......   length value has one byte (6 bits)
  01......   length value has more than one byte (SDNV-encoded)
  10...... data has one byte (6 bits)
  110..... data has two bytes (13 bits)
  1110.... data has three bytes (20 bits)
  aso.

The intent is solely to avoid the decision at the protocol design phase 
whether to directly SDNV-encode the data or to precede it by some 
SDNV-encoded length field.

>   * Sure, but while SDNVs are not extremely processor-intensive to
>     handle they always consume more cycles than simply operating on a
>     byte.  If there’s a significant likelihood that a field will need to
>     be of different sizes under different circumstances, defining it as
>     an SDNV makes sense; otherwise it doesn’t.

No, the point is that this doesn't make the processing any more complex. 
Type codes etc. are still compared on a byte basis just as now. The only 
difference is that bytes values 128-255 are "reserved" to indicate a 
multi-byte (SDNV-encoded) value. At least that way one can assure that 
the number of type codes later defined will never become too large. (And 
if you are confident that the number will always stay slow then nothing 
is lost either.)

>   * This doesn’t seem like a significant disadvantage.  Even if a BP
>     agent received its bundles one byte at a time, it probably shouldn’t
>     act on the basis of bundle processing control flags until at least
>     the entire primary block has been received.

I agree, the disadvantage is likely negligible. Still, I dispute the 
rationale given in the RFC for why bits are not in the standard order of 
RFCs:
"This is
    why the descriptions in this section and the next do not follow
    standard RFC conventions with bit 0 on the left; if fields are added
    in the future, the SDNV will grow to the left, and using this
    representation allows the references here to remain valid."

>   * I don’t think so.  Late binding is about not requiring the source
>     node to know the topological location of the destination.  Endpoint
>     cardinality is about constraining the processing performed at
>     forwarding nodes.

Hm, but then someone (the source/the application) must know that the 
destination EID represents a singleton. It might be a restriction or it 
might be not. (I take your word if you say it is not.)

> It would be beneficial to generalize the current notion to support any
> kind of encoding (including binary) for the scheme-specific part given an
>   * This is why there’s an RFC for CBHE.

Maybe I don't understand what RFC 6260 (CBHE) says. Section 2.2 states that
"In a CBHE-compressed primary block, the eight SDNVs that
    normally contain EIDs' scheme name and SSP offsets within the
    dictionary are instead used to contain the eight integer values..."
As per the BP spec these must be SDNV values. Are they instead encoded 
as 64-bit integer values? If so, how can non-compatible receivers 
correctly parse the bundle header?

>   * Yes, but that’s implicit.  Strings that are needed in order to
>     verify authenticity are referenced, so they can’t be removed from
>     the dictionary.

Could it happen that some extension block be processed, removed and its 
EID references removed by some intermediate node on a security path? I 
am still trying to figure out what is possible with the current security 
spec.

>   * Can you say a little more about why they shouldn’t be?

Let's say a duplicate bundle has been received. Then by steps 2 and 3 
the receiving node would potentially already have sent several redundant 
bundle reception status reports. It seems that such behavior on replays 
should be avoided.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 24 Jun 2013 15:24:55 +0000

Thanks, Michael, I think this is productive.  More notes in-line below.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Noisternig
Sent: Monday, June 24, 2013 2:37 AM
To: [email-masked]
Subject: Re: [dtn-interest] Comments on RFC 5050

Michael

> that some flexible way to encode variable-length data is needed 
> protocol designers are still faced with the decision whether to 
> directly SDNV-encode some data field or instead SDNV-encode a length 
> field such as to more efficiently carry lengthy data. Why not combine 
> the current SDNV solution with some UTF-8-like encoding, such that the 
> length of the data field is implicitly encoded?
>

Well, there are various solutions though they may not be as pretty. One is as such, with bits in standard order (msb first):

The intent is solely to avoid the decision at the protocol design phase whether to directly SDNV-encode the data or to precede it by some SDNV-encoded length field.

	Okay, I think this is worth discussing, but I personally am doubtful that there's more than marginal net advantage here.  In general I don't think it has been difficult for us to make the kinds of design-time decisions this sort of system is designed to shield us from.  At the same time, it makes it impossible to represent a numeric value larger than 63 in a single byte.  The cost in additional metadata doesn't seem, to me, to be justified by the benefit.  But as I say, it's worth discussing.

> SDNV-encoded: Version field, Block Type code, etc. These could easily 
> be declared SDNV values without loosing backwards compatibility (to 
>     byte.  If there's a significant likelihood that a field will need to
>     an SDNV makes sense; otherwise it doesn't.

No, the point is that this doesn't make the processing any more complex. 
Type codes etc. are still compared on a byte basis just as now. The only difference is that bytes values 128-255 are "reserved" to indicate a multi-byte (SDNV-encoded) value. At least that way one can assure that the number of type codes later defined will never become too large. (And if you are confident that the number will always stay slow then nothing is lost either.)

	Again I think we're talking at the margins.  Currently I suspect all implementations process every SDNV as an SDNV, even when it is only a single byte in length.  I think what you're proposing would divide SDNVs into two classes: those that must always be processed as SDNVs and those that may simply be processed as bytes because they're always only a single byte -- except that at some point in the future they might get potentially bigger and have to change into the other sort of SDNV, at which point you've got to change your code.  We could of course get around this by doing an extra check of the high-order bit of the first byte whenever we process an SDNV and, if it's zero, simply processing that single-byte SDNV as a byte.  But that's still slightly more processing than immediately processing the byte field as a byte field, and in addition we've cut the range of possible values in that variable by 50%.   So it's not quite true that if you are confident that the value will always stay low then nothing is lost.  I'm doubtful, but I guess it's not a huge deal one way or the other.

> I see no reason why references should become invalid if the field 
> would grow to the right with bit number 0 put on the left. The present 
> received first before standard flags (those in earlier versions) can 
> be parsed.
>
>   * This doesn't seem like a significant disadvantage.  Even if a BP
>     agent received its bundles one byte at a time, it probably shouldn't

I agree, the disadvantage is likely negligible. Still, I dispute the rationale given in the RFC for why bits are not in the standard order of
RFCs:
"This is

> Flag 4 "Destination endpoint is a singleton.": Requiring this 
> knowledge seems to be in direct conflict with late binding.
>
>   * I don't think so.  Late binding is about not requiring the source

Hm, but then someone (the source/the application) must know that the destination EID represents a singleton. It might be a restriction or it might be not. (I take your word if you say it is not.)

	I don't know whether I'd call it a restriction or not.  The real issue, I would say, is that the difference between unicast and multicast (singleton-ness) is orthogonal to the question of how you forward a bundle toward one of its destination nodes (late binding).  The mechanisms are distinct, and the information items required to invoke them successfully are distinct.

> environments, and definitely sufficient for applications that don't 
> span multiple networks.
>
>   * This is why there's an RFC for CBHE.

Maybe I don't understand what RFC 6260 (CBHE) says. Section 2.2 states that "In a CBHE-compressed primary block, the eight SDNVs that
    normally contain EIDs' scheme name and SSP offsets within the
    dictionary are instead used to contain the eight integer values..."
As per the BP spec these must be SDNV values. Are they instead encoded as 64-bit integer values? If so, how can non-compatible receivers correctly parse the bundle header?

	No, the eight integer values (node number and service number, for source, destination, report-to, and custodian) are still encoded as SDNVs.  CBHE is not a general solution to the problem of encoding any scheme-specific part given a scheme name; it's a single, very specific header compression mechanism that is available for a limited set of scheme names.  I have a feeling I'm not understanding your question, though.

>   * Yes, but that's implicit.  Strings that are needed in order to
>     verify authenticity are referenced, so they can't be removed from
>     the dictionary.

Could it happen that some extension block be processed, removed and its EID references removed by some intermediate node on a security path? I am still trying to figure out what is possible with the current security spec.

	Hmm.  A BAB can certainly be processed and removed, which would remove its EID references, which would in theory authorize the removal of the BAB's EID(s) from the dictionary, but that couldn't invalidate the authenticity of the bundle.  I think the same is true of other types of extension block.
	More generally, though, I am an ardent advocate of losing the dictionary altogether, using CBHE-like encoding natively in the primary block for routine unicast, and carrying uncompressed EID text in extension blocks when more exotic EID structures need to be processed.  I expect this point of view is not universally held, so it may well not prevail as we move toward updating the BP specification, but I believe it would solve a multitude of problems, not least these dictionary management issues.

> Why are processing steps 2 and 3, which generate bundle reception 
> status reports, being executed before step 4?
>
>   * Can you say a little more about why they shouldn't be?

Let's say a duplicate bundle has been received. Then by steps 2 and 3 the receiving node would potentially already have sent several redundant bundle reception status reports. It seems that such behavior on replays should be avoided.

	That's not unreasonable, but on the other hand those additional status reports might actually be helpful.  They're not of much use to the sending application, which already knows that the end-to-end transmission has succeeded, but that's not the sole purpose of the status reports.  Bundle status reports are often used as network management/debugging tools, to trace the paths taken by bundles through the network, and for that purpose the fact that a bundle was redundantly delivered might be important information.
	In general I think the sense of DTNRG was that bundle status reporting is a mechanism that has to be used sparingly in order to avoid saturating the network with metadata.  In that case, an infrequent redundant report at worst does little harm and at best might do some good.
_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Michael Noisternig <[email-masked]>
Date: Mon, 24 Jun 2013 18:41:28 +0200

Thanks again! A few more replies inline.

Michael

> 	Okay, I think this is worth discussing, but I personally am doubtful that there's more than marginal net advantage here.  In general I don't think it has been difficult for us to make the kinds of…

Well, the encoding could be changed such as to carry values up to 127 in 
a single byte. But let's keep these suggestions at the back of our minds 
for now.

> 	Again I think we're talking at the margins.  Currently I suspect all implementations process every SDNV as an SDNV, even when it is only a single byte in length.  I think what you're proposing would divide SDNVs into two classes: those that must always be processed as SDNVs and those that may simply be processed as bytes because they're always only a single byte -- except that at some point in the future they might get potentially bigger and have to change into the other sort of SDNV, at which point you've got to change your code.  We could of course get around this by doing an extra check of the high-order bit of the first byte whenever we process an SDNV and, if it's zero, simply processing that single-byte SDNV as a byte.  But that's still slightly more processing than immediately processing the byte field as a byte field, and in addition we've cut the range of possible values in that variable by 50%.   So it's not quite true that if you are confident that the value wil
 l
>   always stay low then nothing is lost.  I'm doubtful, but I guess it's not a huge deal one way or the other.

Margins, yes. More processing, no. Nodes still do a byte-wise 
comparison, possibly implemented via a 'case' statement: case 1 -> 
payload block, case 2 -> BAB, etc., default -> ignore (as of now) or 
invoke SDNV-decoding routine if and only if type values >= 128 are 
supported by the bundle node. Seems slightly more safe to me but 
probably it's subjective.

> 	No, the eight integer values (node number and service number, for source, destination, report-to, and custodian) are still encoded as SDNVs.  CBHE is not a general solution to the problem of encod…

Argh. I had a wrong picture in my head, which also explains my initial 
confusion about efficiently encoding addresses and my suggestion for a 
binary encoding format (which CBHE essentially implements).

Related to your suggestion (below) on using a CBHE-like encoding by 
default, my original idea was to make the encoding scheme-dependent. So 
a default (implicit) scheme could implement a CBHE-like encoding while 
custom scheme names would define their own encoding syntax (e.g., 
according to the format of URIs). Not sure whether this has some merit 
or not.

> 	In general I think the sense of DTNRG was that bundle status reporting is a mechanism that has to be used sparingly in order to avoid saturating the network with metadata.  In that case, an infreq…

I understand. And in the end, the transmission of these status reports 
is up to policy.

---

From: Amy Alford <[email-masked]>
Date: Mon, 24 Jun 2013 14:48:31 -0400

> EID references removed by some intermediate node on a security path? I am
> still trying to figure out what is possible with the current security spec.
>
Yes.  Talking through a specific example is probably the best way to
clarify this.  Suppose we have a very boring network of:

Node A --- Node B --- Node C --- Node D

Node A sends a bundle to node D, with a PIB block with security source of
node A and security destination of node D.  Node B can add a PIB block with
security source node B and security destination node C.  When node C
removes the PIB block destined for node C, it may change the dictionary.
 But, it would change it back to its state at the time the first PIB was
calculated.

In any event, PIBs don't cover the dictionary (only the specific entries
being used in the blocks covered by the PIB).  BABs cover the dictionary,
but are always the last security block added and first removed.  The only
time dictionary changes would invalidate a BAB are if the dictionary was
modified at a non security aware node.  However, if the dictionary was
being modified because of a change to an extension block, that would
invalidate the BAB anyway.  The only dictionary changes that would
invalidate a PIB are gratuitous changes to case insensitive fields.

- Amy

---

From: Michael Noisternig <[email-masked]>
Date: Mon, 24 Jun 2013 21:03:29 +0200

Am 24.06.2013 20:48, schrieb Amy Alford:
>     Could it happen that some extension block be processed, removed and
>     its EID references removed by some intermediate node on a security
>     path? I am still trying to figure out what is possible with the
>     current security spec.
>
> Node A sends a bundle to node D, with a PIB block with security source
> of node A and security destination of node D.  Node B can add a PIB
> block with security source node B and security destination node C.  When
> node C removes the PIB block destined for node C, it may change the
> dictionary.  But, it would change it back to its state at the time the
> first PIB was calculated.
>
> being used in the blocks covered by the PIB).  BABs cover the
> dictionary, but are always the last security block added and first
> removed.  The only time dictionary changes would invalidate a BAB are if
> the dictionary was modified at a non security aware node.  However, if
> the dictionary was being modified because of a change to an extension
> block, that would invalidate the BAB anyway.  The only dictionary
> changes that would invalidate a PIB are gratuitous changes to case
> insensitive fields.
>
> - Amy

Ah, I missed that the PIB does not protect the complete dictionary. 
Otherwise, I was more thinking about partially overlapping paths. 
Something like where Node A adds some (non-security) extension block 
together with some new dictionary entry, both to be processed and 
removed by Node C, whereas Node B adds a PIB to be consumed by Node D.

But what about dictionary entries by non-primary blocks? How are they 
being protected end-to-end?

Michael

---

From: Amy Alford <[email-masked]>
Date: Mon, 24 Jun 2013 15:14:03 -0400

If you replaced PIB with BAB in your scenario, authentication would fail.
 However, this could only occur if node C is non-security aware.

Dictionary entries in extension blocks aren't protected by PIB or PCB.  An
ESB ciphersuite that provided integrity would protect any extension block
it was applied to.  There isn't a PIB equivalent for extension blocks (if
there were, it would be what you would use to protect dictionary entries
for an extension block (as well as the block contents)).  A revision to
6257 will probably provide a PIB equivalent for extension blocks.

On Mon, Jun 24, 2013 at 3:03 PM, Michael Noisternig <
[email-masked]> wrote:

> Otherwise, I was more thinking about partially overlapping paths. Something
> like where Node A adds some (non-security) extension block together with
> some new dictionary entry, both to be processed and removed by Node C,
> whereas Node B adds a PIB to be consumed by Node D.
>
> ______________________________**_________________
> https://www.irtf.org/mailman/**listinfo/dtn-interest<https://www.irtf.org/mailman/listinfo/dtn-interest>
>

---

From: Peter Lovell <[email-masked]>
Date: Mon, 24 Jun 2013 15:46:58 -0400

>6257 will probably provide a PIB equivalent for extension blocks.

ESB is quite capable of providing PIB-like protection to extension blocks.

The existing sample ciphersuite provides confidentiality (PCB-style) but there's no reason that different ESB ciphersuite couldn't provide PIB-like protection. It's all up to the ciphersuite definition. ESB is not limited to confidentiality.

Regards.....Peter

---

From: Amy Alford <[email-masked]>
Date: Mon, 24 Jun 2013 15:59:38 -0400

I'm calling an integrity ciphersuite for ESB "not PIB-like", because it
encapsulates the target block.  Even if it doesn't encrypt it, it still
isn't transparent to non-security-aware nodes.
- Amy

On Mon, Jun 24, 2013 at 3:46 PM, Peter Lovell <[email-masked]> wrote:

> The existing sample ciphersuite provides confidentiality (PCB-style) but
> there's no reason that different ESB ciphersuite couldn't provide PIB-like
> protection. It's all up to the ciphersuite definition. ESB is not limited
> to confidentiality.
>
> Regards.....Peter
>
>
>
>

---

From: Michael Noisternig <[email-masked]>
Date: Tue, 25 Jun 2013 11:47:05 +0200

Thank you, Amy, for your detailed answer!

Michael

Am 24.06.2013 21:14, schrieb Amy Alford:
> If you replaced PIB with BAB in your scenario, authentication would
> fail.  However, this could only occur if node C is non-security aware.
>
> Dictionary entries in extension blocks aren't protected by PIB or PCB.
>   An ESB ciphersuite that provided integrity would protect any extension
> block it was applied to.  There isn't a PIB equivalent for extension
> blocks (if there were, it would be what you would use to protect
> dictionary entries for an extension block (as well as the block
> contents)).  A revision to 6257 will probably provide a PIB equivalent
> for extension blocks.
>
>
>
> On Mon, Jun 24, 2013 at 3:03 PM, Michael Noisternig
>     But what about dictionary entries by non-primary blocks? How are
>     they being protected end-to-end?
>
>     Michael
>
>     _________________________________________________
>     [email-masked] <mailto:[email-masked]>
>     https://www.irtf.org/mailman/__listinfo/dtn-interest
>     <https://www.irtf.org/mailman/listinfo/dtn-interest>
>
>
>
>