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

Alper Yegin <alper.yegin@yegin.org> Mon, 13 February 2012 14:23 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 2865D21F8597 for <pana@ietfa.amsl.com>; Mon, 13 Feb 2012 06:23:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.392
X-Spam-Level:
X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 qYEverkkNZVX for <pana@ietfa.amsl.com>; Mon, 13 Feb 2012 06:23:10 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C067421F857D for <pana@ietf.org>; Mon, 13 Feb 2012 06:23:09 -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=mrus2) with ESMTP (Nemesis) id 0MDz31-1Rivn71Nj5-00Gtd1; Mon, 13 Feb 2012 09:23:05 -0500
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <4F38DACA.7050302@toshiba.co.jp>
Date: Mon, 13 Feb 2012 16:22:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C1B29DE-1216-4B4E-8E12-1D6062788B14@yegin.org>
References: <4F38CF54.4070206@toshiba.co.jp> <4F38D179.5000203@toshiba.co.jp> <4F38DACA.7050302@toshiba.co.jp>
To: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
X-Mailer: Apple Mail (2.1257)
X-Provags-ID: V02:K0:nO3nNNqs6t3Gf0RU5bQ+w9fL2h/NZrm3GwEwqBzLR3Q 7aNrZsGyXVQsEq+tiRkKYPbhE932446vzoO/ti1kg9AufUhXdh En5YU2dEcbusRj355QjZu3xeceK4JDjzycCvvqQqjtVUyBeYfT 2l5K8nfclYmDav+pbIG+o78zUMZ4I4sTGndvrG226IXxU4sjXt g/DfHVWOpzRzPQaUd98SmzAd2euhNroSuqjwmB5Nq5GbjAQR+k CXt2Mzta3pNHVkMi9PchQromPQBZyjNmIjc1+XdQPaK7a3M2a/ dmU/SBDqr7sPxJOX1MhGPvnMS41e29OVC+xe7fu1+C5NZtczRL KudUKUeVJr9OVlG+TXnO60cwLbAgC+ZxPQ75qKPLYEX+qnrhax wR77mfIdsZr0w==
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 14:23:15 -0000

OK, fine, let's do that.

On Feb 13, 2012, at 11:41 AM, Yoshihiro Ohba wrote:

> 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
>> 
> 
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www.ietf.org/mailman/listinfo/pana