Subject: [Pana] Issue 71: POPA mechanism discovery

From: Alper Yegin <[email-masked]>
Date: Mon, 26 Apr 2004 23:43:57 -0700

Proposed changes to handle Issue 71.
Comments welcome.

[1] 4.1.1 Payload Encoding

Add:

  o  PPAC AVP: Post-PANA address configuration AVP. Conveys the list
     of IP address configuration methods available when sent by the PAA,
     and the chosen method when sent by the PaC.

[2] 4.3 Authentication Phase

Change:

   PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted
   based on the retransmission rule described in Appendix A.

To:

   Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST
   include PPAC AVP, which helps PAA to inform PaC about whether a new
   IP address MUST be configured and the available methods to do so, and
   PaC to indicate the chosen method.

   PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted
   based on the retransmission rule described in Appendix A.

[3] Figure 8:

Change the following segment:

        <-----     PANA-Bind-Request(x+3,y+2)
                      [EAP{Success}, Device-Id, Lifetime,
Protection-Cap., 
                       MAC]
         ----->     PANA-Bind-Answer(y+3,x+3)
                      [Device-Id, Protection-Cap., MAC]

To:

        <-----     PANA-Bind-Request(x+3,y+2)
                      [EAP{Success}, Device-Id, Lifetime,
Protection-Cap., 
                       PPAC, MAC]
         ----->     PANA-Bind-Answer(y+3,x+3)
                      [Device-Id, Protection-Cap., PPAC, MAC]

[4] 9.3.7 PANA-Bind-Request (PBR)

Change:

   PANA-Bind-Request (PBR) is sent by the PAA to the PaC.

         PANA-Bind-Request ::= < PANA-Header: 4, REQ >
                       < Session-Id >
                       < Device-Id >
                       { EAP-Payload }
                       { Result-Code }
                       [ Session-Lifetime ]
                       [ Protection-Capability ]
                       [ Key-Id ]
                    *  [ EP-Device-Id ]
                    *  [ AVP ]
                   0*1 < MAC >
To:

   PANA-Bind-Request (PBR) is sent by the PAA to the PaC.

         PANA-Bind-Request ::= < PANA-Header: 4, REQ >
                       < Session-Id >
                       < Device-Id >
                       { EAP-Payload }
                       { Result-Code }
                       { PPAC }
                       [ Session-Lifetime ]
                       [ Protection-Capability ]
                       [ Key-Id ]
                    *  [ EP-Device-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

[5] 9.3.8 PANA-Bind-Answer (PBA)

Change:

   PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a
   PANA-Result-Request message.

         PANA-Bind-Answer ::= < PANA-Header: 4 >
                       < Session-Id >
                       < Device-Id >
                       [ Key-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

To:

   PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a
   PANA-Result-Request message.

         PANA-Bind-Answer ::= < PANA-Header: 4 >
                       < Session-Id >
                       < Device-Id >
                       { PPAC }
                       [ Key-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

[6] New section 9.4.17

9.4.17 Post-PANA Address Configuration (PPAC) AVP

   The data field of PPAC AVP (Code 1040) is of type Unsigned32. The
   AVP data is used to carry a set of flags which maps to various
   IP address configuration methods. When sent by the PAA, the AVP
   MUST have at least one of the flags set, and MAY have more than one
   set. When sent by the PaC, only one of the flags MUST be set.

   The format of the AVP data is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |N|D|A|T|I|                   Reserved                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PPAC flags:

      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 [IKE2] to configure a new IP address after
        PANA.

      Reserved

        These flag bits are reserved for future use, and MUST be set to
        zero, and ignored by the receiver.

   Unless the N-flag is set, the PaC MUST configure a new IP address
using 
   one of the methods indicated by the other flags. Refer to [PANAFWK]
for a
   detailed discussion on when these methods can be used.

[7] Figure 10

Add a new row on Figure 10:

                          +-----------------------------------------+
                          |        Message                          |
                          |          Type                           |
                          +-----+-----+-----+-----+-----+-----+-----+
      Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
      --------------------+-----+-----+-----+-----+-----+-----+-----+
      PPAC                |  0  |  0  |  0  |  0  |  1  |  1  |  0  |
      --------------------+-----+-----+-----+-----+-----+-----+-----+

                          +-------------------------------+
                          |      Message                  |
                          |       Type                    |
                          +------+------+-----+-----+-----+
      Attribute Name      | PRAR | PRAA | PTR | PTA | PER |
      --------------------+------+------+-----+-----+-----+
      PPAC                |  0   |  0   |  0  |  0  |  0  |
      --------------------+------+------+-----+-----+-----+

[8] Additional references:

[RFC2131]
[RFC2462]
[RFC3456]
[IKE2]
[PANAFWK]

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 17:18:03 -0700

This looks good.

Thanks,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 17:18:03 -0700

This looks good.

Thanks,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Apr 2004 07:54:59 -0700

I had some more thought and came up with something about error
handling for PPAC:

What PaC should do if it does not support none of IP address
configuration methods included in the PPAC AVP in PBR?  The PaC might
need return a PBA with an error result code and a new result code
might be needed for this.  In this case, the PBA might not include a
PPAC AVP.  Also, when a AAA-Key is available at the time when the PBA
is received, the PBA message as well as the PBR message might be
protected with a MAC AVP.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Apr 2004 07:54:59 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 30 Apr 2004 11:19:07 -0700

> might be needed for this.  

We can define a new code similar to
PANA_PROTECTION_CAPABILITY_UNSUPPORTED.

I think we should also mandate inclusion of a result code in the PBR
than.
That way the PaC can explicitly confirm the success, or indicate the
reason for failure on its part (protection or IP address capability
mismatch)

> In this case, the PBA might not include a
> PPAC AVP.  

OK.

> Also, when a AAA-Key is available at the time when the PBA

Right.

Alper

> >       |N|D|A|T|I|                   Reserved
|
> >                           |        Message
|
> >                           |          Type
|

---

From: Alper Yegin <[email-masked]>
Date: Fri, 30 Apr 2004 11:19:07 -0700

OK.

Right.

Alper

|
|
|

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Apr 2004 11:44:34 -0700

> I think we should also mandate inclusion of a result code in the PBR

I guess you meant PBA in the above sentence.

> reason for failure on its part (protection or IP address capability

I agree.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Apr 2004 11:44:34 -0700

I agree.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 30 Apr 2004 14:55:17 -0700

Proposed text updated based on the recent feedback.
Comments welcome.

Add:

Change:

To:

   Additionally, PANA-Bind-Request MUST include a PPAC AVP, which helps
PAA
   to inform PaC about whether a new IP address MUST be configured and
the 
   available methods to do so. PaC MUST include a PPAC AVP in order to 
   indicate its choice of method when there is a match between the
methods 
   offered by the PAA and the methods available on the PaC. When there
is no 
   match, a PPAC AVP MUST NOT be included and the Result-Code AVP MUST
be 
   set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the PANA-Bind-Answer
message.   

[3] Figure 4:

Change: 

To:

         <-----     PANA-Bind-Request(x+3,y+2)
                       [EAP{Success}, Device-Id, Result-Code, Lifetime, 
                        Protection-Cap., MAC]
         ----->     PANA-Bind-Answer(y+3,x+3)
                       [Device-Id, Result-Code, Protection-Cap., MAC]

[4] Figure 8:

To:

        <-----     PANA-Bind-Request(x+3,y+2)
                      [EAP{Success}, Device-Id, Result-Code, Lifetime, 
                       Protection-Cap., PPAC, MAC]
         ----->     PANA-Bind-Answer(y+3,x+3)
                      [Device-Id, Result-Code, Protection-Cap., PPAC,
MAC]

[5] 9.3.7 PANA-Bind-Request (PBR)

Change:

[6] 9.3.8 PANA-Bind-Answer (PBA)

Change:

To:

                       [ PPAC ]
                       [ Key-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

[7] New section 9.4.17

       0                   1                   2                   3

   PPAC flags:

      N (No configuration)

      D (DHCP)

      I (IKEv2)

      Reserved

[8] Add to 9.4.7.2:

PANA_PPAC_CAPABILITY_UNSUPPORTED  5017

      Error code from PaC to PAA.  This error is returned in a 
      PANA-Bind-Answer message when there is no match between the list
of 
      PPAC methods offered by the PAA and the ones available on the Pac.

[9] Figure 10

Add a new row on Figure 10, and update for Result-Code AVP:

                          +-----------------------------------------+
                          |        Message                          |
                          |          Type                           |
                          +-----+-----+-----+-----+-----+-----+-----+
      Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
      --------------------+-----+-----+-----+-----+-----+-----+-----+
      Result-Code         |  0  |  0  |  0  |  0  |  1  |  1  |  0  |
      PPAC                |  0  |  0  |  0  |  0  |  1  | 0-1 |  0  |
      --------------------+-----+-----+-----+-----+-----+-----+-----+

      Result-Code         |  0   |  0   |  0  |  0  |  1  |

[10] Additional references:

[RFC2131]
[RFC2462]
[RFC3456]
[IKE2]
[PANAFWK]

---

From: Alper Yegin <[email-masked]>
Date: Fri, 30 Apr 2004 14:55:17 -0700

Add:

Change:

To:

[3] Figure 4:

Change: 

To:

[4] Figure 8:

To:

Change:

Change:

To:

[7] New section 9.4.17

       0                   1                   2                   3

   PPAC flags:

      N (No configuration)

      D (DHCP)

      I (IKEv2)

      Reserved

[8] Add to 9.4.7.2:

[9] Figure 10

[RFC2131]
[RFC2462]
[RFC3456]
[IKE2]
[PANAFWK]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Apr 2004 16:00:18 -0700

The text looks good.  Just one minor editorial comment.

>                        [Device-Id, Result-Code, Protection-Cap., MAC]

I guess a PPAC AVP also appears in both PBR and PBA here.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Apr 2004 16:00:18 -0700

Yoshihiro Ohba