Subject: RE: question: pana messaging

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 16 Apr 2003 18:45:42 -0700

> 
> >> 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.
> 
> 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.
> 
The way I see it is, "you need to choose option A or option B or ...".
PaC can choose option A ,but rather than indicating it, starts the
negotiation relevant to A i.e if the network supports L2 and L3,
the client starts L3 negotiation which means it wants to do L3.
Perhaps indicating this separately makes PAA/EP more prepared
on what to expect next i.e L2 and L3 may require different details
to be communicated to EP. This means client chooses, PAA does the
setup, acks and then PaC begins the real negotiation. Is this
a strong enough reason ?

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

> Alper
mohan

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Apr 2003 19:08:10 -0700

> to be communicated to EP.

Yes.

For example if the PaC does not explicitly indicate its intentions, this
might open up a security hole. Access point allows the PaC's traffic
thinking PaC is using L3 ciphers. Access router allows the PaC's traffic
thinking it is using L2 ciphers. And maybe the Pac is using neither! [OK,
maybe the access point can be a bit smart and look for an IPsec header and
access router's IP address as the destination of incoming packets, but...]

If we were to enable such a scenario, I'd prefer PaC explicitly indicating
its intentions.

> This means client chooses, PAA does the

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 17 Apr 2003 00:17:54 -0400

> access router's IP address as the destination of incoming packets, but...]

I think there is some scenario in which the network supports L2 or L3
(or both) ciphers, but authenticated PaC is using neither, but EP
still allows forwarding unprotected packets for the PaC.  In some
sense, per-packet protection may be needed only by PaCs that want to
protect its traffic from others.  If such a scenario makes sense, it
might be useful if Data-Protection AVP contains a flag that indicates
whether the network forces per-packet protection to all PaCs or not.

Yoshihiro Ohba

---

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

hi mohan,

please see my comment inline:

> -----Original Message-----
> From: Mohan Parthasarathy [mailto:[email-masked]]
> Sent: Donnerstag, 17. April 2003 03:46
> To: Alper Yegin; Yoshihiro Ohba; Hannes Tschofenig
> Cc: [email-masked]
> Subject: RE: question: pana messaging
>
>
>
>
> >

the pac cannot simply start (let's say) ike since the paa must know that a
particular client wants to start this procedure. it needs to send him the ip
address of the ep (if not co-located with the paa) where the ipsec tunnel
should terminate. it furthermore needs to send the keys and other parameters
there in order for the ep to be ready to respond to it.

in case of link layer protection the situation would be worse. imagine what
happens if the client suddenly starts to transmit only encrypted packets.
the ep is, however, not prepared to decrypt them since it has not received
the necessary parameters yet. as a result the communication to the network
is broken. the same happens if the network (by some magic) assumes that the
client would use link layer security. unfortunately the client hasn't
enabled -> all packets get dropped (no further communication might be
possible - also with the paa).

this is bad.

> > other scenarios that requires PaC to have a say in this.

ciao
hannes