Subject: RE: Ciphering choice

From: <[email-masked]>
Date: Wed, 13 Aug 2003 17:24:58 +0300

What about filtering based on IP address (PANA DI) in EP/PAA? 
It is needed both with L2 ciphering and with IPSec. 

This means that PAA must know the correct IP address for the 
PaC. We just can't forget L3, when L2 ciphering is used.

I think that with L2 ciphering we can use L2 MAC and that 
is fine, but PANA needs to take care of IP traffic filtering 
too. Or should we say that IP traffic filtering is the first
priority since PANA is L3 solution.

And no, this is not SEND problem.

- Dan

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 04 August, 2003 23:21
> To: [email-masked]
> Subject: Ciphering choice
> 
> 
> 
> Some of the discussions around the choice of device 
> identifier for Pac is
> stemming from the choice of ciphering. If L2 ciphering will 
> be used, than
> the L2 address must be the DI. If L3 ciphering will be used 
> (i.e., IPsec),
> then the DI must be an IP address.
> 
> Two questions: 
> a) Does it make sense to leave the selection to PaC, or 
> should PAA mandate
> which ciphering should be used?
> b) Does it make sense to enable both L2 and L3 ciphering at 
> the same time?
> 
> Based on the earlier discussions, in my personal opinion, the 
> ciphering
> selection should be based on the access network policy. 
> Hence, this is not
> something for the PaC to decide. I'd say PAA should mandate, 
> and PaC should
> obey the decision.
> 
> As for (b), it was not clear whether this is something needed 
> and useful. In
> order to bind the client authentication to data traffic, one 
> is sufficient.
> 
> I recommend we let PAA specify which one of the two ciphering 
> mechanisms
> will be used (L2 vs. L3), PaC has to obey or leave the 
> network, and the
> device IDs are chosen accordingly.
> 
> Comments?
> 
> Alper
> 
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 13 Aug 2003 13:42:00 -0700

> And no, this is not SEND problem.
Please see my other mail. We need some mechanism to provide
access control. Using Ipsec does help do this. And we can
document this. Now using this to prevent spoofing etc. beyond
the scope.

-mohan

---

From: <[email-masked]>
Date: Fri, 15 Aug 2003 10:56:05 +0300

IPSec is just one possible(?) way to enforce the usage of 
authorized IP addresses, but the more common approach is 
plain packet filtering.

Packet filtering and IPSec are out of the scope PANA, 
since they are access control mechanisms. What is in the 
scope of PANA is to give the right information so that 
access control is possible.

The case where PANA is bootstrapped without an IP address 
(0::0, 0.0.0.0) and after DHCP (or something similar) 
PANA-Rauth message is used to update the DI. This DI is 
the IP address that PaC is allowed to use for accessing 
the network (if IPSec is used then inside tunnel). 

Currently the PANA protocol spec allows only one DI 
to be specified. In the case of physically secure link or 
with L2 ciphering IPSec is not needed, but IP address based 
access control is (to prevent spoofin of other clients 
etc.). With L2 ciphering MAC address is needed as the 
DI(?), but also the IP address. So, we need to have support
for multiple DI AVPs. In addition, PaC may want to use a 
whole subnet (mobile router) or just multiple IP addresses.
PANA must support this.

- Dan

> From: ext Mohan Parthasarathy [mailto:[email-masked]]
> Sent: 13 August, 2003 23:42
> To: Forsberg Dan (NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: RE: Ciphering choice
> 
> 
> 
>  
> >