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

[Alper Yegin <[e-mail]>]

>> 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.
> 

I think you are right.

Alper


> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/pana
>>>> 
>>> 
>> 
>> _______________________________________________
>> Pana mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pana
>> 
> 
> _______________________________________________
> Pana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pana