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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 25 Apr 2003 16:11:50 -0700

Alper,

> 
> 
> >> 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.
> 
> These are fair questions, which I don't have good answers. 
> I'm just the messenger :)
> 
> > How does the PAA decide which one of the
> > above to use?
> 
> PAA's configuration indicates which one of these is 
> applicable. Note: This config is per PAA, not per PaC.

Ok.

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

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

Isn't this sufficient ?

-mohan

> Alper
> 
> 
> >> 
> >> 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: Alper Yegin <[email-masked]>
Date: Fri, 25 Apr 2003 16:57:26 -0700

Mohan,

> are concerned about service theft, enforce L2 or L3.

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)

> preventing both. So, the network says

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.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 24 Apr 2003 14:47:05 -0700

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

> 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

Subject: Re: question: pana messaging
From: Yoshihiro Ohba <[email-masked]>
To: Alper Yegin <[email-masked]>
Cc: Mohan Parthasarathy <[email-masked]>, Yoshihiro Ohba <[email-masked]>, Hannes Tschofenig <[email-masked]>, [email-masked]
Date: Thu, 17 Apr 2003 00:17:54 -0400

On Wed, Apr 16, 2003 at 07:08:10PM -0700, Alper Yegin wrote:
> > 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.
> 
> 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...]

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

> 
> If we were to enable such a scenario, I'd prefer PaC explicitly indicating
> its intentions.
> 
> > This means client chooses, PAA does the
> > setup, acks and then PaC begins the real negotiation. Is this
> > a strong enough reason ?
> 
> Alper
> 
>