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

Alper Yegin <alper.yegin@yegin.org> Thu, 09 February 2012 09:12 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 2A4C921F8522 for <pana@ietfa.amsl.com>; Thu, 9 Feb 2012 01:12:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.289
X-Spam-Level:
X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 IqkSkBSA5mFB for <pana@ietfa.amsl.com>; Thu, 9 Feb 2012 01:12:26 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3979F21F8441 for <pana@ietf.org>; Thu, 9 Feb 2012 01:12:26 -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 0LdYlu-1SLALJ3C6M-00iGEL; Thu, 09 Feb 2012 04:12:15 -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: <4F335D45.7040404@isl.rdc.toshiba.co.jp>
Date: Thu, 09 Feb 2012 11:11:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3882200C-6C19-4775-9BFA-E3ADC9CC2829@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>
To: Yasuyuki Tanaka <yatch@isl.rdc.toshiba.co.jp>
X-Mailer: Apple Mail (2.1257)
X-Provags-ID: V02:K0:JY6REnr8/ENfArOOSWmkSEV3gnc8ohQvyGHVbXc7gwl bE2UYnqxcCCgLu8DOacJ5kJ18uoB65ti9g3ascVpj8gFnHszSO kkp/EAMZwnGqa3TPJujzZXSKCCn1AFwnHjAo5jHF1o8r2OPUFF Niugs255EPYIhNnf4f721iJrbE2MKckN08uiTMU7zPgcsU4OxM Jnc3+tAHILvQ7mqZEibZTUwzBNJEgUzIM1ZWTUAcT03a94meLZ JfU92YHw3UpTPX7tQjyKJdf5XgkgOSzZurFEjSzoZNd85dru3U 7U8h8O9YwUJzBnV0iVmDpzqHPvTE/4iT50xyJIjOWhXtiZPHwk osvrBUqUdKRsGqpM10wQSRB4Ps7++zs4+HPJ5ILkvdWyiaVXMl tyAspLhlKx2Pw==
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 09:12:27 -0000

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