Subject: RE: [NSIS] chain of trust

From: [email-masked]
Date: Wed, 13 Nov 2002 11:27:02 +0200

Hannes,

Some comments:

> - a signaling protocol requires intermediate nodes to inspect, modify and
> add message parts. hence only some non-mutuable fields can be protected or
> incremental protection. the meaning for an end host might be questionable.

What this means is that the signaling header may need to be unprotected, while
the payload be protected.

> - protocol operations like proxying might require some sort of delegation.

Proxying is officially (or at least unofficially) discouraged by the Secuirty
Area.

> - applying end-to-end security between two arbitrary hosts might be a
> deployment problem in general

Can you suggest why?
 
> if there are some objects which are only relevant for end hosts (and not for
> intermediate nodes at all) then why is it necessary to ship them with a
> signaling protocol.

The above statement confuses me - is your question this:

	" ... necessary to ship them with a hop-by-hop signaling protocol." 

John
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 13 Nov 2002 11:10:40 +0100

hi john.

thanks for talking to the area directors to capture their view. please see

> the payload be protected.

it depends what payload you are referring to:
- flow identifier (no)
- lifetime (no)
- policy object (no)
- local objects (no)
- something like a adspec object (no)
- qos parameters (don't know / might also be known to both end points)

for nat/firewall traversal i am not really sure what end-to-end actually
means. is the firewall the end or the host to which the messages are
addressed.

i will look at rsvp to see how many parameters are possible candidates for
end-to-end protection. (probably not a long list). question to bob: has
someone ever suggested end-to-end security protection for rsvp?

my conclusion: more investigation is required in this area.

> Proxying is officially (or at least unofficially) discouraged by

interesting to hear this. is this also reflected in the framework document?
avoiding proxy operation also means that something like local reservations
(where the end point is unkown) is also not allowed. this might have some
implications for mobility.

another example:
in some architectures the end host communicates his qos parameters using a
link layer protocol. signaling at the ip layer then starts somewhere at the
access network. this is also a proxy operation.

> > deployment problem in general
key management. many of us followed the mobile ipv6 binding update
discussions.

> 	" ... necessary to ship them with a hop-by-hop signaling protocol."

for example: someone suggested to negotiate parameter to determine who has
to pay for a reservation within a signaling protocol. this negotiation is
purely end-to-end. hence there is a question why it has to be piggybacked on
top of a signaling protocol like nsis.

ciao
hannes