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