9 Feb 2012 12:45
Re: I-D Action: draft-yegin-pana-unspecified-addr-05.txt
Yasuyuki Tanaka <yatch <at> isl.rdc.toshiba.co.jp>
2012-02-09 11:45:57 GMT
2012-02-09 11:45:57 GMT
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).
>
> 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.
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
(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 <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pana
>
RSS Feed