Subject: question: pana messaging

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 14 Apr 2003 14:52:37 +0200

hi all,

the pana draft describes some messages. these messages have a certain
semantic and are in most cases directional e.g.

      PANA-Start-Request       <--------
      PANA-Start-Answer        -------->

      PANA-Auth-Request        <--------
      PANA-Auth-Answer         -------->

why isn't it possible to use these messages in both directions? it would be
good to have a generic message which can be executed from both entities (pac
and paa) especially with respect to extensibility.

furthermore, if the pac is preconfigured with the address of the paa then
there is no need for a discovery message. hence the PANA-Start-Request (or
better the PANA-Auth-Request) could go from the pac to the paa. currently
the cookie stuff mandates a certain direction (thank you dan for pointing to
this issue).

here are my questions:
a) should we add a message to carry AVPs in both directions?
c) should we optimize signaling if the pac is already configured with the ip
address of the paa?

please read the pana draft and verify that the signaling message handling
works in all your  scenarios.

ciao
hannes

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 14 Apr 2003 19:41:47 -0400

Hi Hannes,

> the cookie stuff mandates a certain direction (thank you dan for pointing to

Even if the PaC is preconfigured with the address of the paa,
cookie-based 3-way handshake is needed to avoid resource consumption 
attacks during the handshake phase.  Currently this is done by 
discovery/start(-req)/start(-ans) message and I don't think we can omit 
these exchanges when the PAA does not have any state for the PaC before 
the handshake.

On the other hand, we can omit some of the messages at the time of
EAP-based re-authentication in whiich the PAA already has a state for
the PaC.  It looks like:

   PaC      PAA  Message(tseq,rseq)[AVPs] 
   ----------------------------------------------------- 
   // Discovery and initial handshake phase 
      ----->     PANA_discover(0,0) 
    
   // Authentication phase 
      <-----     PANA_auth(p,q)[EAP, MAC]     // or PANA-Auth-Request 
      ----->     PANA_auth(q+1,p)[EAP, MAC]   // or PANA-Auth-Answer
        .
        .

where the sequence numbers continue from the previous message exchange
instead of being started from fresh ones.  If EAP-based
re-authentication is initiated from PAA, the first discover message is
not needed.

We can add this optimized behavior to section 4.4.

> a) should we add a message to carry AVPs in both directions?

So far I don't see a requirement for this.

> c) should we optimize signaling if the pac is already configured with the ip

I would say that we should optimize signaling when the PAA has already a
state for the PaC regardless of whether the PaC is already configured
with the IP address of the PAA.

> works in all your  scenarios.

Yoshihiro Ohba

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 16 Apr 2003 15:14:58 +0200

hi yoshi,

please see my comments inline:

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Dienstag, 15. April 2003 01:42
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: question: pana messaging
>
>
> Hi Hannes,
>

you are right with the 3-way handshake. you also know that i am not fully
satisfied with the dos protection as it is. this is, however, a different
issue which needs to be added to the open issues list.

>    PaC      PAA  Message(tseq,rseq)[AVPs]

i certainly agree with you.

> We can add this optimized behavior to section 4.4.

i would vote for it.

> So far I don't see a requirement for this.

dan mentioned the Reauth-Request(/Answer) message. that would be fine for
me.

there are, however, other messages which could possible carry AVPs from both
entities such as the Data-Protection AVP.

in figure 4 of the current draft it says:

      <-----     PANA_success(x+3,y+2)                // F-flag set
                   [EAP{Success}, Device-Id, Data-Protection, MAC]
      ----->     PANA_success_ack(y+3,x+3)
                   [Device-Id, MAC]  // F-flag set

however, the Data-Protection might also be negotiated e.g. not every pac
supports ipsec. hence if the paa forces the pac to use ipsec then no network
access would be possible. if the paa (and the pac) additionally support link
layer security then they could use link layer sec. instead.

furtermore the paa might not be able to trigger ipsec after the finished eap
authentication. for example: the pac starts without an ip address
configured. hence after successful eap auth. the pac obtains an ip address
e.g. using stateful address autoconfig. (dhcp). subsequently ipsec can be
enabled. thereby the client might send a Data-Protection AVP saying that he
is ready to enable ipsec.

this is also an example why it should be possible to update device-id info
at the paa. the pac cannot provide his ip address. later it is, however,
possible.

> with the IP address of the PAA.
ok.

ciao
hannes

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Apr 2003 15:39:27 -0400

Hi Hannes,

On Wed, Apr 16, 2003 at 03:14:58PM +0200, Hannes Tschofenig wrote:

(snip)

> dan mentioned the Reauth-Request(/Answer) message. that would be fine for

OK.

> layer security then they could use link layer sec. instead.

If the access network supports IPsec but does not force PaCs to always
use it, then the Data-Protection AVP can contain a new flag to
indicate whether per-packet protection is required or not.  However,
this still does not mean that negotiation is needed for PANA and I
don't think Data-Protection AVP is needed for PANA_success_ack to 
support the scenario you mentioned.

> is ready to enable ipsec.

When the PAA registers an IP address of the PaC as the device
identifier, it can mean that the PaC is ready to enable IPsec with
using that IP address.  Then the PAA can inform EP of the IP address
and the IKE credential of the PaC so that EP can perform IKE with the
PaC.  I think what we actually need to support this scenario is the
abitility to use both IP address and MAC address as the device
identifier at one time, instead of using either IP address or MAC
address at one time.  However, this still does not mean that
negotiation is needed for PANA.

> at the paa. the pac cannot provide his ip address. later it is, however,

I agree that it should be possible to update device-id information 
for the reason I mentioned above.

Thanks,
Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Apr 2003 16:35:57 -0700

>> layer security then they could use link layer sec. instead.

The simplistic assumption is this: If the link is not multiaccess, we don't
need to worry about L2 or L3 ciphering. Otherwise, if the network has L2
ciphering capability, it requires all of its clients to use it. If not, it
requires all of its clients to use IPsec. These are not negotiable at all.

If we want to extend this, we need to understand: Under what conditions such
negotiation will be useful? For example, allowing some clients to use L2
ciphering whereas others to use only IPsec, does this make sense? Does it
make sense to "allow" some clients to use both L2 ciphering and IPsec after
PANA?

> negotiation is needed for PANA.

I agree that this does not mean negotitation is needed. Still PAA can
indicate IPsec is a must. Only in that case it might mean that PaC can do
DHCP before turning IPsec on.

> for the reason I mentioned above.

It'd be good if someone can start a new thread to discuss "session id".
Please list the usage scenarios of the session id concept (aforementioned
one, fast re-auth, etc.). Note that currently pana-00 is using device ID as
the handle.

Alper

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 18 Apr 2003 15:12:25 +0200

hi alper,

please see my comments inline:

> From: Alper Yegin [mailto:[email-masked]]
> Sent: Donnerstag, 17. April 2003 01:36
> To: Yoshihiro Ohba; Hannes Tschofenig

i wouldn't mandate issues which are subject to network administrators. there
are reasons why you would like to use ipsec although you have link layer
protection.

which security is most appropriate depends on the given scenario, on the
architecture and on the policy issue of the administrator running the
network.

in some multiaccess cases it might be reasonable to only use packet filters
(particularly if accounting is only time-based and network based on data
volume).

> ciphering whereas others to use only IPsec, does this make sense?

why not? some clients might not support ipsec at all. some others have a
"poor" implementation which does not support nesting ipsec (vpn access in
addition to the network access).

 Does it
> make sense to "allow" some clients to use both L2 ciphering and

link layer and network layer security protection terminate a different
locations (usually). depending on which messages you would like to protect
there might be a reason todo both.

furthermore you might have the requirement for heterogenous network access
with mobility where you switch between different link layer technologies.
each link layer provides different security properties. one way to tackle
this problem is to establish security at a high layer (network layer).

> DHCP before turning IPsec on.

i have to state that the term negotiation might not be the best. i think
that there must be a way to indicate which mechanisms a paa supports.

ciao
hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 18 Apr 2003 15:12:23 +0200

hi yoshi,

~snip~

> indicate whether per-packet protection is required or not.

i don't know whether has to be a flag or an object. however, it think that
something similar should be there.

  However,
> support the scenario you mentioned.

maybe negotiation is the wrong term. the paa indicates what it supports and
the client chooses something. this information needs to be somewhere. if we
think about extensibility then a flag might not be the best choice - instead
it would be better to support something which is more extensible.

> address at one time.

i agree with you that we need the abitility to use both IP address and MAC
address as the device identifier at one time.

this is not a negotiation - clearly.
i consider it a negotiation if the paa supports a number of things (even
some stuff we have not yet thought about). and then the client wants to use
something. you could call it notification.

>  However, this still does not mean that

what is wrong with the ability to specify what the paa supports?
furthermore there should be a way for the pac to trigger something. think
about the dhcp based scenario again. the paa might establish packet filters
after the successful authentication with the help of the mac address. then
the client decides that it would be good to enable ipsec (after obtaining an
ip address from the dhcp).

then you need a message which says:

pac             paa

i want to use ipsec (here is my ip address)
---------------->

ok, here is the ip address of the end point (e.g. ep)
<----------------

ok.

ciao
hannes

---

From: Alper Yegin <[email-masked]>
Date: Wed, 23 Apr 2003 12:12:17 -0700

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?

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