Subject: RE: Choice of ciphering (was Re: question: pana messaging)

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 25 Apr 2003 10:22:37 -0700

> 
> Please see my comment below.
> 
> On Wed, Apr 23, 2003 at 03:05:53PM -0700, Mohan Parthasarathy wrote:
> > 
> > Alper,
> > 
> > > 
> > > The current pana protocol design is quite rigid with respect
> > > to enabling
> > > data protection after pana: The network mandates use of 
> > > either L2 or L3
> > > ciphering, or none. But never both. Client has to accept the 
> > > choice of the
> > > network. That's it.
> > > 
> > > Now we are thinking if we can flex this a bit, that's fine.
> > > 
> > > I think what we are looking at is the ability to provide some 
> > > optional ciphering, or multi-layer protection. Such as:
> > > 
> > > - The network can indicate which ciphering it mandates, and
> > > which it can
> > > optionally provide.
> > > 
> > > For example, at the end of a successful PANA, PAA can indicate 
> > > whether L2 ciphering is optionally provided or mandated, and 
> > > similarly for L3 ciphering. PaC has to use the mandatory 
> one(s), and 
> > > it can indicate its optional choices.
> > > 
> > > Here are the combinations... Network provides:
> > > a- neither L2 nor L3 ciphering.
> > > b- no L2, but optional L3 ciphering.
> > > c- no L2, but mandatory L3 ciphering.
> > > d- optional L2 ciphering, no L3 ciphering.
> > > e- optional L2 ciphering and optional L3 ciphering.
> > > f- optional L2 ciphering and mandatory L3 ciphering.
> > > g- mandatory L2 ciphering, no L3 ciphering.
> > > h- mandatory L2 ciphering and optional L3 ciphering.
> > > i- mandatory L2 ciphering and mandatory L3 ciphering.
> > > 
> > > Does it make sense to have these scenarios?
> > 
> > I think we should try to keep it simple. Why would someone 
> want both 
> > L2 and L3 ciphering ? Is it because L2 is weak ? Then, why 
> don't you 
> > just use L3 ciphering alone. How does the PAA decide which 
> one of the 
> > above to use ? It is very complex. All you need is whether 
> the network 
> > can support L2 and/or L3 and client chooses one of them. Why isn't 
> > this sufficient ?
> 
> L3 ciphering does not protect MAC address spoofing, so a DoS 
> attack such as ARP spoofing is still possible in the case of 
> IPv4.  On the other hand, L2 ciphering does not protect IP 
> address spoofing.  So I think using both L2 and L3 ciphering 
> (at least per-packet integrity

L2 ciphering does not prevent ARP spoofing either. ARP looks
at the inner payload and not the ethernet headers. You need
something like SEND for ARP. Anyway, it is not in the scope of
this WG I guess.

> check) at the same time makes sense for the network where a 
> higher-level of security is required.  But I agree that doing 
> per-packet encryption at both layers might not make sense and 
> thus either L2 encryption or L3 encryption might be enough.
> 
The overhead also may be high when the client is using Ipsec for
his VPN access and it has to do two layers within the access network.
I have not yet enabled WEP on my Ipsec VPN access to see how bad
it is.

> Yoshihiro Ohba
> 
> 
> > > 
> > > When PAA indicates one of the above configurations, PaC will
> > > have to agree
> > > with the mandatory ones, not request the unsupported ones, 
> > > and decide on the
> > > optional ones. So that, at the end of the PANA, the network 
> > > knows which ones
> > > need to be enabled. Of course the order of execution matters.
> > > 
> > > Could this be what we are talking about here?
> > > 
> > > Alper
> > > 
> > -mohan
> > 
> > > 
> > 
> > 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 24 Apr 2003 09:13:22 -0700

> something like SEND for ARP. Anyway, it is not in the scope of

This is true.  Additional filtering that validates ARP payload might
be needed at EP (e.g., access point) for attacks from authenticated
clients that use L2 ciphering.  To do this, PAA would need to inform
EP of both MAC address and IP address and I think providing such a
hook to EP is in the scope of PANA (though filtering itself is out of
the scope of PANA).

However, even (L2 ciphering + filtering ARP at EP) does not prevent
spoofed ARP packets directly (i.e., without passing through EPs) sent
from authenticated and L2-ciphered attackers.  This is basically due
to the lack of cryptographic integrity protection in ARP but still
better than null L2 ciphering in that unauthenticated attackers cannot
launch ARP attacks.

> I have not yet enabled WEP on my Ipsec VPN access to see how bad

It is possible to avoid double encryption with L3 ciphering in the
access network and VPN, if a client that uses IPsec-based VPN can
negotiate a separate IPsec SA with the EP on using NULL encryption
algorithm for a particular destination IP address (i.e., VPN gateway's
address in this case) in addition to an IPsec SA with the EP for
protecting other traffic.  Traffic selector negotiation in IKEv2 can
be used for specifying which traffic belongs to which SA.

It might be difficult to avoid double encryption with L2 ciphering and
VPN, unless L2 ciphering provides integrity protection without
encription or L2 ciphering is turned off with accepting some attacks
below L3.  Disabling VPN encryption is another possibility but no
good since VPN traffic can be eavesdropped on the path between 
EP and VPN gateway.

Yoshihiro Ohba