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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 28 Apr 2003 11:14:56 -0700

Yoshihiro,

> 
> 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.
> 
Ok, I see your point now. But it is just not the clients who are
affected
by service theft. As a network operator, I don't want someone to get
free
service. 

-mohan

> 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
> 
> 
> On Mon, Apr 28, 2003 at 09:30:16AM -0700, Mohan Parthasarathy wrote:
> > 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 03:06:05 -0700

> by service theft. As a network operator, I don't want someone to get

OK, I have overlooked that point.  A network might not want to allow
multiple devices to share the same device identifier even in a very
short amount of time.  So if per-packet protection is enforced, and if
there is some user A and gains access to a network with a device-id,
it is not possible for his/her friend using a separate device to
configure the same device-id and access the network while A is not
sending/receiving packets.

So it seems that service theft has two aspects, one from client side
and the other from network side.  I think it might be better to
describe these two aspects in draft-ietf-pana-threats-eval-03.txt.

Thanks,
Yoshihiro Ohba