Re: [dtn-security] Implementing Security Destinations in DTN2

If the security destination did not handle the bundle would the bundle
payload not still be encrypted, or sigs needing verification?

If the security dest is defined then it should be preferred simply because
the contents have not yet been handled (data not decrypted, sigs not
verified, etc) and the payload would be useless or untrusted, but would the
bundle dest not forward it on to the security dest anyway so that the
operations can be completed?

The final bundle can then be sent on to the bundle destination, assuming of
course that it is different to the security destination.

/2p

Ian

On 3 September 2012 14:38, <ahennes1@math.umd.edu> wrote:

> We're working on adding support for defining security source/destinations
> in DTN2 (which could be different than the bundle src/dest).
>
> This raised the issue of whether or not we should route the bundle to the
> security destination (if defined), rather than the bundle destination. If
> we don't route the bundle through the security dest, then it may be
> discarded at the bundle dest if it did not pass through the security dest
> in transit.
>
> There are also some practical issues that are raised. There can be a
> security destination for PIB/PCB, and a (possibly different) security dest
> for ESB, and we'd have to decide which one to choose.
>
> Also, the routers in DTN2 access the bundle destination themselves, i.e.
> bundle->dest(). They would each have to be corrected to use some other
> value.
>
>
> Any comments/feedback would be appreciated.
>
>
> thanks,
> Angela
> _______________________________________________
> dtn-security mailing list
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security
>