From yatch@isl.rdc.toshiba.co.jp Wed Feb 8 21:44:41 2012 Return-Path: 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 BC89211E8094 for ; Wed, 8 Feb 2012 21:44:41 -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 3hPb6tKn9sYW for ; Wed, 8 Feb 2012 21:44:40 -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 3808911E808D for ; Wed, 8 Feb 2012 21:44:39 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q195icts018077 for ; Thu, 9 Feb 2012 14:44:38 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q195icBG001701 for pana@ietf.org; Thu, 9 Feb 2012 14:44:38 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id QAA01700; Thu, 9 Feb 2012 14:44:38 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q195icw2022123 for ; Thu, 9 Feb 2012 14:44:38 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q195iU5G028815; Thu, 9 Feb 2012 14:44:30 +0900 (JST) Received: from [133.196.16.71] (ncg-dhcp71.isl.rdc.toshiba.co.jp [133.196.16.71]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 9071C97CA6; Thu, 9 Feb 2012 14:44:37 +0900 (JST) Message-ID: <4F335D45.7040404@isl.rdc.toshiba.co.jp> Date: Thu, 09 Feb 2012 14:44:37 +0900 From: Yasuyuki Tanaka User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pana@ietf.org References: <20111216133844.32034.20748.idtracker@ietfa.amsl.com> <35748338-4BE5-40AD-96C4-EAE501162372@yegin.org> <4025A151-3A1E-431F-8DB9-798EE717E2FA@yegin.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:44:41 -0000 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. --------------------------------------------------------------------- (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. --------------------------------------------------------------------- (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. [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. --------------------------------------------------------------------- From alper.yegin@yegin.org Thu Feb 9 01:12:27 2012 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: <4F335D45.7040404@isl.rdc.toshiba.co.jp> Date: Thu, 9 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> <4025A151-3A1E-431F-8DB9-798EE717E2FA@yegin.org> <4F335D45.7040404@isl.rdc.toshiba.co.jp> To: Yasuyuki Tanaka 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, >=20 > I have four comments about the draft. I put them at the bottom of > this mail. Please see them. >=20 > Best, > Yasuyuki Tanaka >=20 > --------------------------------------------------------------------- >=20 > (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. >=20 > [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. >=20 > ! 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). >=20 > [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. >=20 > 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. >=20 OK. > --------------------------------------------------------------------- >=20 > (2) Figure 1, Page 4 >=20 > If the PAA want to initiate re-authentication, PAA have to know PaC's > IPv4 address which is configured by DHCP. >=20 > It would be better that Figure 1 has messages related to "PaC Updating > Its IP Address" described in Section 5.6, RFC 5191. >=20 > [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. > --------------------------------------------------------------------- >=20 > (3) Page 6, Paragraph 3 >=20 > 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.) >=20 > I've referred to RFC 5191, but I've not found the answer. >=20 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. >=20 > --------------------------------------------------------------------- >=20 > (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. >=20 > [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. >=20 > 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. >=20 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 > --------------------------------------------------------------------- >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www.ietf.org/mailman/listinfo/pana From yatch@isl.rdc.toshiba.co.jp Thu Feb 9 03:46:00 2012 Return-Path: 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 D3C7021F8702 for ; Thu, 9 Feb 2012 03:46:00 -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 JHfFVFFE9heK for ; Thu, 9 Feb 2012 03:46:00 -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 B3B2021F8514 for ; Thu, 9 Feb 2012 03:45:59 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q19BjwAM021072 for ; Thu, 9 Feb 2012 20:45:58 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q19BjwDP023568 for pana@ietf.org; Thu, 9 Feb 2012 20:45:58 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id WAA23567; Thu, 9 Feb 2012 20:45:58 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q19Bjvf9013258 for ; Thu, 9 Feb 2012 20:45:58 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q19BjHn6019446; Thu, 9 Feb 2012 20:45:17 +0900 (JST) Received: from [133.196.16.71] (ncg-dhcp71.isl.rdc.toshiba.co.jp [133.196.16.71]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 9A7FF97CA6; Thu, 9 Feb 2012 20:45:57 +0900 (JST) Message-ID: <4F33B1F5.2010607@isl.rdc.toshiba.co.jp> Date: Thu, 09 Feb 2012 20:45:57 +0900 From: Yasuyuki Tanaka User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Alper Yegin References: <20111216133844.32034.20748.idtracker@ietfa.amsl.com> <35748338-4BE5-40AD-96C4-EAE501162372@yegin.org> <4025A151-3A1E-431F-8DB9-798EE717E2FA@yegin.org> <4F335D45.7040404@isl.rdc.toshiba.co.jp> <3882200C-6C19-4775-9BFA-E3ADC9CC2829@yegin.org> In-Reply-To: <3882200C-6C19-4775-9BFA-E3ADC9CC2829@yegin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 11:46:01 -0000 Hello, > 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. 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? [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 > From alper.yegin@yegin.org Thu Feb 9 04:39:46 2012 Return-Path: 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 ; 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 ; 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 ; 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 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> <4025A151-3A1E-431F-8DB9-798EE717E2FA@yegin.org> <4F335D45.7040404@isl.rdc.toshiba.co.jp> <3882200C-6C19-4775-9BFA-E3ADC9CC2829@yegin.org> <4F33B1F5.2010607@isl.rdc.toshiba.co.jp> To: Yasuyuki Tanaka 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >=20 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? >=20 Right. Nevertheless, the max message would be reached with the EAP-carrying PAR = messages, like you say.=20 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: >=20 > 0 The AVP MUST NOT be present in the message. >=20 > 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. >=20 > 1 One instance of the AVP MUST be present in the message. >=20 > 0+ Zero or more instances of the AVP MAY be present in the > message. >=20 > +---------------------------+ > | 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 | > ----------------------+---+---+---+---+---+---+---+ >=20 > Figure 4: AVP Occurrence Table >=20 > Best, > Yasuyuki Tanaka >=20 > (2012/02/09 18:11), Alper Yegin wrote: >> Hello, >>=20 >> Thank you for the review and feedback. >>=20 >> On Feb 9, 2012, at 7:44 AM, Yasuyuki Tanaka wrote: >>=20 >>> Hi all, >>>=20 >>> I have four comments about the draft. I put them at the bottom of >>> this mail. Please see them. >>>=20 >>> Best, >>> Yasuyuki Tanaka >>>=20 >>> = --------------------------------------------------------------------- >>>=20 >>> (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. >>>=20 >>> [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. >>>=20 >>> ! 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). >>>=20 >>> [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. >>>=20 >>> 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. >>>=20 >>=20 >>=20 >> OK. >>=20 >>> = --------------------------------------------------------------------- >>>=20 >>> (2) Figure 1, Page 4 >>>=20 >>> If the PAA want to initiate re-authentication, PAA have to know = PaC's >>> IPv4 address which is configured by DHCP. >>>=20 >>> It would be better that Figure 1 has messages related to "PaC = Updating >>> Its IP Address" described in Section 5.6, RFC 5191. >>>=20 >>> [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. >>=20 >>=20 >> Let us consider that. >>=20 >>> = --------------------------------------------------------------------- >>>=20 >>> (3) Page 6, Paragraph 3 >>>=20 >>> 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.) >>>=20 >>> I've referred to RFC 5191, but I've not found the answer. >>>=20 >>=20 >> I think this is an ambiguity with the RFC 5191. PAR with 'C' bit = makes sense. >>=20 >>=20 >>> [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. >>>=20 >>> = --------------------------------------------------------------------- >>>=20 >>> (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. >>>=20 >>> [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. >>>=20 >>> 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. >>>=20 >>=20 >>=20 >> 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). >>=20 >> Are you using the same reasoning for your above suggestion? >>=20 >> Alper >>=20 >>=20 >>=20 >>> = --------------------------------------------------------------------- >>>=20 >>>=20 >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www.ietf.org/mailman/listinfo/pana >>=20 >=20 From yoshihiro.ohba@toshiba.co.jp Thu Feb 9 10:26:51 2012 Return-Path: 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 AC59121E8033 for ; Thu, 9 Feb 2012 10:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.089 X-Spam-Level: X-Spam-Status: No, score=-8.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, 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 EXgaiUeAg51M for ; Thu, 9 Feb 2012 10:26:50 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBC221E802F for ; Thu, 9 Feb 2012 10:26:50 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q19IQndF023711 for ; Fri, 10 Feb 2012 03:26:49 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q19IQncZ024487 for pana@ietf.org; Fri, 10 Feb 2012 03:26:49 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id DAA24486; Fri, 10 Feb 2012 03:26:49 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q19IQnal014795 for ; Fri, 10 Feb 2012 03:26:49 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q19IPKe9024379; Fri, 10 Feb 2012 03:25:20 +0900 (JST) Received: from [133.199.16.205] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LZ500JEJ1WLW8I0@mail.po.toshiba.co.jp> for pana@ietf.org; Fri, 10 Feb 2012 03:26:49 +0900 (JST) Date: Fri, 10 Feb 2012 03:26:40 +0900 From: Yoshihiro Ohba In-reply-to: <2A30F62A-241D-4261-8BFD-572F6714A52A@yegin.org> To: pana@ietf.org Message-id: <4F340FE0.2090308@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> <4025A151-3A1E-431F-8DB9-798EE717E2FA@yegin.org> <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> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:26:51 -0000 (2012/02/09 21:39), Alper Yegin wrote: >>> 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. > 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. 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 > From alper.yegin@yegin.org Thu Feb 9 22:34:14 2012 Return-Path: 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 CDBA911E8088 for ; Thu, 9 Feb 2012 22:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 SGDx83j2XWNu for ; Thu, 9 Feb 2012 22:34:14 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D4F4511E8075 for ; Thu, 9 Feb 2012 22:34:13 -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 0ML6iX-1Rw1Am0ZA9-000urr; Fri, 10 Feb 2012 01:34:12 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <4F340FE0.2090308@toshiba.co.jp> Date: Fri, 10 Feb 2012 08:34:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60E5034E-55F4-473C-801E-F9174771C7C7@yegin.org> References: <20111216133844.32034.20748.idtracker@ietfa.amsl.com> <35748338-4BE5-40AD-96C4-EAE501162372@yegin.org> <4025A151-3A1E-431F-8DB9-798EE717E2FA@yegin.org> <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> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:g5oxYtk8vxLIgsJF6WaKAObPPQRiM8C3yB9qRas1tRh Pfnfpgh66BK3DWJbCM1Ehox3U4mbekxph3X8sNUPIlTScTGNBy bKtY2XOyE1Q2vPYDCDOx7kpUNGlBA4OuEBy1jBRId8ZZoHhTb8 anDlrrVZ0t6+e7Us533zHTcFyvGJp1ZwhzVfED44nU6v3aFFkY 660QbP0sVo1zTbEYrdCeYBYtjUZ0Oge3Kt2IICbbJNV5U8xRdm EylbF1qc/dhuafMmSWLdhdMiRrU69FLLAC0V8pCeJuAh3X+v3N 7ROFPCWnyKDdwDwrNTYHu+44w4YWbBqKIg9vmNrRK10YrzJl9R 4lpZ2L0oJr8wa/sqAd02os55NmbJMYmsIm0JhPKUSFWvQEC7Rz Vs17PRTqZ0+FQ== 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 06:34:14 -0000 >> Right. >>=20 >> Nevertheless, the max message would be reached with the EAP-carrying = PAR messages, like you say. >>=20 >> 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. >>=20 >=20 >=20 > 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. >=20 I think you are right. Alper > Yoshihiro Ohba >=20 >> Alper >>=20 >>=20 >>=20 >>> [Figure 4, RFC 5191] >>> The table uses the following symbols: >>>=20 >>> 0 The AVP MUST NOT be present in the message. >>>=20 >>> 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. >>>=20 >>> 1 One instance of the AVP MUST be present in the message. >>>=20 >>> 0+ Zero or more instances of the AVP MAY be present in the >>> message. >>>=20 >>> +---------------------------+ >>> | 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 | >>> ----------------------+---+---+---+---+---+---+---+ >>>=20 >>> Figure 4: AVP Occurrence Table >>>=20 >>> Best, >>> Yasuyuki Tanaka >>>=20 >>> (2012/02/09 18:11), Alper Yegin wrote: >>>> Hello, >>>>=20 >>>> Thank you for the review and feedback. >>>>=20 >>>> On Feb 9, 2012, at 7:44 AM, Yasuyuki Tanaka wrote: >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I have four comments about the draft. I put them at the bottom of >>>>> this mail. Please see them. >>>>>=20 >>>>> Best, >>>>> Yasuyuki Tanaka >>>>>=20 >>>>> = --------------------------------------------------------------------- >>>>>=20 >>>>> (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. >>>>>=20 >>>>> [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. >>>>>=20 >>>>> ! 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). >>>>>=20 >>>>> [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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>>=20 >>>> OK. >>>>=20 >>>>> = --------------------------------------------------------------------- >>>>>=20 >>>>> (2) Figure 1, Page 4 >>>>>=20 >>>>> If the PAA want to initiate re-authentication, PAA have to know = PaC's >>>>> IPv4 address which is configured by DHCP. >>>>>=20 >>>>> It would be better that Figure 1 has messages related to "PaC = Updating >>>>> Its IP Address" described in Section 5.6, RFC 5191. >>>>>=20 >>>>> [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. >>>>=20 >>>>=20 >>>> Let us consider that. >>>>=20 >>>>> = --------------------------------------------------------------------- >>>>>=20 >>>>> (3) Page 6, Paragraph 3 >>>>>=20 >>>>> 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.) >>>>>=20 >>>>> I've referred to RFC 5191, but I've not found the answer. >>>>>=20 >>>>=20 >>>> I think this is an ambiguity with the RFC 5191. PAR with 'C' bit = makes sense. >>>>=20 >>>>=20 >>>>> [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. >>>>>=20 >>>>> = --------------------------------------------------------------------- >>>>>=20 >>>>> (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. >>>>>=20 >>>>> [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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>>=20 >>>> 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). >>>>=20 >>>> Are you using the same reasoning for your above suggestion? >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>>> = --------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Pana mailing list >>>>> Pana@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pana >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www.ietf.org/mailman/listinfo/pana >>=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www.ietf.org/mailman/listinfo/pana From yoshihiro.ohba@toshiba.co.jp Mon Feb 13 00:59:12 2012 Return-Path: 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 ; 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 ; 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 ; 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 In-reply-to: <60E5034E-55F4-473C-801E-F9174771C7C7@yegin.org> To: Alper Yegin 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> <4025A151-3A1E-431F-8DB9-798EE717E2FA@yegin.org> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > From yoshihiro.ohba@toshiba.co.jp Mon Feb 13 01:01:53 2012 Return-Path: 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 DD25E21F874F for ; Mon, 13 Feb 2012 01:01:53 -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 ThftxI63BrQi for ; Mon, 13 Feb 2012 01:01:53 -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 D1AA621F8749 for ; Mon, 13 Feb 2012 01:01:52 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q1D91p4j028548 for ; Mon, 13 Feb 2012 18:01:51 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q1D91pGR005249 for pana@ietf.org; Mon, 13 Feb 2012 18:01:51 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA05245; Mon, 13 Feb 2012 18:01:51 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q1D91pCD000440 for ; Mon, 13 Feb 2012 18:01:51 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q1D90J1e013436; Mon, 13 Feb 2012 18:00:19 +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 <0LZB000XXQF2H7B0@mail.po.toshiba.co.jp> for pana@ietf.org; Mon, 13 Feb 2012 18:01:50 +0900 (JST) Date: Mon, 13 Feb 2012 18:01:45 +0900 From: Yoshihiro Ohba In-reply-to: <4F38CF54.4070206@toshiba.co.jp> To: "pana@ietf.org" Message-id: <4F38D179.5000203@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit X-Forwarded-Message-Id: <4F38CF54.4070206@toshiba.co.jp> References: <4F38CF54.4070206@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 09:01:54 -0000 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 To: Alper Yegin (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 > From yoshihiro.ohba@toshiba.co.jp Mon Feb 13 01:41:48 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > To: Alper Yegin > > (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 > From alper.yegin@yegin.org Mon Feb 13 06:23:15 2012 Return-Path: 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 ; 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 ; 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 ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: >=20 > " > I (IP Reconfiguration) >=20 > 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. > " >=20 > I think the right thing is to just refer to RFC 5191 for the behavior > iwth the 'I' bit set. >=20 > Yoshihiro Ohba >=20 >=20 > (2012/02/13 18:01), Yoshihiro Ohba wrote: >> Forgot to include pana mailing list.. >>=20 >> -------- 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 >> To: Alper Yegin >>=20 >> (2012/02/09 18:11), Alper Yegin wrote: >>=20 >> (snip) >>=20 >>>> = --------------------------------------------------------------------- >>>>=20 >>>> (3) Page 6, Paragraph 3 >>>>=20 >>>> 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.) >>>>=20 >>>> I've referred to RFC 5191, but I've not found the answer. >>>>=20 >>>=20 >>> I think this is an ambiguity with the RFC 5191. PAR with 'C' bit = makes sense. >>>=20 >>=20 >> 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. >>=20 >> Yoshihiro Ohba >>=20 >>>=20 >>>> [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. >>>>=20 >>>> = --------------------------------------------------------------------- >>>>=20 >>>> (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. >>>>=20 >>>> [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. >>>>=20 >>>> 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. >>>>=20 >>>=20 >>>=20 >>> 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). >>>=20 >>> Are you using the same reasoning for your above suggestion? >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>> = --------------------------------------------------------------------- >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Pana mailing list >>>> Pana@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pana >>>=20 >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www.ietf.org/mailman/listinfo/pana >>>=20 >>=20 >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www.ietf.org/mailman/listinfo/pana >>=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www.ietf.org/mailman/listinfo/pana