Subject: RE: question: pana messaging

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 18 Apr 2003 10:54:39 -0700

> hi mohan,
> 
> please see my comment inline:
> >
> > >
> > > >> 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.
> 
> 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 network operator wants to make sure that no one is stealing
anyone else service and thus getting service for free in the
network.

> 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.
> 
> 
> >
> > > 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.
> 
> 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.
> 
I think in the later mails, we agreed to this.

-mohan

> 
> >
> > >
> > > >
> > > > 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
> 
> ciao
> hannes
> 
> >
> > > >
> > > >
> > > > Thanks,
> > > > Yoshihiro Ohba
> > > >
> > > >
> > >
> > >
> >
> 
>