Subject: RE: question: pana messaging

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 16 Apr 2003 17:58:04 -0700

> 
> >> however, the Data-Protection might also be negotiated e.g. 
> not every pac
> >> supports ipsec. hence if the paa forces the pac to use 
> ipsec then no network
> >> access would be possible. if the paa (and the pac) 
> additionally support link
> >> layer security then they could use link layer sec. instead.
> 
> The simplistic assumption is this: If the link is not 
> multiaccess, we don't
> need to worry about L2 or L3 ciphering. Otherwise, if the 
> network has L2
> ciphering capability, it requires all of its clients to use 
> it. If not, it
> requires all of its clients to use IPsec. These are not 
> negotiable at all.
> 
Yes.

> If we want to extend this, we need to understand: Under what 
> conditions such
> negotiation will be useful? For example, allowing some 
> clients to use L2
> ciphering whereas others to use only IPsec, does this make 
> sense? Does it

It is still not negotiation here. The network enforces this
on the clients.

> make sense to "allow" some clients to use both L2 ciphering 
> and IPsec after
> PANA?
> 
I see it more as what the network wants to enforce on the client.
I don't see anything negotiable in this unless someone tells
what is being negotiated here.

> 
> > 
> > If the access network supports IPsec but does not force 
> PaCs to always
> > use it, then the Data-Protection AVP can contain a new flag to
> > indicate whether per-packet protection is required or not.  However,
> > this still does not mean that negotiation is needed for PANA and I
> > don't think Data-Protection AVP is needed for PANA_success_ack to
> > support the scenario you mentioned.
> > 
> >> 
> >> furtermore the paa might not be able to trigger ipsec 
> after the finished eap
> >> authentication. for example: the pac starts without an ip address
> >> configured. hence after successful eap auth. the pac 
> obtains an ip address
> >> e.g. using stateful address autoconfig. (dhcp). 
> subsequently ipsec can be
> >> enabled. thereby the client might send a Data-Protection 
> AVP saying that he
> >> is ready to enable ipsec.
> > 
> > When the PAA registers an IP address of the PaC as the device
> > identifier, it can mean that the PaC is ready to enable IPsec with
> > using that IP address.  Then the PAA can inform EP of the IP address
> > and the IKE credential of the PaC so that EP can perform 
> IKE with the
> > PaC.  I think what we actually need to support this scenario is the
> > abitility to use both IP address and MAC address as the device
> > identifier at one time, instead of using either IP address or MAC
> > address at one time.  However, this still does not mean that
> > negotiation is needed for PANA.
> 
> I agree that this does not mean negotitation is needed. Still PAA can
> indicate IPsec is a must. Only in that case it might mean 
> that PaC can do
> DHCP before turning IPsec on.
> 
> 
> > 
> >> 
> >> this is also an example why it should be possible to 
> update device-id info
> >> at the paa. the pac cannot provide his ip address. later 
> it is, however,
> >> possible.
> > 
> > I agree that it should be possible to update device-id information
> > for the reason I mentioned above.
> 
> It'd be good if someone can start a new thread to discuss 
> "session id".
> Please list the usage scenarios of the session id concept 
> (aforementioned
> one, fast re-auth, etc.). Note that currently pana-00 is 
> using device ID as
> the handle.
> 
> 
> Alper
> 
mohan

> > Thanks,
> > Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Apr 2003 18:30:58 -0700

> what is being negotiated here.

OK, let me expand on this a bit more...

I don't know if the following scenario is realistic and needed:

"The access network can do both L2 ciphering and L3 ciphering.
PaC is being told that the access network can do any one of these, and
optionally both at the same time. PaC must choose at least one, but it can
choose both at the same time".

So, in that case, PaC will have to indicate its choice: L2, L3, or both.

This is what I mean by "negotiation". But first thing we should do is to
analize this scenario, or see if there are other scenarios that requires PaC
to have a say in this.

Alper

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 18 Apr 2003 15:12:27 +0200

hi mohan,

> It is still not negotiation here. The network enforces this

what is the incentive for the network to enforce strong protection? the
client does not want an adversary to inject traffic or to eavesdrop the
transmitted datat traffic. the network does not care.

the same is true for the negotiation of the refresh interval. for the
benefit of the network access provider there shouldn't be a refresh interval
at all. the client, however, wants to stop accounting if it lost
connectivity. hence the network suggest something (which is probably aligned
to the accounting interval) and the client has to indicate something.

hence you cannot mandate a certain refresh interval here as well.
(as derek mentioned there is a tradeoff)

i see these as the same mechanisms why not to make them more general for
future extensions to the pana protocol.

> what is being negotiated here.

the negotiable part here is:

network supports something (possible more than one mechanism):

a) network and link layer protection

b) client says that he would like to enable something

if there is always only one choice then there is clearly no negotiation.
this does not seem to be the case here.

maybe it is better to see this procedure as an indication of what is
supported rather than a negotiation.

> > one, fast re-auth, etc.). Note that currently pana-00 is

ciao
hannes