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

(2012/02/09 21:39), Alper Yegin wrote:
>>> 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?
>> Yes. To shorten a PANA Message, we can send an EAP-Payload AVP in
>> another PANA Message.
>>
> 
> OK.
> 
> 
> 
>> 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?
>>
> 
> 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.
> 

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

> Alper
> 
> 
> 
>> [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
>>
>> (2012/02/09 18:11), Alper Yegin wrote:
>>> Hello,
>>>
>>> Thank you for the review and feedback.
>>>
>>> On Feb 9, 2012, at 7:44 AM, Yasuyuki Tanaka wrote:
>>>
>>>> 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.
>>>>
>>>
>>>
>>> OK.
>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> (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.
>>>
>>>
>>> Let us consider that.
>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> (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.
>>>>
>>>
>>> I think this is an ambiguity with the RFC 5191. PAR with 'C' bit makes sense.
>>>
>>>
>>>> [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.
>>>>
>>>
>>>
>>> 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
>>>> Pana@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pana
>>>
>>
> 
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www.ietf.org/mailman/listinfo/pana
> 