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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 28 Apr 2003 09:30:16 -0700

Yoshihiro,

In your attached mail, you indicate the network may still want to
forward
unprotected packets for the PaC. You still have not given a reason for
this.
You also indicate that Pac needs to use strong protection only to
protect
traffic from others. This is not true. Per-packet protection is needed
for
service theft. So, I am not sure I understand what you are saying.

-mohan

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, April 24, 2003 2:47 PM
> To: Alper Yegin
> Cc: Mohan Parthasarathy; [email-masked]
> Subject: Re: Choice of ciphering (was Re: question: pana messaging)
> 
> 
> On Fri, Apr 25, 2003 at 04:57:26PM -0700, Alper Yegin wrote:
> > Mohan,
> > 
> > >>>  It is very complex.
> > >> 
> > >> I'm not sure if it is really that complex. At the end of 
> PANA, both 
> > >> the PaC and PAA knows which ciphering needs to be turned on. 
> > >> Basically PAA indicated which one(s) are mandatory, and PaC 
> > >> additionally chose optional one(s). If L2 ciphers is included in 
> > >> this final list, it needs to be turned on. This is just 
> like what 
> > >> would have happened if only L2 ciphers were used. If L3 
> ciphers is 
> > >> included, it'll be turned on next. This is independent 
> of whether 
> > >> L2 ciphering is on or off. Am I missing something?
> > >> 
> > > I think the optional part is ncreasing the number
> > > of combinations. For example, what is the use of "no L2, L3 
> > > optional". Why does the network want to keep something 
> optional ?  
> > > If you are concerned about service theft, enforce L2 or L3.
> 
> My answer is in the attached email which I sent last week.
> But please see my further comments below.
> 
> > 
> > This question is more about the motivation of this 
> flexibility, which 
> > I'll defer to someone else to respond...(because I said 
> earlier that I 
> > didn't have a good answer)
> > 
> > > 
> > >> 
> > >>> All you need is whether the network can
> > >>> support L2 and/or L3 and client chooses one of them. Why isn't 
> > >>> this sufficient ?
> > >> 
> > >> I think you meant to say "L2 or L3 but not both", right? 
> Doing both 
> > >> L2 and L3 is what you are questioning earlier. Some 
> clients doing 
> > >> L2 while some other doing L3 is complex.
> > >> 
> > > Thinking more about it, perhaps there is not much use in 
> preventing 
> > > both. So, the network says
> > > 
> > > 1) L2 AND L3
> > > 2) L2 or L3
> > > 3) L2
> > > 4) L3
> > 
> > Let me rewrite it a bit:
> > 
> > 1) L2 and L3
> > 2) L2
> > 3) L3
> > 4) None
> > 
> > This would be the network mandating what ciphering to use. 
> > Alternatively, the network could blend this with the optional ones 
> > (hence 9 possible combinations I listed earlier), but at 
> the end the 
> > PaC would pick one and it'd boil down to executing one of these 4 
> > combinations. So I don't see where the complexity is. Is it 
> with some 
> > clients are using L2 ciphering while some others using 
> L2+L3 ciphering 
> > (because L3 is optional)?
> > 
> > I removed your original "2) L2 or L3" because I believe that one is 
> > really complex. If L2 ciphering is necessary and available in an 
> > access network, then it must be mandatory. I don't think an 
> optional 
> > L3 ciphering can fully replace that. Also, if we allow some 
> clients do 
> > L2 ciphering only, some others L3 ciphering only, I suspect 
> all L2 and 
> > L3 enforcement points should be aware of each other, and aware of 
> > every client's choice. Otherwise, there might be some 
> security holes.
> 
> If every (L2 or L3) EP that provides an optional ciphering 
> performs an appropriate access control to filter out packets 
> from unauthorized devices, I don't think EPs need to be aware 
> of each other.  But I don't have a good answer for what the 
> "appropriate access control" is, 
> so I tend to agree on the Alper's 4 patterns above for now.
> 
> Yoshihiro Ohba
> 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 26 Apr 2003 01:34:17 -0700

I meant " protect traffic from others" includes protecting traffic
from others that spoof MAC address and/or IP address of the PaC (so
service theft is covered).  I think that if appropriate filtering is
performed at EP for both cryptographically protected and unprotected
packets, service theft would not occur at least for clients that use
per-packet protection even there are some clients that do not use
per-packet protection.  Of course clients that do not use per-packet
protection are vulnerable to service theft, but if they don't much
care about service theft (e.g., when they are charged with a
flat-rate), and allowing them to connect the network does not
compromise security for clients with using per-packet protection, the
network might want to allow them to be connected for providing broader
level of service availability.

On the other hand, defining an appropriate filtering may be difficult
as I mentioned in a separate email, so in many cases a network might
not want to make per-packet protection optional.

Yoshihiro Ohba