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

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Mon, 13 February 2012 08:59 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
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 909EB21F866E for <pana@ietfa.amsl.com>; Mon, 13 Feb 2012 00:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level:
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 k46LlayqurVT for <pana@ietfa.amsl.com>; Mon, 13 Feb 2012 00:59:11 -0800 (PST)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 75B8221F864E for <pana@ietf.org>; Mon, 13 Feb 2012 00:59:11 -0800 (PST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q1D8x8WU027256; Mon, 13 Feb 2012 17:59:08 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id q1D8x8PX001946; Mon, 13 Feb 2012 17:59:08 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id TAA01945; Mon, 13 Feb 2012 17:59:08 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q1D8x8Va028726; Mon, 13 Feb 2012 17:59:08 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q1D8x0ef019648; Mon, 13 Feb 2012 17:59:00 +0900 (JST)
Received: from [133.196.16.108] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LZB000RRQAJH7B0@mail.po.toshiba.co.jp>; Mon, 13 Feb 2012 17:59:08 +0900 (JST)
Date: Mon, 13 Feb 2012 17:59:02 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <60E5034E-55F4-473C-801E-F9174771C7C7@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
Message-id: <4F38D0D6.9040106@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
Content-transfer-encoding: 7bit
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> <2A30F62A-241D-4261-8BFD-572F6714A52A@yegin.org> <4F340FE0.2090308@toshiba.co.jp> <60E5034E-55F4-473C-801E-F9174771C7C7@yegin.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
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: Mon, 13 Feb 2012 08:59:12 -0000

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