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

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Mon, 13 February 2012 09:41 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 8560E21F8796 for <pana@ietfa.amsl.com>; Mon, 13 Feb 2012 01:41:48 -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 xOLJ8LDU2xeP for <pana@ietfa.amsl.com>; Mon, 13 Feb 2012 01:41:47 -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 25A2221F8789 for <pana@ietf.org>; Mon, 13 Feb 2012 01:41:47 -0800 (PST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q1D9fbOP015305 for <pana@ietf.org>; Mon, 13 Feb 2012 18:41:37 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id q1D9fbCp020000 for pana@ietf.org; Mon, 13 Feb 2012 18:41:37 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA19999; Mon, 13 Feb 2012 18:41:37 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q1D9fafN020878 for <pana@ietf.org>; Mon, 13 Feb 2012 18:41:36 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q1D9e5hD028431; Mon, 13 Feb 2012 18:40:05 +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 <0LZB0000OS9CH7E0@mail.po.toshiba.co.jp> for pana@ietf.org; Mon, 13 Feb 2012 18:41:36 +0900 (JST)
Date: Mon, 13 Feb 2012 18:41:30 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <4F38D179.5000203@toshiba.co.jp>
To: pana@ietf.org
Message-id: <4F38DACA.7050302@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
Content-transfer-encoding: 7bit
References: <4F38CF54.4070206@toshiba.co.jp> <4F38D179.5000203@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
Subject: Re: [Pana] Fwd: Re: 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 09:41:48 -0000

The behavior I mentioned is stated in RFC 5191:

"
   I (IP Reconfiguration)

      If set, it indicates that the PaC is required to perform IP
      address reconfiguration after successful authentication and
      authorization phase to configure an IP address that is usable for
      exchanging data traffic across EP.  This bit is set by the PAA
      only for PANA-Auth-Request messages in the authentication and
      authorization phase.  For other messages, this bit MUST be
      cleared.
"

I think the right thing is to just refer to RFC 5191 for the behavior
iwth the 'I' bit set.

Yoshihiro Ohba


(2012/02/13 18:01), Yoshihiro Ohba wrote:
> Forgot to include pana mailing list..
> 
> -------- Original Message --------
> Subject: Re: [Pana] I-D Action: draft-yegin-pana-unspecified-addr-05.txt
> Date: Mon, 13 Feb 2012 17:52:36 +0900
> From: Yoshihiro Ohba<yoshihiro.ohba@toshiba.co.jp>
> To: Alper Yegin<alper.yegin@yegin.org>
> 
> (2012/02/09 18:11), Alper Yegin wrote:
> 
> (snip)
> 
>>> ---------------------------------------------------------------------
>>>
>>> (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.
>>
> 
> I have been interpreting the original text as setting 'I' bit for all
> PAR messages sent by the PAA in the authentication and authorization
> phase and clearing the bit for subsequent PAR messages.  With this
> behavior, the PAA can set the 'I' bit from the very first PAR message
> and the PaC can immediately stop PANA authentication if the PaC does
> not expect IP address update.  I think we need a bit more discussion
> on this.
> 
> Yoshihiro Ohba
> 
>>
>>> [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
>