Subject: [Pana] review of pana-08

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Jun 2005 14:19:39 +0300

Hello folks,

I have reviewed draft-ietf-pana-pana-08.txt. Here are my
questions and comments:

Technical:

>    PANA can carry any
>    authentication method that can be specified as an EAP method, and it
>    can be used on any link that can carry IP.

The former part may be too strong, particularly if we start dictating
what requirements EAP methods must meet. I think its easy to just delete
this part from the abstract, or change it to "Different authentication
methods can be used within the EAP framework, and PANA can be
used over different types of links as long as those carry IP."

>    o  If the first EAP authentication has failed, the PAA can choose not
>       to perform the second EAP authentication by clearing the S-flag of
>       the PANA-FirstAuth-End-Request message.  In this case, the S-flag
>       of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be
>       cleared.  If the S-flag of the PANA-FirstAuth-End-Request message
>       is set when the first EAP authentication has failed, the PaC can
>       choose not to perform the second EAP authentication by clearing
>       the S-flag of the PANA-FirstAuth-End-Answer message.  If the first
>       EAP authentication failed and the S-flag is not set in the PANA-
>       FirstAuth-End-Answer message as a result of those operations, the
>       PANA session MUST be immediately deleted.  Otherwise, the second
>       EAP authentication MUST be performed.

I think we may have discussed this in the past, but I still don't
understand why we need to continue if one of the authentications
fail. Is there a specific real-world scenario where this would be useful?

>          When the S-flag is set in a PANA-Start-Request message it
>          indicates that PAA is willing to offer separate NAP and ISP
>          authentication.  When the S-flag is set in a PANA-Start-Answer
>          message it indicates that the PaC accepts on performing
>          separate NAP and ISP authentication.  The PaC may also respond

I'd like to understand whether the S-flag can also appear in
the Reauth-Request message or not. If yes, does this mean that
the initial 2-step authentication can change to a 1-step authentication
in the reauth phase?

>       N (No configuration)
>
>          The PaC does not have to (if sent by PAA) or will not (if sent
>          by PaC) configure a new IP address after PANA.
>
>       D (DHCP)
>
>          The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP
>          [RFC2131] [RFC3315] to configure a new IP address after PANA.
>
>       A (stateless autoconfiguration)
>
>          The PaC can/will use stateless IPv6 address autoconfiguration
>          [RFC2462] to configure a new IP address after PANA.
>
>       T (DHCP with IPsec tunnel mode)
>
>          The PaC can/will use [RFC3456] to configure a new IP address
>          after PANA.
>
>       I (IKEv2)
>
>          The PaC can/will use [I-D.ietf-ipsec-ikev2] to configure a new
>          IP address after PANA.

Is there some guidance as to what bits must at least be
set here? (ANd what do server/client sides have to support,
as a consequence)?

First guess: either N or one of the other bits must be set.

ALso, is there a difference wrt IPv6 and IPv4 here? What if you want to
retrieve both IPv4 and IPv6 addresses after the authentication
has occurred.

> Security considerations stemming from the use of EAP and
> EAP methods are discussed in [RFC3748].

Perhaps you should add eap-keying as an (informational)
reference here.

>    A return-
>    routability test does not provide additional protection as PANA
>    traffic is not routed but simply forwarded on-link.  It is difficult
>    to prevent this threat entirely.

This sentence may have to be revised a bit, now that we allow
multiple hops.

Editorial:

>    networks and 3GPP2 networks with crytographically-secured cdma2000

Either this is a new technique, or s/cryto/crypto/

>    5.   Protocol Design Details and Processing Rules . . . . . . . .  25
>      5.1  Transport Layer  . . . . . . . . . . . . . . . . . . . . .  25
>        5.1.1  Fragmentation  . . . . . . . . . . . . . . . . . . . .  25
>      5.2  Sequence Number and Retransmission . . . . . . . . . . . .  25

Looking at the contents page, it seems that 5.1 might better fit
section 4, and then you could call section 5 simply as "Processing
Rules". Maybe in that case also change s/6. PANA Headers and Formats/
6. Header Format/, and maybe even split section 7 to two independent
parts, one to describe messages and another one to describe AVPs.

>    There are components that are part of a complete secure network
>    solution but are outside of the PANA protocol specification,

s/network solution/network access solution/

> either the expiration of a finite session lifetime or failed
> liveness tests would do the job.

s/would do the job/would clean up the session at the other end/

> administratively scoped multicast address (TBD) and UDP port (TBD).

I have found that s/TBD/To Be Assigned by IANA/ is
easier from the point of view of the later processing of
this draft, as the IANA can simply search for its name.

--Jari

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

---

From: Sasikanth Bharadwaj <[email-masked]>
Date: Wed, 15 Jun 2005 17:25:15 +0530

Hi

Here are a few corrections needed in PANA draft 8

In Section 4.3
 " PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted
   based on the retransmission rule described in Section 5.2."

Section 8 states that retransmission happens only for request messages and
Start-Answer message when stateless discovery is used

In Section 5.2
" If the received PANA-Start-Request message included a Cookie AVP (an
indication of
  stateless PAA discovery), the PaC MUST retransmit the PANA-PAA-Discover
message
  until the first PANA-Auth-Request message is received."

But it is the PANA-Start-Answer message that has to be retransmitted after
receiving the
Start-Request message containing a cookie AVP. It is clearer in section 4.2
so may be removed from here

In Figure 10 - AVP occurrence table
PBR message carries PPAC AVP only in case of successful authentication
Therefore it has to be 0-1 in the table for PPAC AVP
Same change applies to the ABNF notation as well

Thanks and Regards

Sasikanth

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 Jun 2005 08:35:28 -0400

> so may be removed from here

You are right.  Section 5.2 was incorrect in that "PANA-PAA-Discover"
should have been "PANA-Start-Answer".  As you indicated, section 4.2
is clearer on this behavior, and it is better to remove the following
paragraph from section 5.2:

"
   The initial discovery and handshake phase requires special handling.
   The PaC MUST retransmit the PANA-PAA-Discover message if a subsequent
   PANA-Start-Request message is not received in time.  Even though a
   PANA-Start-Request message is received, the PANA-PAA-Discover message
   may still have to be retransmitted.  This is because stateless PAA
   discovery requires one time transmission of a solicited PANA-Start-
   Request message.  The PAA MUST NOT start a timer and retransmit the
   request in order to avoid state creation.  If the received PANA-
   Start-Request message included a Cookie AVP (an indication of
   stateless PAA discovery), the PaC MUST retransmit the PANA-PAA-
   Discover message until the first PANA-Auth-Request message is
   received.  Otherwise, the PaC can rely on the PAA to retransmit the
   PANA-Start-Request message as soon as the PaC receives the first one
   (i.e., the PaC can stop sending the PANA-PAA-Discover message).
"

> Same change applies to the ABNF notation as well

You are right here as well.  I'll fix Figure 10 as well as ABNF for
PBR as you suggest.

Thank you,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 20 Jun 2005 14:05:27 -0400

Hi Sasikanth,

I forgot to reply to the other comment:

> Start-Answer message when stateless discovery is used

You are right.  Instead of revising this sentense, I'd remove this
sentense since retransmission behavior is described in section 5.2.

Yoshihiro Ohba