Subject: Re: [Pana] PANA WG last call: draft-ietf-pana-framework-02

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 3 Oct 2004 17:41:26 -0700

The draft is in good shape.  Mostly are editorials.

1) In section 10.2,

    When PANA authentication is used for bootstrapping L3 security, L2 security
     is not necessarily to exist even after PANA authentication. Instead, IPsec-based
     data traffic is bootstrapped from PANA.

I am not sure i understand this well. Are we saying that if we use PANA for bootstrapping
L3 security, we don't need L2 security even after PANA authentication. If so, it can be reworded

    When PANA authentication is used for bootstrapping L3 security, IPsec can be used for
     protecting the data traffic and L2 protection can be avoided completely.

2) In section 10.2.2,

      Upon successful PANA authentication, the
      traffic switches to the controlled port.  Host configuration,
      including obtaining an (potentially new) IP address, takes place on
      this port.  Usual DHCP-based, and also in the case of IPv6 stateless
      autoconfiguration, mechanism is available to the PaC.
                               ^
      Perhaps the last sentence can be reworded to

      DHCP and IPv6 stateless autoconfiguration mechanism is available to the PaC.

3) In section 10.2.2,

   When a PaC does not have a PMK for the AP, the following procedure is
   taken:

   1.  The PaC associates with the AP.

   2.  The PaC configures a PRPA by using DHCP (in the case of IPv4) or
       configures a link-local address (in the case of IPv6), and then
       runs PANA by using the address.

   3.  Upon successful authentication, the PaC obtains a PMK for each AP
       controlled by the PAA.

    At step (3), how does it obtain a PMK for each AP controlled by the PAA ?
    Perhaps a more basic question is how is AAA-key, PANA_MAC_KEY
    and PMK are related ? We should also mention that the AP is doing open
    system authentication mode.

3) Can we not merge capability discovery into the previous section ? It looks like
     10.2.3 is the first thing that would happen before the steps mentioned in
     section 10.2.2.

-mohan

----- Original Message ----- 
From: "Alper Yegin" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 20, 2004 4:48 PM
Subject: [Pana] PANA WG last call: draft-ietf-pana-framework-02

> 
> This message announces the PANA WG last call on PANA Framework document
> (draft-ietf-pana-framework-02). The last call will conclude on Nov 3rd,
> 2004.
> 
> Please read and review the document, and register your feedback on the
> PANA mailing list (even if it is a simple "I read the document and it is
> ready to proceed.").
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-02.txt
> 
> - PANA WG chairs
> 
> 
> 
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 17:42:34 -0500

Hi Mohan,

>      protecting the data traffic and L2 protection can be avoided completely.

The proposed sentence gives an impression that L2 protection is
something needs to be avoided.  I don't think that is the actual
intention.  So how about this?

"
When PANA authentication is used for bootstrapping L3 security, IPsec
can be used for protecting the data traffic and L2 security is not
necessarily to exist even after PANA authentication.
"

>       DHCP and IPv6 stateless autoconfiguration mechanism is available to the PaC.

OK.

>     system authentication mode.

Good point.  PMK for each EP should be drived from AAA-Key, as IKE
pre-shared secret is derived from it.  We can clarify this in the document.

>      10.2.3 is the first thing that would happen before the steps mentioned in

But capability discovery is also related to section 10.2 and 10.2.1.  So I think 
10.2.3 should not be merged with 10.2.2.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 04 Nov 2004 03:23:36 +0100

Hi all, Document is good for me but I would like to do a pair of 
comments related with section 10.2.1:

I think it is more focused on PAA side than PaC side. I mean for example :
"
Note that for all of the cases described in this section, PBR
   (PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA
   [I-D.ietf-pana-pana] should occur after installing the authorization
   parameter to AR, so that IKE can be performed immediately after PANA
   is successfully completed.
"
But what happen in the PaC? I think we should add here that PaC should 
configure its SPDs before sending PBA for example.

The same happens in the figures , nothing about PaC behaviour.

Second comment is taking into account text above and figures 
11,12,13,14. PAA sends PaC-DI to EP BEFORE PBR/PBA exchange. However PaC 
sends Device-Id in the PBA message.

Also it could be related with Mohan's comment:

"

In the case of IPsec, the device identifier is not know until the IKE is run. So, during
the PBR/PBA exchange the right device identifier is not known, right ? How can
the PaC include the device identifier in that case ?

"
I would add how could PAA configure EP before PBR/PBA following current 
draft-pana-framework?

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 19:11:33 -0500

> configure its SPDs before sending PBA for example.

On the PaC side, the SPD can be configured after sending PBA.  Also,
as the PaC is the initiator of IKE messaging, there is no situation
where the first IKE request is received from the EP.  So I think we do
not need to focus on PaC side regarding the timing to install the
authorization parameter.

> sends Device-Id in the PBA message.

Since the Device-Id can be extracted from the IP header, the PAA can
send PaC-DI to EP BEFORE PBR/PBA exchange.  However, this
authorization should be finally revoked if subsequent PBR/PBA exchange
does not succeed.  Perhaps need some text to explain this.

Thanks,

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 04 Nov 2004 18:15:19 +0100

Hi Yoshi... please see my comments below.

>not need to focus on PaC side regarding the timing to install the
That's right. Agree

>does not succeed.  Perhaps need some text to explain this.
Yes it should be explained.
Thanks.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 5 Oct 2004 12:56:19 -0700

> necessarily to exist even after PANA authentication.
Hmm How about :

"When PANA authentication is used for bootstrapping L3 security, IPsec
can be used for protecting the data traffic and L2 security is not necessary
after PANA authentication.

I guess the intent is to say that L2 security is optional, right ?

> pre-shared secret is derived from it.  We can clarify this in the document.
Okay.

> 10.2.3 should not be merged with 10.2.2.
Okay.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 03 Nov 2004 00:03:27 -0500

> I guess the intent is to say that L2 security is optional, right ?

Yes, and suggested text works for me.

Yoshihiro Ohba