Subject: RE: [NSIS] chain of trust

From: [email-masked]
Date: Wed, 13 Nov 2002 13:13:29 +0200

Hi Hannes,

> 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)

Agreed.  Some of these may need to be readable by intermediate nodes,
I am not sure which need to be mutable.
 
> 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.

Well, if you are signaling the NAT (for example) I see this as the endpoint.

> 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.

Most definately.
 
> > > - protocol operations like proxying might require some sort of
> > delegation.
> >
> > Proxying is officially (or at least unofficially) discouraged by
> > the Secuirty Area.
> 
> 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.

It is not currently in the framework.  I would like to ask a security person
to look at it an recomend it.

> 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.

It is a proxy of a sort, but I would not call it a layer 3 proxy.

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 13 Nov 2002 08:40:44 -0500

> Well, if you are signaling the NAT (for example) I see this as the =
> endpoint.

It depends.  For signaling purposes it's not an endpoint,
it's just another NSIS forwarder with peculiar properties.
For the purposes of securing the operation, however, it's an
endpoint in that unlike a router that's being participating
in QoS signaling, the NAT needs to authenticate itself to
the sender, which is an end-to-end operation between the NAT
and the sender.

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 13 Nov 2002 15:57:46 +0100

hi melinda!

i see that an end host (nsis initiator) has to authenticate itself to a
firewall in many cases. but why should a nat authenticate itself to the
signaling initator? why is it not sufficient to have authentication of the
nat to its nsis peer?

ciao
hannes

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, November 13, 2002 2:41 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] chain of trust
>
>