Subject: Re: [Pana] I-D Action: draft-yegin-pana-unspecified-addr-05.txt

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 09 Feb 2012 14:44:37 +0900

Hi all,

I have four comments about the draft. I put them at the bottom of
this mail. Please see them.

Best,
Yasuyuki Tanaka

---------------------------------------------------------------------

(1) Page 4, Paragraph 1
It would be helpful to add text about the source port number and the
destination port number of the PCI as below.

[edited]
   Step 1: The PaC initiates PANA by sending a broadcasted PCI carrying
   a Token AVP that contains a random value generated by the PaC.

! The source IPv4 address of the PCI is set to 0.0.0.0. The source
! port number is chosen by the PaC. The destination IPv4 address is
! set to 255.255.255.255. The destination port number is the PANA port
! number (716).

[original]
   Step 1: The PaC initiates PANA by sending a broadcasted PCI carrying
   a Token AVP that contains a random value generated by the PaC.

   The source IPv4 address of the PCI is set to 0.0.0.0.  The
   destination IPv4 address is set to 255.255.255.255.

---------------------------------------------------------------------

(2) Figure 1, Page 4

If the PAA want to initiate re-authentication, PAA have to know PaC's
IPv4 address which is configured by DHCP.

It would be better that Figure 1 has messages related to "PaC Updating
Its IP Address" described in Section 5.6, RFC 5191.

[Section 5.6. in RFC 5191]
   After the PaC has changed its IP address used for PANA, it MUST send
   any valid PANA message.  If the message that carries the new PaC IP
   address in the Source Address field of the IP header is valid, the
   PAA MUST update the PANA session with the new PaC address.  If there
   is an established PANA SA, the message MUST be protected with an
   AUTH AVP.
---------------------------------------------------------------------

(3) Page 6, Paragraph 3

I have no idea which PAR should have 'I' bit. Every PAR sent by
PAA should have 'I' bit? Or, only a PAR with 'C' bit should have
'I' bit? (I think the latter is preferable.)

I've referred to RFC 5191, but I've not found the answer.

[original]
   The PAA SHALL set the 'I' (IP Reconfiguration) bit of PAR messages
   in authentication and authorization phase so that the PaC proceeds
   to IP address configuration.

---------------------------------------------------------------------

(4) Page 6, Paragraph 7
I don't think that the description about the size of the largest PANA
is correct. This is because the initial PAR could have multiple
Integrity-Algorithm AVPs and PRF-Algorithm AVPs. This specification is
described in Section 4.1, RFC 5191.

[Section 4.1. in RFC 5191]
    the PAA sends the initial PANA-Auth-Request carrying one or more
    PRF-Algorithm AVPs and one or more Integrity-Algorithm AVPs for the
    PRF and integrity algorithms supported by it, respectively.

In my understanding, it is sufficient to consider a PANA Message which
has only one EAP-Payload AVP for "Message Size Considerations". In
other words, the minimum PANA MTU size is equivalent to the size of a
PANA message which has only one EAP-Payload AVP.

---------------------------------------------------------------------

---

From: Alper Yegin <[email-masked]>
Date: Thu, 9 Feb 2012 11:11:57 +0200

Hello,

Thank you for the review and feedback.

> this mail. Please see them.

OK.

Let us consider that.

I think this is an ambiguity with the RFC 5191. PAR with 'C' bit makes sense.

>  to IP address configuration.

We are trying to find the the size of the largest PANA message.
The largest PANA message is possibly not the very first PAR from the PAA (unlike the current draft states).
Such a PAR can be carrying a EAP-Request/Identity, hence not really be caring a minimum EAP MTU size.
A subsequent PAR can be carrying that (and it'd not have the Integrity-Algorithm, PRF-Algorithm, and Token AVPs).

Are you using the same reasoning for your above suggestion?

Alper

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

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 09 Feb 2012 20:45:57 +0900

Hello,

 > The largest PANA message is possibly not the very first PAR
 > from the PAA (unlike the current draft states). Such a PAR can
 > be carrying a EAP-Request/Identity, hence not really be caring
 > a minimum EAP MTU size.  A subsequent PAR can be carrying
 > that (and it'd not have the Integrity-Algorithm, PRF-Algorithm,
 > and Token AVPs).
 >
Yes. To shorten a PANA Message, we can send an EAP-Payload AVP in
another PANA Message.

Strictly speaking, RFC 5191 has no upper limit on the number of
PRF-Algorithm AVPs and Integrity-Algorithm AVPs which are
contained in a PAR. The size of a PANA message might be the
maximum size of the UDP data... Is this correct?

[Figure 4, RFC 5191]
    The table uses the following symbols:

    0     The AVP MUST NOT be present in the message.

    0-1   Zero or one instance of the AVP MAY be present in the message.
          It is considered an error if there is more than one instance of
          the AVP.

    1     One instance of the AVP MUST be present in the message.

    0+    Zero or more instances of the AVP MAY be present in the
          message.

                          +---------------------------+
                          |        Message Type       |
                          +---+---+---+---+---+---+---+
    Attribute Name        |PCI|PAR|PAN|PTR|PTA|PNR|PNA|
    ----------------------+---+---+---+---+---+---+---+
    AUTH                  | 0 |0-1|0-1|0-1|0-1|0-1|0-1|
    EAP-Payload           | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
    Integrity-Algorithm   | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
    Key-Id                | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
    Nonce                 | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
    PRF-Algorithm         | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
    Result-Code           | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
    Session-Lifetime      | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
    Termination-Cause     | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
    ----------------------+---+---+---+---+---+---+---+

    Figure 4: AVP Occurrence Table

Best,
Yasuyuki Tanaka

---

From: Alper Yegin <[email-masked]>
Date: Thu, 9 Feb 2012 14:39:15 +0200

OK.

> maximum size of the UDP data... Is this correct?

Right.

Nevertheless, the max message would be reached with the EAP-carrying PAR messages, like you say. 

Even though there is not limit on the number of *-Algorithms, it'd be a reasonable number not to cause the message going beyond an EAP-carrying PAR message in size.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 10 Feb 2012 03:26:40 +0900

> Even though there is not limit on the number of *-Algorithms, it'd be a reasonable number not to cause the message going beyond an EAP-carrying PAR message in size.

In that logic, the max message would be a PAR in re-authentication
phase where an EAP-Paylaod AVP carrying an EAP method and additionally
an AUTH AVP.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 10 Feb 2012 08:34:08 +0200

> phase where an EAP-Paylaod AVP carrying an EAP method and additionally

I think you are right.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 13 Feb 2012 17:59:02 +0900

Alper,

I have a second thought.   Probably there is no use case for PANA
re-authentication phase with the use of unspecified IPv4 address
because the PaC is expected to obtain a specified IPv4 address after
successful PANA authentication phase.  So I think we don't need to
consider AUTH AVP for the max message computation.

Yoshihiro Ohba