Re: [dtn-interest] Comments on RFC 5050

[Michael Noisternig <[e-mail]>]

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
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Am 24.06.2013 20:48, schrieb Amy Alford:
>
>
>                  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.
>
>
>              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.
>
>         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
>
>
>     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
>
>     _________________________________________________
>     dtn-interest mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.irtf.org/mailman/__listinfo/dtn-interest
>     <https://www.irtf.org/mailman/listinfo/dtn-interest>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>