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 (2012/02/10 15:34), Alper Yegin wrote: >>> 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 >>>>>> Pana@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pana >>>>> >>>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
