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

Alper Yegin <alper.yegin@yegin.org> Thu, 09 February 2012 12:39 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6732621F86C5 for <pana@ietfa.amsl.com>; Thu, 9 Feb 2012 04:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.333
X-Spam-Level:
X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaqiHzp-1L3S for <pana@ietfa.amsl.com>; Thu, 9 Feb 2012 04:39:45 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 78F5221F86BB for <pana@ietf.org>; Thu, 9 Feb 2012 04:39:45 -0800 (PST)
Received: from [192.168.2.3] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LlUid-1SUnhd0XGZ-00anMy; Thu, 09 Feb 2012 07:39:33 -0500
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <4F33B1F5.2010607@isl.rdc.toshiba.co.jp>
Date: Thu, 9 Feb 2012 14:39:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A30F62A-241D-4261-8BFD-572F6714A52A@yegin.org>
References: <20111216133844.32034.20748.idtracker@ietfa.amsl.com> <35748338-4BE5-40AD-96C4-EAE501162372@yegin.org> <DB9259A8-E3E1-4A92-805D-1C8A21D03D44@um.es> <4025A151-3A1E-431F-8DB9-798EE717E2FA@yegin.org> <B0A66B63-E291-4704-9BE4-1B4345BC475C@um.es> <4F335D45.7040404@isl.rdc.toshiba.co.jp> <3882200C-6C19-4775-9BFA-E3ADC9CC2829@yegin.org> <4F33B1F5.2010607@isl.rdc.toshiba.co.jp>
To: Yasuyuki Tanaka <yatch@isl.rdc.toshiba.co.jp>
X-Mailer: Apple Mail (2.1257)
X-Provags-ID: V02:K0:xQU6inws8Ob+qEpbkw8ThUFzUPaRLwaiYxYbRRa++bb PxtwzJn1y8Y3n+qOcBNa9cu1I7PrEHABh0TWbbYni9yL1HnXAA 5xyDGPx+6y54yAoS0ddEoHS3Vl4FOqcMA4rUF0r4bnBb7SzqKP /adGaKe/1TA3aFghDtWmey+YJqST5SzYyO2Bu1q4E1SBCdirpc BlJiZjyYrYNt37nz24NnO/2/lmE0WcQDdNsxmL9QgCRglRLDJx u2AjoZ4TB4YGNtrB9XrUcRfOeeEMPw7wLtf+jjitoV0tpADbVJ J+MMDh+y3s+LbbIoZpwDU+WulpRSO6027ImM8HbuzPAe8i2cLu CoIwkb2viZD1tDp2VRYZQqsSiDY253OktmnxfkzqXF60JCids/ siLusrXelvPoA==
Cc: pana@ietf.org
Subject: Re: [Pana] I-D Action: draft-yegin-pana-unspecified-addr-05.txt
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2012 12:39:46 -0000

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