From pana-admin@ietf.org Tue Nov 4 17:32:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09148 for ; Tue, 4 Nov 2003 17:32:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9iT-0003Zd-GK; Tue, 04 Nov 2003 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH738-0008Pk-KE for pana@optimus.ietf.org; Tue, 04 Nov 2003 14:41:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00403 for ; Tue, 4 Nov 2003 14:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH735-0003kf-00 for pana@ietf.org; Tue, 04 Nov 2003 14:41:07 -0500 Received: from [212.55.154.25] (helo=sapo.pt) by ietf-mx with smtp (Exim 4.12) id 1AH735-0003ja-00 for pana@ietf.org; Tue, 04 Nov 2003 14:41:07 -0500 Received: (qmail 31052 invoked by uid 0); 4 Nov 2003 19:40:36 -0000 Received: from unknown (HELO fep05-svc.mail.telepac.pt) (194.65.5.209) by relay5 with SMTP; 4 Nov 2003 19:40:36 -0000 Received: from escritorio1 ([81.193.107.121]) by fep05-svc.mail.telepac.pt (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with SMTP id <20031104194036.FVHJ15244.fep05-svc.mail.telepac.pt@escritorio1> for ; Tue, 4 Nov 2003 19:40:36 +0000 Message-ID: <000801c3a30b$8c696130$ef74fea9@escritorio1> From: "Joaquim Moreira" To: Date: Tue, 4 Nov 2003 19:40:48 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C3A30B.8C230960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Pana] questions Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C3A30B.8C230960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 1 - What are the goals of PANA implementation ? 2 - What are the goals of PANA security for the users ?=20 J.Moreira ------=_NextPart_000_0005_01C3A30B.8C230960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
1 - What are the goals of PANA = implementation=20 ?
2 - What are the goals of PANA = security  for=20 the users ? 
 
J.Moreira
------=_NextPart_000_0005_01C3A30B.8C230960-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 4 17:32:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09163 for ; Tue, 4 Nov 2003 17:32:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9iW-0003aF-QA for pana-archive@odin.ietf.org; Tue, 04 Nov 2003 17:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4MW4kg013774 for pana-archive@odin.ietf.org; Tue, 4 Nov 2003 17:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9iW-0003a5-Id for pana-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09139 for ; Tue, 4 Nov 2003 17:31:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9iU-0006yG-00 for pana-web-archive@ietf.org; Tue, 04 Nov 2003 17:32:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9iT-0006yC-00 for pana-web-archive@ietf.org; Tue, 04 Nov 2003 17:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9iT-0003Zd-GK; Tue, 04 Nov 2003 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH738-0008Pk-KE for pana@optimus.ietf.org; Tue, 04 Nov 2003 14:41:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00403 for ; Tue, 4 Nov 2003 14:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH735-0003kf-00 for pana@ietf.org; Tue, 04 Nov 2003 14:41:07 -0500 Received: from [212.55.154.25] (helo=sapo.pt) by ietf-mx with smtp (Exim 4.12) id 1AH735-0003ja-00 for pana@ietf.org; Tue, 04 Nov 2003 14:41:07 -0500 Received: (qmail 31052 invoked by uid 0); 4 Nov 2003 19:40:36 -0000 Received: from unknown (HELO fep05-svc.mail.telepac.pt) (194.65.5.209) by relay5 with SMTP; 4 Nov 2003 19:40:36 -0000 Received: from escritorio1 ([81.193.107.121]) by fep05-svc.mail.telepac.pt (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with SMTP id <20031104194036.FVHJ15244.fep05-svc.mail.telepac.pt@escritorio1> for ; Tue, 4 Nov 2003 19:40:36 +0000 Message-ID: <000801c3a30b$8c696130$ef74fea9@escritorio1> From: "Joaquim Moreira" To: Date: Tue, 4 Nov 2003 19:40:48 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C3A30B.8C230960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Pana] questions Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C3A30B.8C230960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 1 - What are the goals of PANA implementation ? 2 - What are the goals of PANA security for the users ?=20 J.Moreira ------=_NextPart_000_0005_01C3A30B.8C230960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
1 - What are the goals of PANA = implementation=20 ?
2 - What are the goals of PANA = security  for=20 the users ? 
 
J.Moreira
------=_NextPart_000_0005_01C3A30B.8C230960-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Nov 5 05:26:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29713 for ; Wed, 5 Nov 2003 05:26:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKrQ-0007cT-BT; Wed, 05 Nov 2003 05:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKr6-0007c1-02 for pana@optimus.ietf.org; Wed, 05 Nov 2003 05:25:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29693 for ; Wed, 5 Nov 2003 05:25:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHKr2-0000vi-00 for pana@ietf.org; Wed, 05 Nov 2003 05:25:36 -0500 Received: from alc250.alcatel.be ([195.207.101.250] helo=bt0g2p.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 1AHKr1-0000vI-00 for pana@ietf.org; Wed, 05 Nov 2003 05:25:36 -0500 Received: from btm34m.sh.bel.alcatel.be (btm34m.sh.bel.alcatel.be [138.203.192.124]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id hA58S1r2007616; Wed, 5 Nov 2003 09:28:01 +0100 Received: from alcatel.be (bt0pxa [138.203.85.210]) by btm34m.sh.bel.alcatel.be (8.8.8p2+Sun/8.8.8/1.1) with ESMTP id LAA08494; Wed, 5 Nov 2003 11:25:03 +0100 (MET) Message-ID: <3FA8CFFF.ADFC7266@alcatel.be> Date: Wed, 05 Nov 2003 11:25:03 +0100 From: nagi reddy jonnala Organization: Alcatel Telecom X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Joaquim Moreira CC: pana@ietf.org Subject: Re: [Pana] questions References: <000801c3a30b$8c696130$ef74fea9@escritorio1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.37 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joaquim Moreira wrote: > Hi, 1 - What are the goals of PANA implementation ?2 - What are the > goals of PANA security for the users ? J.Moreira Goals of PANA implementation: Perhaps this a preliminary question that was analysed by the chairs in the initial stages of this WG. Every new comer possibly would have understood a bit from the WG charter page. ( Me too a late starter :) ) Let me try to answer your first question. If you look at the TCP/IP or OSI architecture, we don't find any specification saying this layer should perform the security. Right? Later on depending on the need, some networks adopted it at as part of PPP, some did it as part of Mobile IPv4 and some did it as part of HTTP. To conclude there is no single layer that is identified to perform authentication. For example, in DSL networks, PPPoE protocol is used to authenticate the user. on an ethernet network . Both protocols being the Layer-2 protocols, most of the people wonder why the PPP protocol runs on Ethernet. This PANA group wants to define a protocol on its own (which doesn't depend on any specifc link layer) that allows clients to authenticate themselves to the access network using IP protocols. Another goal also is to avoid deciding which authentication method to use. The authentication method (for eg: MD5, Token Pass or whatever) will be decided by the back end AAA server. PANA Authentication Agent will just act as a pass-through and enables to have the multiple authentication methods. Please look at the PANA charter page for formal description. what are the goals of PANA security to users: ================================= 1) PANA as such doesn't directly provide any new security mechanisms bit it ENABLES the user/network provider to choose from one of the multiple authentication method because PANA uses EAP. 2) PANA will enable the network provider ( no significant advantage to end-user) to do the authentication at one unique place. Without PANA, either depend on the link layer provided authnticationmechanism or in HTTP Web- redirect and so on. -Nagi. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Nov 5 05:26:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29728 for ; Wed, 5 Nov 2003 05:26:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKrT-0007dF-Cj for pana-archive@odin.ietf.org; Wed, 05 Nov 2003 05:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5AQ3f3029336 for pana-archive@odin.ietf.org; Wed, 5 Nov 2003 05:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKrT-0007d2-89 for pana-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 05:26:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29704 for ; Wed, 5 Nov 2003 05:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHKrP-0000w4-00 for pana-web-archive@ietf.org; Wed, 05 Nov 2003 05:25:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHKrP-0000w1-00 for pana-web-archive@ietf.org; Wed, 05 Nov 2003 05:25:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKrQ-0007cT-BT; Wed, 05 Nov 2003 05:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKr6-0007c1-02 for pana@optimus.ietf.org; Wed, 05 Nov 2003 05:25:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29693 for ; Wed, 5 Nov 2003 05:25:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHKr2-0000vi-00 for pana@ietf.org; Wed, 05 Nov 2003 05:25:36 -0500 Received: from alc250.alcatel.be ([195.207.101.250] helo=bt0g2p.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 1AHKr1-0000vI-00 for pana@ietf.org; Wed, 05 Nov 2003 05:25:36 -0500 Received: from btm34m.sh.bel.alcatel.be (btm34m.sh.bel.alcatel.be [138.203.192.124]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id hA58S1r2007616; Wed, 5 Nov 2003 09:28:01 +0100 Received: from alcatel.be (bt0pxa [138.203.85.210]) by btm34m.sh.bel.alcatel.be (8.8.8p2+Sun/8.8.8/1.1) with ESMTP id LAA08494; Wed, 5 Nov 2003 11:25:03 +0100 (MET) Message-ID: <3FA8CFFF.ADFC7266@alcatel.be> Date: Wed, 05 Nov 2003 11:25:03 +0100 From: nagi reddy jonnala Organization: Alcatel Telecom X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Joaquim Moreira CC: pana@ietf.org Subject: Re: [Pana] questions References: <000801c3a30b$8c696130$ef74fea9@escritorio1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.37 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joaquim Moreira wrote: > Hi, 1 - What are the goals of PANA implementation ?2 - What are the > goals of PANA security for the users ? J.Moreira Goals of PANA implementation: Perhaps this a preliminary question that was analysed by the chairs in the initial stages of this WG. Every new comer possibly would have understood a bit from the WG charter page. ( Me too a late starter :) ) Let me try to answer your first question. If you look at the TCP/IP or OSI architecture, we don't find any specification saying this layer should perform the security. Right? Later on depending on the need, some networks adopted it at as part of PPP, some did it as part of Mobile IPv4 and some did it as part of HTTP. To conclude there is no single layer that is identified to perform authentication. For example, in DSL networks, PPPoE protocol is used to authenticate the user. on an ethernet network . Both protocols being the Layer-2 protocols, most of the people wonder why the PPP protocol runs on Ethernet. This PANA group wants to define a protocol on its own (which doesn't depend on any specifc link layer) that allows clients to authenticate themselves to the access network using IP protocols. Another goal also is to avoid deciding which authentication method to use. The authentication method (for eg: MD5, Token Pass or whatever) will be decided by the back end AAA server. PANA Authentication Agent will just act as a pass-through and enables to have the multiple authentication methods. Please look at the PANA charter page for formal description. what are the goals of PANA security to users: ================================= 1) PANA as such doesn't directly provide any new security mechanisms bit it ENABLES the user/network provider to choose from one of the multiple authentication method because PANA uses EAP. 2) PANA will enable the network provider ( no significant advantage to end-user) to do the authentication at one unique place. Without PANA, either depend on the link layer provided authnticationmechanism or in HTTP Web- redirect and so on. -Nagi. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 6 10:13:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12423 for ; Thu, 6 Nov 2003 10:13:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHloj-0003nT-IA; Thu, 06 Nov 2003 10:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlog-0003n8-3V for pana@optimus.ietf.org; Thu, 06 Nov 2003 10:12:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12343 for ; Thu, 6 Nov 2003 10:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlod-0002GX-00 for pana@ietf.org; Thu, 06 Nov 2003 10:12:55 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AHlod-0002GB-00 for pana@ietf.org; Thu, 06 Nov 2003 10:12:55 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id BFB7C35478 for ; Thu, 6 Nov 2003 16:06:10 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id A87983F425 for ; Thu, 6 Nov 2003 16:06:10 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003110616061011906 for ; Thu, 06 Nov 2003 16:06:10 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 866DA3F425 for ; Thu, 6 Nov 2003 16:06:10 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AHlh6-000Aa8-Pd for ; Thu, 06 Nov 2003 16:05:08 +0100 Date: Thu, 6 Nov 2003 16:05:08 +0100 From: Julien Bournelle To: pana@ietf.org Message-ID: <20031106150508.GL72999@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Pana] PANA-Discover message Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hi, as written in the re-authentication part of the PANA draft-02, if the pac wants to initiate a re-authentication it may send a PANA-PAA-Discover with an AVP Session-Id. So, maybe we can change: In 9.3.2 PANA-PAA-Discover PANA-PAA-Discover ::= < PANA-Header: 1 > 0*1 < Device-Id > * [ AVP ] by PANA-PAA-Discover ::= < PANA-Header: 1 > 0*1 < Device-Id > 0*1 < Session-Id > * [ AVP ] and update the AVP Occurence table. (change 0 -> 0-1 in PDI Column) -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 6 10:13:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12438 for ; Thu, 6 Nov 2003 10:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlom-0003oJ-Ov for pana-archive@odin.ietf.org; Thu, 06 Nov 2003 10:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6FD4JG014641 for pana-archive@odin.ietf.org; Thu, 6 Nov 2003 10:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlom-0003o4-Jl for pana-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 10:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12373 for ; Thu, 6 Nov 2003 10:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlok-0002H7-00 for pana-web-archive@ietf.org; Thu, 06 Nov 2003 10:13:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHlok-0002H3-00 for pana-web-archive@ietf.org; Thu, 06 Nov 2003 10:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHloj-0003nT-IA; Thu, 06 Nov 2003 10:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlog-0003n8-3V for pana@optimus.ietf.org; Thu, 06 Nov 2003 10:12:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12343 for ; Thu, 6 Nov 2003 10:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlod-0002GX-00 for pana@ietf.org; Thu, 06 Nov 2003 10:12:55 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AHlod-0002GB-00 for pana@ietf.org; Thu, 06 Nov 2003 10:12:55 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id BFB7C35478 for ; Thu, 6 Nov 2003 16:06:10 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id A87983F425 for ; Thu, 6 Nov 2003 16:06:10 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003110616061011906 for ; Thu, 06 Nov 2003 16:06:10 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 866DA3F425 for ; Thu, 6 Nov 2003 16:06:10 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AHlh6-000Aa8-Pd for ; Thu, 06 Nov 2003 16:05:08 +0100 Date: Thu, 6 Nov 2003 16:05:08 +0100 From: Julien Bournelle To: pana@ietf.org Message-ID: <20031106150508.GL72999@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Pana] PANA-Discover message Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hi, as written in the re-authentication part of the PANA draft-02, if the pac wants to initiate a re-authentication it may send a PANA-PAA-Discover with an AVP Session-Id. So, maybe we can change: In 9.3.2 PANA-PAA-Discover PANA-PAA-Discover ::= < PANA-Header: 1 > 0*1 < Device-Id > * [ AVP ] by PANA-PAA-Discover ::= < PANA-Header: 1 > 0*1 < Device-Id > 0*1 < Session-Id > * [ AVP ] and update the AVP Occurence table. (change 0 -> 0-1 in PDI Column) -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 6 10:19:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13010 for ; Thu, 6 Nov 2003 10:19:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHluW-0004Kd-VO; Thu, 06 Nov 2003 10:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHluJ-0004KJ-2X for pana@optimus.ietf.org; Thu, 06 Nov 2003 10:18:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12965 for ; Thu, 6 Nov 2003 10:18:33 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHluG-0002Ob-00 for pana@ietf.org; Thu, 06 Nov 2003 10:18:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHluG-0002OY-00 for pana@ietf.org; Thu, 06 Nov 2003 10:18:44 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA6FIhF07090 for ; Thu, 6 Nov 2003 17:18:43 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Nov 2003 17:18:42 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Nov 2003 17:18:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 6 Nov 2003 17:18:41 +0200 Message-ID: Thread-Topic: [issue39] PDI message format with re-authentication Thread-Index: AcOkeO3ZMhocrd/9Sc+ichcfG8T+DgAADj9A To: X-OriginalArrivalTime: 06 Nov 2003 15:18:41.0314 (UTC) FILETIME=[42AD0820:01C3A479] Content-Transfer-Encoding: base64 Subject: [Pana] [issue39] PDI message format with re-authentication Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpoaSwNCg0KIGFzIHdyaXR0ZW4gaW4gdGhlIHJlLWF1dGhlbnRpY2F0aW9uIHBhcnQgb2Yg dGhlIFBBTkEgZHJhZnQtMDIsIGlmIHRoZQ0KcGFjIHdhbnRzIHRvIGluaXRpYXRlIGEgcmUtYXV0 aGVudGljYXRpb24gaXQgbWF5IHNlbmQgYQ0KUEFOQS1QQUEtRGlzY292ZXIgd2l0aCBhbiBBVlAg U2Vzc2lvbi1JZC4NCg0KIFNvLCBtYXliZSB3ZSBjYW4gY2hhbmdlOg0KDQpJbiA5LjMuMiBQQU5B LVBBQS1EaXNjb3Zlcg0KDQpQQU5BLVBBQS1EaXNjb3ZlciA6Oj0gPCBQQU5BLUhlYWRlcjogMSA+ DQogICAgICAgICAgICAgICAgMCoxIDwgRGV2aWNlLUlkID4NCiAgICAgICAgICAgICAgICAgKiAg WyBBVlAgXSANCmJ5DQoNClBBTkEtUEFBLURpc2NvdmVyIDo6PSA8IFBBTkEtSGVhZGVyOiAxID4N CiAgICAgICAgICAgICAgICAwKjEgPCBEZXZpY2UtSWQgPg0KCQkwKjEgPCBTZXNzaW9uLUlkID4N CiAgICAgICAgICAgICAgICAgKiAgWyBBVlAgXQ0KDQoNCmFuZCB1cGRhdGUgdGhlIEFWUCBPY2N1 cmVuY2UgdGFibGUuIA0KKGNoYW5nZSAwIC0+IDAtMSBpbiBQREkgQ29sdW1uKQ0KDQotLSANCmp1 bGllbi5ib3VybmVsbGVAaW50LWV2cnkuZnINCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IEVkaXRv cmlhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5hLTAyLnR4dA0KbWVzc2FnZXM6IDE1 NA0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBNdXN0IEZpeA0Kc3RhdHVzOiBObyBEaXNjdXNz aW9uDQp0aXRsZTogUERJIG1lc3NhZ2UgZm9ybWF0IHdpdGggcmUtYXV0aGVudGljYXRpb24NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQQU5BIElz c3VlcyA8cGFuYV9pc3N1ZXNAZGFuZm9yc2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9yc2Jlcmcu aW5mbzo4MDgwL3BhbmEtaXNzdWVzL2lzc3VlMzk+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 6 10:19:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13025 for ; Thu, 6 Nov 2003 10:19:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlub-0004LE-52 for pana-archive@odin.ietf.org; Thu, 06 Nov 2003 10:19:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6FJ5LA016682 for pana-archive@odin.ietf.org; Thu, 6 Nov 2003 10:19:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlub-0004Kz-05 for pana-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 10:19:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12978 for ; Thu, 6 Nov 2003 10:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHluX-0002Om-00 for pana-web-archive@ietf.org; Thu, 06 Nov 2003 10:19:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHluW-0002Oj-00 for pana-web-archive@ietf.org; Thu, 06 Nov 2003 10:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHluW-0004Kd-VO; Thu, 06 Nov 2003 10:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHluJ-0004KJ-2X for pana@optimus.ietf.org; Thu, 06 Nov 2003 10:18:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12965 for ; Thu, 6 Nov 2003 10:18:33 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHluG-0002Ob-00 for pana@ietf.org; Thu, 06 Nov 2003 10:18:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHluG-0002OY-00 for pana@ietf.org; Thu, 06 Nov 2003 10:18:44 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA6FIhF07090 for ; Thu, 6 Nov 2003 17:18:43 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Nov 2003 17:18:42 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Nov 2003 17:18:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 6 Nov 2003 17:18:41 +0200 Message-ID: Thread-Topic: [issue39] PDI message format with re-authentication Thread-Index: AcOkeO3ZMhocrd/9Sc+ichcfG8T+DgAADj9A To: X-OriginalArrivalTime: 06 Nov 2003 15:18:41.0314 (UTC) FILETIME=[42AD0820:01C3A479] Content-Transfer-Encoding: base64 Subject: [Pana] [issue39] PDI message format with re-authentication Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpoaSwNCg0KIGFzIHdyaXR0ZW4gaW4gdGhlIHJlLWF1dGhlbnRpY2F0aW9uIHBhcnQgb2Yg dGhlIFBBTkEgZHJhZnQtMDIsIGlmIHRoZQ0KcGFjIHdhbnRzIHRvIGluaXRpYXRlIGEgcmUtYXV0 aGVudGljYXRpb24gaXQgbWF5IHNlbmQgYQ0KUEFOQS1QQUEtRGlzY292ZXIgd2l0aCBhbiBBVlAg U2Vzc2lvbi1JZC4NCg0KIFNvLCBtYXliZSB3ZSBjYW4gY2hhbmdlOg0KDQpJbiA5LjMuMiBQQU5B LVBBQS1EaXNjb3Zlcg0KDQpQQU5BLVBBQS1EaXNjb3ZlciA6Oj0gPCBQQU5BLUhlYWRlcjogMSA+ DQogICAgICAgICAgICAgICAgMCoxIDwgRGV2aWNlLUlkID4NCiAgICAgICAgICAgICAgICAgKiAg WyBBVlAgXSANCmJ5DQoNClBBTkEtUEFBLURpc2NvdmVyIDo6PSA8IFBBTkEtSGVhZGVyOiAxID4N CiAgICAgICAgICAgICAgICAwKjEgPCBEZXZpY2UtSWQgPg0KCQkwKjEgPCBTZXNzaW9uLUlkID4N CiAgICAgICAgICAgICAgICAgKiAgWyBBVlAgXQ0KDQoNCmFuZCB1cGRhdGUgdGhlIEFWUCBPY2N1 cmVuY2UgdGFibGUuIA0KKGNoYW5nZSAwIC0+IDAtMSBpbiBQREkgQ29sdW1uKQ0KDQotLSANCmp1 bGllbi5ib3VybmVsbGVAaW50LWV2cnkuZnINCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IEVkaXRv cmlhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5hLTAyLnR4dA0KbWVzc2FnZXM6IDE1 NA0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBNdXN0IEZpeA0Kc3RhdHVzOiBObyBEaXNjdXNz aW9uDQp0aXRsZTogUERJIG1lc3NhZ2UgZm9ybWF0IHdpdGggcmUtYXV0aGVudGljYXRpb24NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQQU5BIElz c3VlcyA8cGFuYV9pc3N1ZXNAZGFuZm9yc2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9yc2Jlcmcu aW5mbzo4MDgwL3BhbmEtaXNzdWVzL2lzc3VlMzk+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 6 16:57:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03355 for ; Thu, 6 Nov 2003 16:57:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7g-0006r7-Li; Thu, 06 Nov 2003 16:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7G-0006pk-Ep for pana@optimus.ietf.org; Thu, 06 Nov 2003 16:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03323 for ; Thu, 6 Nov 2003 16:56:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHs7E-0001KS-00 for pana@ietf.org; Thu, 06 Nov 2003 16:56:32 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AHs7D-0001KO-00 for pana@ietf.org; Thu, 06 Nov 2003 16:56:31 -0500 Date: Thu, 06 Nov 2003 13:57:24 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] Minute takers - volunteers please Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, We'd like to solicit for 2 volunteers for taking minutes during the PANA meeting. Please let the chairs know if you can help with that. Thanks. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 6 16:57:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03369 for ; Thu, 6 Nov 2003 16:57:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7k-0006si-6Q for pana-archive@odin.ietf.org; Thu, 06 Nov 2003 16:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Lv4U5026446 for pana-archive@odin.ietf.org; Thu, 6 Nov 2003 16:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7k-0006sT-2D for pana-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 16:57:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03342 for ; Thu, 6 Nov 2003 16:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHs7h-0001L4-00 for pana-web-archive@ietf.org; Thu, 06 Nov 2003 16:57:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHs7h-0001L1-00 for pana-web-archive@ietf.org; Thu, 06 Nov 2003 16:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7g-0006r7-Li; Thu, 06 Nov 2003 16:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7G-0006pk-Ep for pana@optimus.ietf.org; Thu, 06 Nov 2003 16:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03323 for ; Thu, 6 Nov 2003 16:56:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHs7E-0001KS-00 for pana@ietf.org; Thu, 06 Nov 2003 16:56:32 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AHs7D-0001KO-00 for pana@ietf.org; Thu, 06 Nov 2003 16:56:31 -0500 Date: Thu, 06 Nov 2003 13:57:24 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] Minute takers - volunteers please Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, We'd like to solicit for 2 volunteers for taking minutes during the PANA meeting. Please let the chairs know if you can help with that. Thanks. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 6 20:48:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12168 for ; Thu, 6 Nov 2003 20:48:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvjF-0004GN-3w; Thu, 06 Nov 2003 20:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvjC-0004G8-3h for pana@optimus.ietf.org; Thu, 06 Nov 2003 20:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12136 for ; Thu, 6 Nov 2003 20:47:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvj9-0004OJ-00 for pana@ietf.org; Thu, 06 Nov 2003 20:47:55 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AHvj9-0004OG-00 for pana@ietf.org; Thu, 06 Nov 2003 20:47:55 -0500 Date: Thu, 06 Nov 2003 17:48:48 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] Issue 2 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit http://danforsberg.info:8080/pana-issues/issue2 PANA does not deal with EAP mehtods or method negotiation between the EAP peers. Therefore IMO solving downgrading attacks should be outside the scope of PANA. If some design aspect of PANA can help solving this problem, this is worth exploring. But I would not impose this as a "requirement" on the PANA design... Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 6 20:48:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12184 for ; Thu, 6 Nov 2003 20:48:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvjH-0004HA-RC for pana-archive@odin.ietf.org; Thu, 06 Nov 2003 20:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA71m3xs016430 for pana-archive@odin.ietf.org; Thu, 6 Nov 2003 20:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvjH-0004Gv-Mt for pana-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 20:48:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12143 for ; Thu, 6 Nov 2003 20:47:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvjF-0004OW-00 for pana-web-archive@ietf.org; Thu, 06 Nov 2003 20:48:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHvjF-0004OT-00 for pana-web-archive@ietf.org; Thu, 06 Nov 2003 20:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvjF-0004GN-3w; Thu, 06 Nov 2003 20:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvjC-0004G8-3h for pana@optimus.ietf.org; Thu, 06 Nov 2003 20:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12136 for ; Thu, 6 Nov 2003 20:47:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvj9-0004OJ-00 for pana@ietf.org; Thu, 06 Nov 2003 20:47:55 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AHvj9-0004OG-00 for pana@ietf.org; Thu, 06 Nov 2003 20:47:55 -0500 Date: Thu, 06 Nov 2003 17:48:48 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] Issue 2 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit http://danforsberg.info:8080/pana-issues/issue2 PANA does not deal with EAP mehtods or method negotiation between the EAP peers. Therefore IMO solving downgrading attacks should be outside the scope of PANA. If some design aspect of PANA can help solving this problem, this is worth exploring. But I would not impose this as a "requirement" on the PANA design... Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 7 07:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11658 for ; Fri, 7 Nov 2003 07:04:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5LM-0002EV-Tk; Fri, 07 Nov 2003 07:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5Kz-0002Du-S1 for pana@optimus.ietf.org; Fri, 07 Nov 2003 07:03:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11623 for ; Fri, 7 Nov 2003 07:03:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI5Kv-0003pO-00 for pana@ietf.org; Fri, 07 Nov 2003 07:03:33 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AI5Ku-0003p4-00 for pana@ietf.org; Fri, 07 Nov 2003 07:03:32 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA7C31lQ343854 for ; Fri, 7 Nov 2003 07:03:01 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-205-39.mts.ibm.com [9.65.205.39]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA7C30A3163730 for ; Fri, 7 Nov 2003 05:03:01 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id hA7C08a05733 for ; Fri, 7 Nov 2003 07:00:16 -0500 Message-Id: <200311071200.hA7C08a05733@cichlid.adsl.duke.edu> To: pana@ietf.org Date: Fri, 07 Nov 2003 07:00:08 -0500 From: Thomas Narten Subject: [Pana] on PANA's requirement to use the unspecified address Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , in looking at draft-ietf-pana-requirements-07.txt, it says: > 4.2. IP Address Assignment > > Assigning an IP address to the client is outside the scope of PANA. > PANA protocol design MAY require the PaC to configure an IP address > before using this protocol. Allocating IP addresses to > unauthenticated PaCs may create security vulnerabilities, such as IP > address depletion attacks on the access network [SECTHREAT]. IPv4 > networks with limited address space are the main targets of such > attacks. Launching a successful attack that can deplete the > addresses in an IPv6 network is relatively harder. > > This threat can be mitigated by allowing the protocol to run without > an IP address configured on the PaC (i.e., using unspecified source > address). Such a design choice might limit the re-use of existing > security mechanisms, and impose additional implementation > complexity. This trade off should be taken into consideration in > designing PANA. I'd like to better understand the above analysis and apparent conclusion. draft-ietf-pana-threats-eval-04.txt says: > 6.5.1: There are various forms of DoS attacks that can be launched > on the PAA or AS. A few are mentioned below. As it is hard to defend > against some of the DoS attacks, the protocol should be designed > carefully to mitigate or prevent such attacks. > > . Attacker can bombard the PAA with lots of authentication > requests. If PAA and AS are not collocated, PAA may have to > allocate resources to store some state about PaC locally before > it receives the response from the backend AS. This can deplete > memory resources on PAA. > . The attacker can force the PAA or AS to make computationally > intensive operations with minimal effort, that can deplete the > CPU resources of the PAA or AS. > > T6.5.2: PaC acquires IP address before PANA authentication begins > using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6 > [PANAREQ]. If IP addresses are assigned before authentication, it > opens up the possibility of DoS attack where malicious nodes can > deplete the IP addresses by assigning multiple IP addresses. If > stateless auto-configuration [ADDRCONF] is used, the attacker can > respond to duplicate address detection probes sent by any node on the > network effectively not allowing the node to configure a link local > address. If stateful mechanism is used in IPv6 e.g., DHCPv6, then > this attack is still possible. Address depletion attack is not > specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If PANA > assumes that the client has an IP address already, it opens up the > network to the DoS attack. > > Requirement 9 > > PANA SHOULD not assume that the PaC has acquired an IP address before > PANA begins. A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL addressing are all vulnerable to DOS attacks that can prevent and address from being assigned. But any PANA protocol will also be subject to DOS attacks. E.g., it will almost certainly be possible to interfere with ongoing PANA exchanges and cause DOS attacks that prevent devices from obtaining service. So the conclusion that PANA must also support a mode of operation in which addresses have not been assigned does not (in mind) immediately follow. I.e, the case needs to be made that: a) the address depletion one is significant in the overall scheme of things. b) using the unspecified address would not leave the network vulnerable to other DOS attacks that make solving the previous one a waste of time. Note: folk might want to look at draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security mechanisms after concluding they were useless due to bigger DOS issues related to IP's reliance on ARP. Second, there are significant stack complications to allowing generic communication with an unspecified address. Things to consider: - IP fragmentation doesn't work reliably anymore (a recieving machine might think two fragments that are actually from two different machines are from the same machine, and reassemble them improperly). - when sending to an unspecified address, the IP stack doens't know where to send the packet. Thus, special hacks (and API changes) are needed to specify the link-layer address (and interface) of where to send the packet. - when receiving packets from the unspecified address (e.g. on the PAA), one needs a way of identifying which machine the packet came from. Normally, this would be the source IP address. But if that address is the unspecified address, we need something else. The two obvious choices are - use the sender's link-layer address. But note that now we aren't really using pure IP anymore (and we need stack/API support for this)... - add a field to the protocol itself that is used for this purpose. While that can be done with new protocols, it can't be done with existing protocols, so this approach is obviously not generally applicable where a goal is protocol reuse. Given that there are costs (and significant ones IMO) associated with using an unspecified address, I'm not convinced that the cost benefit tradeoff has been evaluated correctly. Thus, what I'd really like to understand is why the following isn't the standard pana model: - device gets an address using standard mechanisms (either DHC, IPv4 LL, or IPv6 LL). Since the PAA is required to be on the same IP link as the PAC, LL addressing works just fine. - Use the address obtained in the previous step to run PANA. Because its a proper address, IP-based protocols just work. - Once PANA has completed, obtain a proper/better address, if that is what is needed. (And there are lots of ways of doing this, but that comes later). Thomas _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 7 07:04:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11673 for ; Fri, 7 Nov 2003 07:04:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5LR-0002FD-Rt for pana-archive@odin.ietf.org; Fri, 07 Nov 2003 07:04:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7C45fZ008621 for pana-archive@odin.ietf.org; Fri, 7 Nov 2003 07:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5LR-0002Ey-NM for pana-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 07:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11629 for ; Fri, 7 Nov 2003 07:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI5LN-0003pk-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 07:04:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI5LM-0003ph-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 07:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5LM-0002EV-Tk; Fri, 07 Nov 2003 07:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5Kz-0002Du-S1 for pana@optimus.ietf.org; Fri, 07 Nov 2003 07:03:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11623 for ; Fri, 7 Nov 2003 07:03:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI5Kv-0003pO-00 for pana@ietf.org; Fri, 07 Nov 2003 07:03:33 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AI5Ku-0003p4-00 for pana@ietf.org; Fri, 07 Nov 2003 07:03:32 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA7C31lQ343854 for ; Fri, 7 Nov 2003 07:03:01 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-205-39.mts.ibm.com [9.65.205.39]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA7C30A3163730 for ; Fri, 7 Nov 2003 05:03:01 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id hA7C08a05733 for ; Fri, 7 Nov 2003 07:00:16 -0500 Message-Id: <200311071200.hA7C08a05733@cichlid.adsl.duke.edu> To: pana@ietf.org Date: Fri, 07 Nov 2003 07:00:08 -0500 From: Thomas Narten Subject: [Pana] on PANA's requirement to use the unspecified address Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , in looking at draft-ietf-pana-requirements-07.txt, it says: > 4.2. IP Address Assignment > > Assigning an IP address to the client is outside the scope of PANA. > PANA protocol design MAY require the PaC to configure an IP address > before using this protocol. Allocating IP addresses to > unauthenticated PaCs may create security vulnerabilities, such as IP > address depletion attacks on the access network [SECTHREAT]. IPv4 > networks with limited address space are the main targets of such > attacks. Launching a successful attack that can deplete the > addresses in an IPv6 network is relatively harder. > > This threat can be mitigated by allowing the protocol to run without > an IP address configured on the PaC (i.e., using unspecified source > address). Such a design choice might limit the re-use of existing > security mechanisms, and impose additional implementation > complexity. This trade off should be taken into consideration in > designing PANA. I'd like to better understand the above analysis and apparent conclusion. draft-ietf-pana-threats-eval-04.txt says: > 6.5.1: There are various forms of DoS attacks that can be launched > on the PAA or AS. A few are mentioned below. As it is hard to defend > against some of the DoS attacks, the protocol should be designed > carefully to mitigate or prevent such attacks. > > . Attacker can bombard the PAA with lots of authentication > requests. If PAA and AS are not collocated, PAA may have to > allocate resources to store some state about PaC locally before > it receives the response from the backend AS. This can deplete > memory resources on PAA. > . The attacker can force the PAA or AS to make computationally > intensive operations with minimal effort, that can deplete the > CPU resources of the PAA or AS. > > T6.5.2: PaC acquires IP address before PANA authentication begins > using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6 > [PANAREQ]. If IP addresses are assigned before authentication, it > opens up the possibility of DoS attack where malicious nodes can > deplete the IP addresses by assigning multiple IP addresses. If > stateless auto-configuration [ADDRCONF] is used, the attacker can > respond to duplicate address detection probes sent by any node on the > network effectively not allowing the node to configure a link local > address. If stateful mechanism is used in IPv6 e.g., DHCPv6, then > this attack is still possible. Address depletion attack is not > specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If PANA > assumes that the client has an IP address already, it opens up the > network to the DoS attack. > > Requirement 9 > > PANA SHOULD not assume that the PaC has acquired an IP address before > PANA begins. A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL addressing are all vulnerable to DOS attacks that can prevent and address from being assigned. But any PANA protocol will also be subject to DOS attacks. E.g., it will almost certainly be possible to interfere with ongoing PANA exchanges and cause DOS attacks that prevent devices from obtaining service. So the conclusion that PANA must also support a mode of operation in which addresses have not been assigned does not (in mind) immediately follow. I.e, the case needs to be made that: a) the address depletion one is significant in the overall scheme of things. b) using the unspecified address would not leave the network vulnerable to other DOS attacks that make solving the previous one a waste of time. Note: folk might want to look at draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security mechanisms after concluding they were useless due to bigger DOS issues related to IP's reliance on ARP. Second, there are significant stack complications to allowing generic communication with an unspecified address. Things to consider: - IP fragmentation doesn't work reliably anymore (a recieving machine might think two fragments that are actually from two different machines are from the same machine, and reassemble them improperly). - when sending to an unspecified address, the IP stack doens't know where to send the packet. Thus, special hacks (and API changes) are needed to specify the link-layer address (and interface) of where to send the packet. - when receiving packets from the unspecified address (e.g. on the PAA), one needs a way of identifying which machine the packet came from. Normally, this would be the source IP address. But if that address is the unspecified address, we need something else. The two obvious choices are - use the sender's link-layer address. But note that now we aren't really using pure IP anymore (and we need stack/API support for this)... - add a field to the protocol itself that is used for this purpose. While that can be done with new protocols, it can't be done with existing protocols, so this approach is obviously not generally applicable where a goal is protocol reuse. Given that there are costs (and significant ones IMO) associated with using an unspecified address, I'm not convinced that the cost benefit tradeoff has been evaluated correctly. Thus, what I'd really like to understand is why the following isn't the standard pana model: - device gets an address using standard mechanisms (either DHC, IPv4 LL, or IPv6 LL). Since the PAA is required to be on the same IP link as the PAC, LL addressing works just fine. - Use the address obtained in the previous step to run PANA. Because its a proper address, IP-based protocols just work. - Once PANA has completed, obtain a proper/better address, if that is what is needed. (And there are lots of ways of doing this, but that comes later). Thomas _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 7 09:35:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15897 for ; Fri, 7 Nov 2003 09:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7hW-0000I1-73; Fri, 07 Nov 2003 09:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7ge-0000H0-JL for pana@optimus.ietf.org; Fri, 07 Nov 2003 09:34:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15868 for ; Fri, 7 Nov 2003 09:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7gc-0005pK-00 for pana@ietf.org; Fri, 07 Nov 2003 09:34:06 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AI7gb-0005ov-00 for pana@ietf.org; Fri, 07 Nov 2003 09:34:06 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 72F17347D7; Fri, 7 Nov 2003 15:27:52 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id A6E723F40C; Fri, 7 Nov 2003 15:27:51 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003110715275131408 ; Fri, 07 Nov 2003 15:27:51 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 67A813F429; Fri, 7 Nov 2003 15:27:50 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AI7ZX-000BRS-Af; Fri, 07 Nov 2003 15:26:47 +0100 Date: Fri, 7 Nov 2003 15:26:47 +0100 From: Julien Bournelle To: Alper Yegin Cc: pana@ietf.org Subject: [Pana] Issue 35 Message-ID: <20031107142647.GT72999@ipv6-5.int-evry.fr> References: <003101c38c2c$4460f380$5a100a0a@adithya> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi all, On Mon, Oct 06, 2003 at 09:30:04PM -0700, Alper Yegin wrote: > > >From PANA-IPsec draft: > > > 3.0 Pre-requisites for IPsec SA establisment > > This document assumes that the following have already happened before > the IPSEC SA is established. > > 1) PANA client (PaC) learns the IP address of the Enforcement point > (EP) during the PANA exchange. > > Currently we don't have this feature in PANA. I think we can handle this by: > > - Having an AVP for carrying the DI of EP(s). We can add a new field (or > flag?) to current device-ID AVP to indicate whether it belongs to PAA or one > of the EPs. I think we can't add a Flag in AVP header, because these flags are for general purpose. (cf. Mandatory, Vendor etc...). I prefer the idea of adding a field. > - This AVP MUST be included in PANA-Bind-Request when L2 or L3 ciphering > will be enabled after PANA. There may be more than one such AVP at a time > (for multiple access routers, for example). If we do L2 ciphering, do you think that the ciphering will occur between pac and ep ? > - The address type in this AVP MUST match the ciphering type. agree -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 7 09:35:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15912 for ; Fri, 7 Nov 2003 09:35:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7hZ-0000Ie-8W for pana-archive@odin.ietf.org; Fri, 07 Nov 2003 09:35:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7EZ5n1001151 for pana-archive@odin.ietf.org; Fri, 7 Nov 2003 09:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7hZ-0000IU-3V for pana-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 09:35:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15886 for ; Fri, 7 Nov 2003 09:34:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7hX-0005pl-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 09:35:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI7hX-0005pi-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 09:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7hW-0000I1-73; Fri, 07 Nov 2003 09:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7ge-0000H0-JL for pana@optimus.ietf.org; Fri, 07 Nov 2003 09:34:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15868 for ; Fri, 7 Nov 2003 09:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7gc-0005pK-00 for pana@ietf.org; Fri, 07 Nov 2003 09:34:06 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AI7gb-0005ov-00 for pana@ietf.org; Fri, 07 Nov 2003 09:34:06 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 72F17347D7; Fri, 7 Nov 2003 15:27:52 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id A6E723F40C; Fri, 7 Nov 2003 15:27:51 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003110715275131408 ; Fri, 07 Nov 2003 15:27:51 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 67A813F429; Fri, 7 Nov 2003 15:27:50 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AI7ZX-000BRS-Af; Fri, 07 Nov 2003 15:26:47 +0100 Date: Fri, 7 Nov 2003 15:26:47 +0100 From: Julien Bournelle To: Alper Yegin Cc: pana@ietf.org Subject: [Pana] Issue 35 Message-ID: <20031107142647.GT72999@ipv6-5.int-evry.fr> References: <003101c38c2c$4460f380$5a100a0a@adithya> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi all, On Mon, Oct 06, 2003 at 09:30:04PM -0700, Alper Yegin wrote: > > >From PANA-IPsec draft: > > > 3.0 Pre-requisites for IPsec SA establisment > > This document assumes that the following have already happened before > the IPSEC SA is established. > > 1) PANA client (PaC) learns the IP address of the Enforcement point > (EP) during the PANA exchange. > > Currently we don't have this feature in PANA. I think we can handle this by: > > - Having an AVP for carrying the DI of EP(s). We can add a new field (or > flag?) to current device-ID AVP to indicate whether it belongs to PAA or one > of the EPs. I think we can't add a Flag in AVP header, because these flags are for general purpose. (cf. Mandatory, Vendor etc...). I prefer the idea of adding a field. > - This AVP MUST be included in PANA-Bind-Request when L2 or L3 ciphering > will be enabled after PANA. There may be more than one such AVP at a time > (for multiple access routers, for example). If we do L2 ciphering, do you think that the ciphering will occur between pac and ep ? > - The address type in this AVP MUST match the ciphering type. agree -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 7 17:12:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10563 for ; Fri, 7 Nov 2003 17:12:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEpk-00063J-6Q; Fri, 07 Nov 2003 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEos-00061h-Om for pana@optimus.ietf.org; Fri, 07 Nov 2003 17:11:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10476 for ; Fri, 7 Nov 2003 17:10:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEoq-0003vq-00 for pana@ietf.org; Fri, 07 Nov 2003 17:11:04 -0500 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1AIEop-0003vd-00 for pana@ietf.org; Fri, 07 Nov 2003 17:11:03 -0500 Received: from mail.atheros.com (HELO adithya) (mohanp@sbcglobal.net@65.212.155.130 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 7 Nov 2003 22:10:54 -0000 Message-ID: <001d01c3a57c$03f59620$34100a0a@adithya> From: "Mohan Parthasarathy" To: , "Thomas Narten" References: <200311071200.hA7C08a05733@cichlid.adsl.duke.edu> Subject: Re: [Pana] on PANA's requirement to use the unspecified address Date: Fri, 7 Nov 2003 14:10:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thomas, > in looking at draft-ietf-pana-requirements-07.txt, it says: > > > 4.2. IP Address Assignment > > > > Assigning an IP address to the client is outside the scope of PANA. > > PANA protocol design MAY require the PaC to configure an IP address > > before using this protocol. Allocating IP addresses to > > unauthenticated PaCs may create security vulnerabilities, such as IP > > address depletion attacks on the access network [SECTHREAT]. IPv4 > > networks with limited address space are the main targets of such > > attacks. Launching a successful attack that can deplete the > > addresses in an IPv6 network is relatively harder. > > > > This threat can be mitigated by allowing the protocol to run without > > an IP address configured on the PaC (i.e., using unspecified source > > address). Such a design choice might limit the re-use of existing > > security mechanisms, and impose additional implementation > > complexity. This trade off should be taken into consideration in > > designing PANA. > > I'd like to better understand the above analysis and apparent > conclusion. > At one of the IETF meeting, we discussed about this particular case. The conclusion is to look at the trade-offs of using an unspecified address. As you note below there are some additional complexities. At least the issue of fragmentation did surface in some private discussions. More below. > draft-ietf-pana-threats-eval-04.txt says: > > > 6.5.1: There are various forms of DoS attacks that can be launched > > on the PAA or AS. A few are mentioned below. As it is hard to defend > > against some of the DoS attacks, the protocol should be designed > > carefully to mitigate or prevent such attacks. > > > > . Attacker can bombard the PAA with lots of authentication > > requests. If PAA and AS are not collocated, PAA may have to > > allocate resources to store some state about PaC locally before > > it receives the response from the backend AS. This can deplete > > memory resources on PAA. > > . The attacker can force the PAA or AS to make computationally > > intensive operations with minimal effort, that can deplete the > > CPU resources of the PAA or AS. > > > > T6.5.2: PaC acquires IP address before PANA authentication begins > > using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6 > > [PANAREQ]. If IP addresses are assigned before authentication, it > > opens up the possibility of DoS attack where malicious nodes can > > deplete the IP addresses by assigning multiple IP addresses. If > > stateless auto-configuration [ADDRCONF] is used, the attacker can > > respond to duplicate address detection probes sent by any node on the > > network effectively not allowing the node to configure a link local > > address. If stateful mechanism is used in IPv6 e.g., DHCPv6, then > > this attack is still possible. Address depletion attack is not > > specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If PANA > > assumes that the client has an IP address already, it opens up the > > network to the DoS attack. > > > > Requirement 9 > > > > PANA SHOULD not assume that the PaC has acquired an IP address before > > PANA begins. > > A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL > addressing are all vulnerable to DOS attacks that can prevent and > address from being assigned. But any PANA protocol will also be > subject to DOS attacks. E.g., it will almost certainly be possible to > interfere with ongoing PANA exchanges and cause DOS attacks that > prevent devices from obtaining service. So the conclusion that PANA > must also support a mode of operation in which addresses have not been > assigned does not (in mind) immediately follow. I.e, the case needs to > be made that: > It is a "SHOULD" above. Perhaps you are saying that it should be a "MAY" ? > a) the address depletion one is significant in the overall scheme of > things. > > b) using the unspecified address would not leave the network > vulnerable to other DOS attacks that make solving the previous one > a waste of time. Note: folk might want to look at > draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security > mechanisms after concluding they were useless due to bigger DOS > issues related to IP's reliance on ARP. > The basic idea is to see whether it is possible to mitigate against address depletion attack assuming there are good tradeoffs. I am not sure why this DoS attack needs special treatment compared to other DoS attacks. > Second, there are significant stack complications to allowing generic > communication with an unspecified address. Things to consider: > > - IP fragmentation doesn't work reliably anymore (a recieving machine > might think two fragments that are actually from two different > machines are from the same machine, and reassemble them improperly). > Agreed. Some stacks maintain the reassembly queue per interface which solves problem with link-local addresses in general. But for unspecified address, unless mac addresses are used (which may not be reasonable), the problem will exist. > - when sending to an unspecified address, the IP stack doens't know > where to send the packet. Thus, special hacks (and API changes) are > needed to specify the link-layer address (and interface) of where to > send the packet. > As DAD has been there for sometime, i thought most of the stacks should be supporting this API. > - when receiving packets from the unspecified address (e.g. on the > PAA), one needs a way of identifying which machine the packet came > from. Normally, this would be the source IP address. But if that > address is the unspecified address, we need something else. The two > obvious choices are > Agreed. But with mobile IPv4 similar problem existed where FA cannot ARP for MN where you needed to know the source MAC address of the MN. Agreed that this may not be a standard API. > - use the sender's link-layer address. But note that now we aren't > really using pure IP anymore (and we need stack/API support for > this)... > > - add a field to the protocol itself that is used for this > purpose. While that can be done with new protocols, it can't be > done with existing protocols, so this approach is obviously not > generally applicable where a goal is protocol reuse. > > Given that there are costs (and significant ones IMO) associated with > using an unspecified address, I'm not convinced that the cost benefit > tradeoff has been evaluated correctly. > I agree to some extent. Are you concerned about the wording in the draft ? The PANA requirements draft itself does not say anything strong about this. I agreed that the threats draft can include a better analysis on this part to point out the tradeoffs. > Thus, what I'd really like to understand is why the following isn't > the standard pana model: > > - device gets an address using standard mechanisms (either DHC, IPv4 > LL, or IPv6 LL). Since the PAA is required to be on the same IP link > as the PAC, LL addressing works just fine. > Some stacks typically use a single global queue for reassembly. If the same mac addresses are used for src and dst on two different links, such problem would still exist. Not sure whether this is a common problem or not. > - Use the address obtained in the previous step to run PANA. Because > its a proper address, IP-based protocols just work. > Sure. I have not read the latest version of the PANA protocol document. I don't know how much of this directly affects the functioning of the protocol itself. Sure some of the implementation complexities might still be there. As i mentioned earlier, the requirements document itself does not prohibit from using link local addresses. Perhaps the threats document should be fixed. -mohan > - Once PANA has completed, obtain a proper/better address, if that is > what is needed. (And there are lots of ways of doing this, but that > comes later). > > Thomas > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 7 17:12:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10585 for ; Fri, 7 Nov 2003 17:12:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEpp-00064M-L4 for pana-archive@odin.ietf.org; Fri, 07 Nov 2003 17:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7MC5CO023324 for pana-archive@odin.ietf.org; Fri, 7 Nov 2003 17:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEpo-000645-1J for pana-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 17:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10543 for ; Fri, 7 Nov 2003 17:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEpl-0003x2-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 17:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIEpl-0003wy-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 17:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEpk-00063J-6Q; Fri, 07 Nov 2003 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEos-00061h-Om for pana@optimus.ietf.org; Fri, 07 Nov 2003 17:11:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10476 for ; Fri, 7 Nov 2003 17:10:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEoq-0003vq-00 for pana@ietf.org; Fri, 07 Nov 2003 17:11:04 -0500 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1AIEop-0003vd-00 for pana@ietf.org; Fri, 07 Nov 2003 17:11:03 -0500 Received: from mail.atheros.com (HELO adithya) (mohanp@sbcglobal.net@65.212.155.130 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 7 Nov 2003 22:10:54 -0000 Message-ID: <001d01c3a57c$03f59620$34100a0a@adithya> From: "Mohan Parthasarathy" To: , "Thomas Narten" References: <200311071200.hA7C08a05733@cichlid.adsl.duke.edu> Subject: Re: [Pana] on PANA's requirement to use the unspecified address Date: Fri, 7 Nov 2003 14:10:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas, > in looking at draft-ietf-pana-requirements-07.txt, it says: > > > 4.2. IP Address Assignment > > > > Assigning an IP address to the client is outside the scope of PANA. > > PANA protocol design MAY require the PaC to configure an IP address > > before using this protocol. Allocating IP addresses to > > unauthenticated PaCs may create security vulnerabilities, such as IP > > address depletion attacks on the access network [SECTHREAT]. IPv4 > > networks with limited address space are the main targets of such > > attacks. Launching a successful attack that can deplete the > > addresses in an IPv6 network is relatively harder. > > > > This threat can be mitigated by allowing the protocol to run without > > an IP address configured on the PaC (i.e., using unspecified source > > address). Such a design choice might limit the re-use of existing > > security mechanisms, and impose additional implementation > > complexity. This trade off should be taken into consideration in > > designing PANA. > > I'd like to better understand the above analysis and apparent > conclusion. > At one of the IETF meeting, we discussed about this particular case. The conclusion is to look at the trade-offs of using an unspecified address. As you note below there are some additional complexities. At least the issue of fragmentation did surface in some private discussions. More below. > draft-ietf-pana-threats-eval-04.txt says: > > > 6.5.1: There are various forms of DoS attacks that can be launched > > on the PAA or AS. A few are mentioned below. As it is hard to defend > > against some of the DoS attacks, the protocol should be designed > > carefully to mitigate or prevent such attacks. > > > > . Attacker can bombard the PAA with lots of authentication > > requests. If PAA and AS are not collocated, PAA may have to > > allocate resources to store some state about PaC locally before > > it receives the response from the backend AS. This can deplete > > memory resources on PAA. > > . The attacker can force the PAA or AS to make computationally > > intensive operations with minimal effort, that can deplete the > > CPU resources of the PAA or AS. > > > > T6.5.2: PaC acquires IP address before PANA authentication begins > > using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6 > > [PANAREQ]. If IP addresses are assigned before authentication, it > > opens up the possibility of DoS attack where malicious nodes can > > deplete the IP addresses by assigning multiple IP addresses. If > > stateless auto-configuration [ADDRCONF] is used, the attacker can > > respond to duplicate address detection probes sent by any node on the > > network effectively not allowing the node to configure a link local > > address. If stateful mechanism is used in IPv6 e.g., DHCPv6, then > > this attack is still possible. Address depletion attack is not > > specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If PANA > > assumes that the client has an IP address already, it opens up the > > network to the DoS attack. > > > > Requirement 9 > > > > PANA SHOULD not assume that the PaC has acquired an IP address before > > PANA begins. > > A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL > addressing are all vulnerable to DOS attacks that can prevent and > address from being assigned. But any PANA protocol will also be > subject to DOS attacks. E.g., it will almost certainly be possible to > interfere with ongoing PANA exchanges and cause DOS attacks that > prevent devices from obtaining service. So the conclusion that PANA > must also support a mode of operation in which addresses have not been > assigned does not (in mind) immediately follow. I.e, the case needs to > be made that: > It is a "SHOULD" above. Perhaps you are saying that it should be a "MAY" ? > a) the address depletion one is significant in the overall scheme of > things. > > b) using the unspecified address would not leave the network > vulnerable to other DOS attacks that make solving the previous one > a waste of time. Note: folk might want to look at > draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security > mechanisms after concluding they were useless due to bigger DOS > issues related to IP's reliance on ARP. > The basic idea is to see whether it is possible to mitigate against address depletion attack assuming there are good tradeoffs. I am not sure why this DoS attack needs special treatment compared to other DoS attacks. > Second, there are significant stack complications to allowing generic > communication with an unspecified address. Things to consider: > > - IP fragmentation doesn't work reliably anymore (a recieving machine > might think two fragments that are actually from two different > machines are from the same machine, and reassemble them improperly). > Agreed. Some stacks maintain the reassembly queue per interface which solves problem with link-local addresses in general. But for unspecified address, unless mac addresses are used (which may not be reasonable), the problem will exist. > - when sending to an unspecified address, the IP stack doens't know > where to send the packet. Thus, special hacks (and API changes) are > needed to specify the link-layer address (and interface) of where to > send the packet. > As DAD has been there for sometime, i thought most of the stacks should be supporting this API. > - when receiving packets from the unspecified address (e.g. on the > PAA), one needs a way of identifying which machine the packet came > from. Normally, this would be the source IP address. But if that > address is the unspecified address, we need something else. The two > obvious choices are > Agreed. But with mobile IPv4 similar problem existed where FA cannot ARP for MN where you needed to know the source MAC address of the MN. Agreed that this may not be a standard API. > - use the sender's link-layer address. But note that now we aren't > really using pure IP anymore (and we need stack/API support for > this)... > > - add a field to the protocol itself that is used for this > purpose. While that can be done with new protocols, it can't be > done with existing protocols, so this approach is obviously not > generally applicable where a goal is protocol reuse. > > Given that there are costs (and significant ones IMO) associated with > using an unspecified address, I'm not convinced that the cost benefit > tradeoff has been evaluated correctly. > I agree to some extent. Are you concerned about the wording in the draft ? The PANA requirements draft itself does not say anything strong about this. I agreed that the threats draft can include a better analysis on this part to point out the tradeoffs. > Thus, what I'd really like to understand is why the following isn't > the standard pana model: > > - device gets an address using standard mechanisms (either DHC, IPv4 > LL, or IPv6 LL). Since the PAA is required to be on the same IP link > as the PAC, LL addressing works just fine. > Some stacks typically use a single global queue for reassembly. If the same mac addresses are used for src and dst on two different links, such problem would still exist. Not sure whether this is a common problem or not. > - Use the address obtained in the previous step to run PANA. Because > its a proper address, IP-based protocols just work. > Sure. I have not read the latest version of the PANA protocol document. I don't know how much of this directly affects the functioning of the protocol itself. Sure some of the implementation complexities might still be there. As i mentioned earlier, the requirements document itself does not prohibit from using link local addresses. Perhaps the threats document should be fixed. -mohan > - Once PANA has completed, obtain a proper/better address, if that is > what is needed. (And there are lots of ways of doing this, but that > comes later). > > Thomas > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 7 17:22:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10965 for ; Fri, 7 Nov 2003 17:22:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEzR-0006cN-1g; Fri, 07 Nov 2003 17:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEz3-0006Yv-Ld for pana@optimus.ietf.org; Fri, 07 Nov 2003 17:21:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10916 for ; Fri, 7 Nov 2003 17:21:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEz1-00045l-00 for pana@ietf.org; Fri, 07 Nov 2003 17:21:35 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AIEz0-00045Z-00 for pana@ietf.org; Fri, 07 Nov 2003 17:21:34 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hA7MLPF1016040; Sat, 8 Nov 2003 07:21:25 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hA7MLPb1001913; Sat, 8 Nov 2003 07:21:25 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA01912 ; Sat, 8 Nov 2003 07:21:24 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA15653; Sat, 8 Nov 2003 07:21:24 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA21209; Sat, 8 Nov 2003 07:21:23 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hA7MLN9X019476; Sat, 8 Nov 2003 07:21:23 +0900 (JST) Received: from cse2188 ([159.119.168.66]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with SMTP id <0HO000L7463IZ3@tsbpo1.po.toshiba.co.jp>; Sat, 8 Nov 2003 07:21:22 +0900 (JST) Date: Fri, 07 Nov 2003 14:21:17 -0800 From: Yoshihiro Ohba To: narten@us.ibm.com Cc: pana@ietf.org Message-id: <00ca01c3a57d$7896ce30$6a696442@cse2188> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Priority: 3 Content-Transfer-Encoding: 7bit Subject: [Pana] Comments on "on PANA's requirement to use the unspecified address" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please find "" for my comments. To: pana@ietf.org Subject: [Pana] on PANA's requirement to use the unspecified address From: Thomas Narten Date: Fri, 07 Nov 2003 07:00:08 -0500 List-help: List-id: Protocol for carrying Authentication for Network Access List-post: List-subscribe: , List-unsubscribe: , Sender: pana-admin@ietf.org in looking at draft-ietf-pana-requirements-07.txt, it says: > 4.2. IP Address Assignment > > Assigning an IP address to the client is outside the scope of PANA. > PANA protocol design MAY require the PaC to configure an IP address > before using this protocol. Allocating IP addresses to > unauthenticated PaCs may create security vulnerabilities, such as IP > address depletion attacks on the access network [SECTHREAT]. IPv4 > networks with limited address space are the main targets of such > attacks. Launching a successful attack that can deplete the > addresses in an IPv6 network is relatively harder. > > This threat can be mitigated by allowing the protocol to run without > an IP address configured on the PaC (i.e., using unspecified source > address). Such a design choice might limit the re-use of existing > security mechanisms, and impose additional implementation > complexity. This trade off should be taken into consideration in > designing PANA. I'd like to better understand the above analysis and apparent conclusion. draft-ietf-pana-threats-eval-04.txt says: > 6.5.1: There are various forms of DoS attacks that can be launched > on the PAA or AS. A few are mentioned below. As it is hard to defend > against some of the DoS attacks, the protocol should be designed > carefully to mitigate or prevent such attacks. > > . Attacker can bombard the PAA with lots of authentication > requests. If PAA and AS are not collocated, PAA may have to > allocate resources to store some state about PaC locally before > it receives the response from the backend AS. This can deplete > memory resources on PAA. > . The attacker can force the PAA or AS to make computationally > intensive operations with minimal effort, that can deplete the > CPU resources of the PAA or AS. > > T6.5.2: PaC acquires IP address before PANA authentication begins > using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6 > [PANAREQ]. If IP addresses are assigned before authentication, it > opens up the possibility of DoS attack where malicious nodes can > deplete the IP addresses by assigning multiple IP addresses. If > stateless auto-configuration [ADDRCONF] is used, the attacker can > respond to duplicate address detection probes sent by any node on the > network effectively not allowing the node to configure a link local > address. If stateful mechanism is used in IPv6 e.g., DHCPv6, then > this attack is still possible. Address depletion attack is not > specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If PANA > assumes that the client has an IP address already, it opens up the > network to the DoS attack. > > Requirement 9 > > PANA SHOULD not assume that the PaC has acquired an IP address before > PANA begins. A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL addressing are all vulnerable to DOS attacks that can prevent and address from being assigned. But any PANA protocol will also be subject to DOS attacks. E.g., it will almost certainly be possible to interfere with ongoing PANA exchanges and cause DOS attacks that prevent devices from obtaining service. So the conclusion that PANA must also support a mode of operation in which addresses have not been assigned does not (in mind) immediately follow. I.e, the case needs to be made that: a) the address depletion one is significant in the overall scheme of things. b) using the unspecified address would not leave the network vulnerable to other DOS attacks that make solving the previous one a waste of time. Note: folk might want to look at draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security mechanisms after concluding they were useless due to bigger DOS issues related to IP's reliance on ARP. Second, there are significant stack complications to allowing generic communication with an unspecified address. Things to consider: - IP fragmentation doesn't work reliably anymore (a recieving machine might think two fragments that are actually from two different machines are from the same machine, and reassemble them improperly). - when sending to an unspecified address, the IP stack doens't know where to send the packet. Thus, special hacks (and API changes) are needed to specify the link-layer address (and interface) of where to send the packet. - when receiving packets from the unspecified address (e.g. on the PAA), one needs a way of identifying which machine the packet came from. Normally, this would be the source IP address. But if that address is the unspecified address, we need something else. The two obvious choices are - use the sender's link-layer address. But note that now we aren't really using pure IP anymore (and we need stack/API support for this)... - add a field to the protocol itself that is used for this purpose. While that can be done with new protocols, it can't be done with existing protocols, so this approach is obviously not generally applicable where a goal is protocol reuse. Given that there are costs (and significant ones IMO) associated with using an unspecified address, I'm not convinced that the cost benefit tradeoff has been evaluated correctly. Thus, what I'd really like to understand is why the following isn't the standard pana model: - device gets an address using standard mechanisms (either DHC, IPv4 LL, or IPv6 LL). Since the PAA is required to be on the same IP link as the PAC, LL addressing works just fine. - Use the address obtained in the previous step to run PANA. Because its a proper address, IP-based protocols just work. - Once PANA has completed, obtain a proper/better address, if that is what is needed. (And there are lots of ways of doing this, but that comes later). Thomas Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 7 17:22:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10984 for ; Fri, 7 Nov 2003 17:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEzV-0006d5-85 for pana-archive@odin.ietf.org; Fri, 07 Nov 2003 17:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7MM5Yo025477 for pana-archive@odin.ietf.org; Fri, 7 Nov 2003 17:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEzV-0006cq-3n for pana-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 17:22:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10923 for ; Fri, 7 Nov 2003 17:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEzS-00046A-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 17:22:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIEzS-000467-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 17:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEzR-0006cN-1g; Fri, 07 Nov 2003 17:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEz3-0006Yv-Ld for pana@optimus.ietf.org; Fri, 07 Nov 2003 17:21:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10916 for ; Fri, 7 Nov 2003 17:21:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEz1-00045l-00 for pana@ietf.org; Fri, 07 Nov 2003 17:21:35 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AIEz0-00045Z-00 for pana@ietf.org; Fri, 07 Nov 2003 17:21:34 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hA7MLPF1016040; Sat, 8 Nov 2003 07:21:25 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hA7MLPb1001913; Sat, 8 Nov 2003 07:21:25 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA01912 ; Sat, 8 Nov 2003 07:21:24 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA15653; Sat, 8 Nov 2003 07:21:24 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA21209; Sat, 8 Nov 2003 07:21:23 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hA7MLN9X019476; Sat, 8 Nov 2003 07:21:23 +0900 (JST) Received: from cse2188 ([159.119.168.66]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with SMTP id <0HO000L7463IZ3@tsbpo1.po.toshiba.co.jp>; Sat, 8 Nov 2003 07:21:22 +0900 (JST) Date: Fri, 07 Nov 2003 14:21:17 -0800 From: Yoshihiro Ohba To: narten@us.ibm.com Cc: pana@ietf.org Message-id: <00ca01c3a57d$7896ce30$6a696442@cse2188> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Priority: 3 Content-Transfer-Encoding: 7bit Subject: [Pana] Comments on "on PANA's requirement to use the unspecified address" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please find "" for my comments. To: pana@ietf.org Subject: [Pana] on PANA's requirement to use the unspecified address From: Thomas Narten Date: Fri, 07 Nov 2003 07:00:08 -0500 List-help: List-id: Protocol for carrying Authentication for Network Access List-post: List-subscribe: , List-unsubscribe: , Sender: pana-admin@ietf.org in looking at draft-ietf-pana-requirements-07.txt, it says: > 4.2. IP Address Assignment > > Assigning an IP address to the client is outside the scope of PANA. > PANA protocol design MAY require the PaC to configure an IP address > before using this protocol. Allocating IP addresses to > unauthenticated PaCs may create security vulnerabilities, such as IP > address depletion attacks on the access network [SECTHREAT]. IPv4 > networks with limited address space are the main targets of such > attacks. Launching a successful attack that can deplete the > addresses in an IPv6 network is relatively harder. > > This threat can be mitigated by allowing the protocol to run without > an IP address configured on the PaC (i.e., using unspecified source > address). Such a design choice might limit the re-use of existing > security mechanisms, and impose additional implementation > complexity. This trade off should be taken into consideration in > designing PANA. I'd like to better understand the above analysis and apparent conclusion. draft-ietf-pana-threats-eval-04.txt says: > 6.5.1: There are various forms of DoS attacks that can be launched > on the PAA or AS. A few are mentioned below. As it is hard to defend > against some of the DoS attacks, the protocol should be designed > carefully to mitigate or prevent such attacks. > > . Attacker can bombard the PAA with lots of authentication > requests. If PAA and AS are not collocated, PAA may have to > allocate resources to store some state about PaC locally before > it receives the response from the backend AS. This can deplete > memory resources on PAA. > . The attacker can force the PAA or AS to make computationally > intensive operations with minimal effort, that can deplete the > CPU resources of the PAA or AS. > > T6.5.2: PaC acquires IP address before PANA authentication begins > using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6 > [PANAREQ]. If IP addresses are assigned before authentication, it > opens up the possibility of DoS attack where malicious nodes can > deplete the IP addresses by assigning multiple IP addresses. If > stateless auto-configuration [ADDRCONF] is used, the attacker can > respond to duplicate address detection probes sent by any node on the > network effectively not allowing the node to configure a link local > address. If stateful mechanism is used in IPv6 e.g., DHCPv6, then > this attack is still possible. Address depletion attack is not > specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If PANA > assumes that the client has an IP address already, it opens up the > network to the DoS attack. > > Requirement 9 > > PANA SHOULD not assume that the PaC has acquired an IP address before > PANA begins. A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL addressing are all vulnerable to DOS attacks that can prevent and address from being assigned. But any PANA protocol will also be subject to DOS attacks. E.g., it will almost certainly be possible to interfere with ongoing PANA exchanges and cause DOS attacks that prevent devices from obtaining service. So the conclusion that PANA must also support a mode of operation in which addresses have not been assigned does not (in mind) immediately follow. I.e, the case needs to be made that: a) the address depletion one is significant in the overall scheme of things. b) using the unspecified address would not leave the network vulnerable to other DOS attacks that make solving the previous one a waste of time. Note: folk might want to look at draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security mechanisms after concluding they were useless due to bigger DOS issues related to IP's reliance on ARP. Second, there are significant stack complications to allowing generic communication with an unspecified address. Things to consider: - IP fragmentation doesn't work reliably anymore (a recieving machine might think two fragments that are actually from two different machines are from the same machine, and reassemble them improperly). - when sending to an unspecified address, the IP stack doens't know where to send the packet. Thus, special hacks (and API changes) are needed to specify the link-layer address (and interface) of where to send the packet. - when receiving packets from the unspecified address (e.g. on the PAA), one needs a way of identifying which machine the packet came from. Normally, this would be the source IP address. But if that address is the unspecified address, we need something else. The two obvious choices are - use the sender's link-layer address. But note that now we aren't really using pure IP anymore (and we need stack/API support for this)... - add a field to the protocol itself that is used for this purpose. While that can be done with new protocols, it can't be done with existing protocols, so this approach is obviously not generally applicable where a goal is protocol reuse. Given that there are costs (and significant ones IMO) associated with using an unspecified address, I'm not convinced that the cost benefit tradeoff has been evaluated correctly. Thus, what I'd really like to understand is why the following isn't the standard pana model: - device gets an address using standard mechanisms (either DHC, IPv4 LL, or IPv6 LL). Since the PAA is required to be on the same IP link as the PAC, LL addressing works just fine. - Use the address obtained in the previous step to run PANA. Because its a proper address, IP-based protocols just work. - Once PANA has completed, obtain a proper/better address, if that is what is needed. (And there are lots of ways of doing this, but that comes later). Thomas Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 7 19:09:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15524 for ; Fri, 7 Nov 2003 19:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGey-0003vO-HV; Fri, 07 Nov 2003 19:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGeJ-0003uN-4y for pana@optimus.ietf.org; Fri, 07 Nov 2003 19:08:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15457 for ; Fri, 7 Nov 2003 19:08:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGeF-0005Oy-00 for pana@ietf.org; Fri, 07 Nov 2003 19:08:15 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AIGeE-0005Ov-00 for pana@ietf.org; Fri, 07 Nov 2003 19:08:15 -0500 Date: Fri, 07 Nov 2003 16:09:08 -0800 Subject: Re: [Pana] Issue 35 From: Alper Yegin To: Julien Bournelle CC: Message-ID: In-Reply-To: <20031107142647.GT72999@ipv6-5.int-evry.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> - This AVP MUST be included in PANA-Bind-Request when L2 or L3 ciphering >> will be enabled after PANA. There may be more than one such AVP at a time >> (for multiple access routers, for example). > > If we do L2 ciphering, do you think that the ciphering will occur > between pac and ep ? Yes. Whether it is L2 or L3 ciphering, it will take place between the PaC and EP. Of course, the EP might be co-located with the PAA. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 7 19:09:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15539 for ; Fri, 7 Nov 2003 19:09:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGf3-0003wO-PN for pana-archive@odin.ietf.org; Fri, 07 Nov 2003 19:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA809558015142 for pana-archive@odin.ietf.org; Fri, 7 Nov 2003 19:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGf3-0003w9-K0 for pana-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 19:09:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15492 for ; Fri, 7 Nov 2003 19:08:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGf0-0005Px-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 19:09:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIGez-0005Pu-00 for pana-web-archive@ietf.org; Fri, 07 Nov 2003 19:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGey-0003vO-HV; Fri, 07 Nov 2003 19:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGeJ-0003uN-4y for pana@optimus.ietf.org; Fri, 07 Nov 2003 19:08:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15457 for ; Fri, 7 Nov 2003 19:08:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGeF-0005Oy-00 for pana@ietf.org; Fri, 07 Nov 2003 19:08:15 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AIGeE-0005Ov-00 for pana@ietf.org; Fri, 07 Nov 2003 19:08:15 -0500 Date: Fri, 07 Nov 2003 16:09:08 -0800 Subject: Re: [Pana] Issue 35 From: Alper Yegin To: Julien Bournelle CC: Message-ID: In-Reply-To: <20031107142647.GT72999@ipv6-5.int-evry.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> - This AVP MUST be included in PANA-Bind-Request when L2 or L3 ciphering >> will be enabled after PANA. There may be more than one such AVP at a time >> (for multiple access routers, for example). > > If we do L2 ciphering, do you think that the ciphering will occur > between pac and ep ? Yes. Whether it is L2 or L3 ciphering, it will take place between the PaC and EP. Of course, the EP might be co-located with the PAA. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sat Nov 8 18:46:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01370 for ; Sat, 8 Nov 2003 18:46:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIcmI-0004I4-8N; Sat, 08 Nov 2003 18:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIclX-0004HW-UI for pana@optimus.ietf.org; Sat, 08 Nov 2003 18:45:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01344 for ; Sat, 8 Nov 2003 18:45:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIclU-0006cw-00 for pana@ietf.org; Sat, 08 Nov 2003 18:45:12 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AIclT-0006cs-00 for pana@ietf.org; Sat, 08 Nov 2003 18:45:12 -0500 Date: Sat, 08 Nov 2003 15:46:05 -0800 Subject: Re: [Pana] on PANA's requirement to use the unspecified address From: Alper Yegin To: Thomas Narten , Message-ID: In-Reply-To: <200311071200.hA7C08a05733@cichlid.adsl.duke.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ... > A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL > addressing are all vulnerable to DOS attacks that can prevent and > address from being assigned. But any PANA protocol will also be > subject to DOS attacks. E.g., it will almost certainly be possible to > interfere with ongoing PANA exchanges and cause DOS attacks that > prevent devices from obtaining service. We need to look at the specifics of this DoS attack. Why does this DAD-based attack deserves prevention? Because it is very easy to launch (low cost), an ongoing attack might not be detectable, it does not have to be network-wide (i.e., it can be directed at a targeted victim), and it can be relatively easily mitigated. > So the conclusion that PANA > must also support a mode of operation in which addresses have not been > assigned does not (in mind) immediately follow. I.e, the case needs to > be made that: > > a) the address depletion one is significant in the overall scheme of > things. > > b) using the unspecified address would not leave the network > vulnerable to other DOS attacks that make solving the previous one > a waste of time. Note: folk might want to look at > draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security > mechanisms after concluding they were useless due to bigger DOS > issues related to IP's reliance on ARP. > > Second, there are significant stack complications to allowing generic > communication with an unspecified address. Things to consider: > > - IP fragmentation doesn't work reliably anymore (a recieving machine > might think two fragments that are actually from two different > machines are from the same machine, and reassemble them improperly). Yes, when unspecified IP address is used, IP-layer fragmentation should not be used for PANA. But note that, fragmentation is a requirement on the EAP methods, not the EAP lower layers anyways. IP-layer fragmentation can be used as a bonus of PANA when PaC has an IP address, and not otherwise. > > - when sending to an unspecified address, the IP stack doens't know > where to send the packet. Thus, special hacks (and API changes) are > needed to specify the link-layer address (and interface) of where to > send the packet. Either that, or a broadcast destination should be used. This dual approach is used by DHCP. On the other hand, Mobile IPv4 relies on the special hacks. > > - when receiving packets from the unspecified address (e.g. on the > PAA), one needs a way of identifying which machine the packet came > from. Normally, this would be the source IP address. But if that > address is the unspecified address, we need something else. The two > obvious choices are > > - use the sender's link-layer address. But note that now we aren't > really using pure IP anymore (and we need stack/API support for > this)... > > - add a field to the protocol itself that is used for this > purpose. While that can be done with new protocols, it can't be > done with existing protocols, so this approach is obviously not > generally applicable where a goal is protocol reuse. We can use PANA session ID for this purpose (which is already defined for other reasons). So, when the special hack is not available, the implementation can rely on this field for matching the PANA packets with the clients. [btw, I'm not sure why we need to consider "existing protocols"] > > Given that there are costs (and significant ones IMO) associated with > using an unspecified address, I'm not convinced that the cost benefit > tradeoff has been evaluated correctly. > > Thus, what I'd really like to understand is why the following isn't > the standard pana model: > > - device gets an address using standard mechanisms (either DHC, IPv4 > LL, or IPv6 LL). Since the PAA is required to be on the same IP link > as the PAC, LL addressing works just fine. > > - Use the address obtained in the previous step to run PANA. Because > its a proper address, IP-based protocols just work. > > - Once PANA has completed, obtain a proper/better address, if that is > what is needed. (And there are lots of ways of doing this, but that > comes later). Aside from the security issue, this approach has additional burden on the deployment. For the first step, either the PaC should be using an IPv4 link-local implemantation, or the access network must be maintaining a DHCP pool of temporary PANA addresses. The latter might mean having to add a DHCP server on that network, which otherwise could be using a DHCP relay only. For the third step, PANA should signal whether the current IP address can be kept, and whether the PaC can (or has to) to obtain a new IP address. This shouldn't be hard to encode in the PANA design. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sat Nov 8 18:46:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01385 for ; Sat, 8 Nov 2003 18:46:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIcmO-0004J0-68 for pana-archive@odin.ietf.org; Sat, 08 Nov 2003 18:46:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8Nk8LP016544 for pana-archive@odin.ietf.org; Sat, 8 Nov 2003 18:46:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIcmO-0004Il-1S for pana-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 18:46:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01363 for ; Sat, 8 Nov 2003 18:45:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIcmK-0006iD-00 for pana-web-archive@ietf.org; Sat, 08 Nov 2003 18:46:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIcmK-0006i9-00 for pana-web-archive@ietf.org; Sat, 08 Nov 2003 18:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIcmI-0004I4-8N; Sat, 08 Nov 2003 18:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIclX-0004HW-UI for pana@optimus.ietf.org; Sat, 08 Nov 2003 18:45:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01344 for ; Sat, 8 Nov 2003 18:45:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIclU-0006cw-00 for pana@ietf.org; Sat, 08 Nov 2003 18:45:12 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AIclT-0006cs-00 for pana@ietf.org; Sat, 08 Nov 2003 18:45:12 -0500 Date: Sat, 08 Nov 2003 15:46:05 -0800 Subject: Re: [Pana] on PANA's requirement to use the unspecified address From: Alper Yegin To: Thomas Narten , Message-ID: In-Reply-To: <200311071200.hA7C08a05733@cichlid.adsl.duke.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ... > A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL > addressing are all vulnerable to DOS attacks that can prevent and > address from being assigned. But any PANA protocol will also be > subject to DOS attacks. E.g., it will almost certainly be possible to > interfere with ongoing PANA exchanges and cause DOS attacks that > prevent devices from obtaining service. We need to look at the specifics of this DoS attack. Why does this DAD-based attack deserves prevention? Because it is very easy to launch (low cost), an ongoing attack might not be detectable, it does not have to be network-wide (i.e., it can be directed at a targeted victim), and it can be relatively easily mitigated. > So the conclusion that PANA > must also support a mode of operation in which addresses have not been > assigned does not (in mind) immediately follow. I.e, the case needs to > be made that: > > a) the address depletion one is significant in the overall scheme of > things. > > b) using the unspecified address would not leave the network > vulnerable to other DOS attacks that make solving the previous one > a waste of time. Note: folk might want to look at > draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security > mechanisms after concluding they were useless due to bigger DOS > issues related to IP's reliance on ARP. > > Second, there are significant stack complications to allowing generic > communication with an unspecified address. Things to consider: > > - IP fragmentation doesn't work reliably anymore (a recieving machine > might think two fragments that are actually from two different > machines are from the same machine, and reassemble them improperly). Yes, when unspecified IP address is used, IP-layer fragmentation should not be used for PANA. But note that, fragmentation is a requirement on the EAP methods, not the EAP lower layers anyways. IP-layer fragmentation can be used as a bonus of PANA when PaC has an IP address, and not otherwise. > > - when sending to an unspecified address, the IP stack doens't know > where to send the packet. Thus, special hacks (and API changes) are > needed to specify the link-layer address (and interface) of where to > send the packet. Either that, or a broadcast destination should be used. This dual approach is used by DHCP. On the other hand, Mobile IPv4 relies on the special hacks. > > - when receiving packets from the unspecified address (e.g. on the > PAA), one needs a way of identifying which machine the packet came > from. Normally, this would be the source IP address. But if that > address is the unspecified address, we need something else. The two > obvious choices are > > - use the sender's link-layer address. But note that now we aren't > really using pure IP anymore (and we need stack/API support for > this)... > > - add a field to the protocol itself that is used for this > purpose. While that can be done with new protocols, it can't be > done with existing protocols, so this approach is obviously not > generally applicable where a goal is protocol reuse. We can use PANA session ID for this purpose (which is already defined for other reasons). So, when the special hack is not available, the implementation can rely on this field for matching the PANA packets with the clients. [btw, I'm not sure why we need to consider "existing protocols"] > > Given that there are costs (and significant ones IMO) associated with > using an unspecified address, I'm not convinced that the cost benefit > tradeoff has been evaluated correctly. > > Thus, what I'd really like to understand is why the following isn't > the standard pana model: > > - device gets an address using standard mechanisms (either DHC, IPv4 > LL, or IPv6 LL). Since the PAA is required to be on the same IP link > as the PAC, LL addressing works just fine. > > - Use the address obtained in the previous step to run PANA. Because > its a proper address, IP-based protocols just work. > > - Once PANA has completed, obtain a proper/better address, if that is > what is needed. (And there are lots of ways of doing this, but that > comes later). Aside from the security issue, this approach has additional burden on the deployment. For the first step, either the PaC should be using an IPv4 link-local implemantation, or the access network must be maintaining a DHCP pool of temporary PANA addresses. The latter might mean having to add a DHCP server on that network, which otherwise could be using a DHCP relay only. For the third step, PANA should signal whether the current IP address can be kept, and whether the PaC can (or has to) to obtain a new IP address. This shouldn't be hard to encode in the PANA design. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sat Nov 8 21:44:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04612 for ; Sat, 8 Nov 2003 21:44:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfYW-0002Gw-OD; Sat, 08 Nov 2003 21:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfXg-0002Do-Q4 for pana@optimus.ietf.org; Sat, 08 Nov 2003 21:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04557 for ; Sat, 8 Nov 2003 21:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfXd-0000z5-00 for pana@ietf.org; Sat, 08 Nov 2003 21:43:05 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AIfXc-0000yy-00 for pana@ietf.org; Sat, 08 Nov 2003 21:43:05 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sat, 8 Nov 2003 21:42:31 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EAB@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Thomas Narten , pana@ietf.org Subject: RE: [Pana] on PANA's requirement to use the unspecified address Date: Sat, 8 Nov 2003 21:42:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > Thus, what I'd really like to understand is why the following isn't > > the standard pana model: > > > > - device gets an address using standard mechanisms (either > DHC, IPv4 > > LL, or IPv6 LL). Since the PAA is required to be on the > same IP link > > as the PAC, LL addressing works just fine. > > > > - Use the address obtained in the previous step to run > PANA. Because > > its a proper address, IP-based protocols just work. > > > > - Once PANA has completed, obtain a proper/better address, > if that is > > what is needed. (And there are lots of ways of doing this, but that > > comes later). > > Aside from the security issue, this approach has additional > burden on the > deployment. > > For the first step, either the PaC should be using an IPv4 link-local > implemantation, or the access network must be maintaining a > DHCP pool of > temporary PANA addresses. The latter might mean having to > add a DHCP server > on that network, which otherwise could be using a DHCP relay only. => Why not just provide a normal address (not LL and not a temp "special" DHC address for PANA)? The address could be provided with a short lease time if DoS is the issue. Do people know of current deployments that use HTTP redirect and do not provide an IP address at the beginning? We can have the same model in PANA. What happens if you connect to the WLAN today, get an address and then never login the HTTP redirect? This is certainly possible. > > For the third step, PANA should signal whether the current > IP address can be > kept, and whether the PaC can (or has to) to obtain a new IP > address. => I wouldn't worry about that, I'd just provide the proper address from the beginning. Hesham _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sat Nov 8 21:44:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04627 for ; Sat, 8 Nov 2003 21:44:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfYc-0002Hw-6C for pana-archive@odin.ietf.org; Sat, 08 Nov 2003 21:44:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA92i6A1008790 for pana-archive@odin.ietf.org; Sat, 8 Nov 2003 21:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfYc-0002Hh-1P for pana-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 21:44:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04609 for ; Sat, 8 Nov 2003 21:43:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfYZ-0000zv-00 for pana-web-archive@ietf.org; Sat, 08 Nov 2003 21:44:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIfYY-0000zs-00 for pana-web-archive@ietf.org; Sat, 08 Nov 2003 21:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfYW-0002Gw-OD; Sat, 08 Nov 2003 21:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfXg-0002Do-Q4 for pana@optimus.ietf.org; Sat, 08 Nov 2003 21:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04557 for ; Sat, 8 Nov 2003 21:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfXd-0000z5-00 for pana@ietf.org; Sat, 08 Nov 2003 21:43:05 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AIfXc-0000yy-00 for pana@ietf.org; Sat, 08 Nov 2003 21:43:05 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sat, 8 Nov 2003 21:42:31 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EAB@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Thomas Narten , pana@ietf.org Subject: RE: [Pana] on PANA's requirement to use the unspecified address Date: Sat, 8 Nov 2003 21:42:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > Thus, what I'd really like to understand is why the following isn't > > the standard pana model: > > > > - device gets an address using standard mechanisms (either > DHC, IPv4 > > LL, or IPv6 LL). Since the PAA is required to be on the > same IP link > > as the PAC, LL addressing works just fine. > > > > - Use the address obtained in the previous step to run > PANA. Because > > its a proper address, IP-based protocols just work. > > > > - Once PANA has completed, obtain a proper/better address, > if that is > > what is needed. (And there are lots of ways of doing this, but that > > comes later). > > Aside from the security issue, this approach has additional > burden on the > deployment. > > For the first step, either the PaC should be using an IPv4 link-local > implemantation, or the access network must be maintaining a > DHCP pool of > temporary PANA addresses. The latter might mean having to > add a DHCP server > on that network, which otherwise could be using a DHCP relay only. => Why not just provide a normal address (not LL and not a temp "special" DHC address for PANA)? The address could be provided with a short lease time if DoS is the issue. Do people know of current deployments that use HTTP redirect and do not provide an IP address at the beginning? We can have the same model in PANA. What happens if you connect to the WLAN today, get an address and then never login the HTTP redirect? This is certainly possible. > > For the third step, PANA should signal whether the current > IP address can be > kept, and whether the PaC can (or has to) to obtain a new IP > address. => I wouldn't worry about that, I'd just provide the proper address from the beginning. Hesham _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 10:36:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24958 for ; Mon, 10 Nov 2003 10:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJE5B-0002Wg-0m; Mon, 10 Nov 2003 10:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJE54-0002Vp-2F for pana@optimus.ietf.org; Mon, 10 Nov 2003 10:35:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24882 for ; Mon, 10 Nov 2003 10:35:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJE50-0006AM-00 for pana@ietf.org; Mon, 10 Nov 2003 10:35:50 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AJE50-0006AI-00 for pana@ietf.org; Mon, 10 Nov 2003 10:35:50 -0500 Date: Mon, 10 Nov 2003 09:35:13 -0800 Subject: Re: [Pana] on PANA's requirement to use the unspecified address From: Alper Yegin To: Soliman Hesham , Thomas Narten , Message-ID: In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922EAB@ftmail.lab.flarion.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 11/8/03 6:42 PM, "Soliman Hesham" wrote: > >>> Thus, what I'd really like to understand is why the following isn't >>> the standard pana model: >>> >>> - device gets an address using standard mechanisms (either >> DHC, IPv4 >>> LL, or IPv6 LL). Since the PAA is required to be on the >> same IP link >>> as the PAC, LL addressing works just fine. >>> >>> - Use the address obtained in the previous step to run >> PANA. Because >>> its a proper address, IP-based protocols just work. >>> >>> - Once PANA has completed, obtain a proper/better address, >> if that is >>> what is needed. (And there are lots of ways of doing this, but that >>> comes later). >> >> Aside from the security issue, this approach has additional >> burden on the >> deployment. >> >> For the first step, either the PaC should be using an IPv4 link-local >> implemantation, or the access network must be maintaining a >> DHCP pool of >> temporary PANA addresses. The latter might mean having to >> add a DHCP server >> on that network, which otherwise could be using a DHCP relay only. > > => Why not just provide a normal address (not LL and not > a temp "special" DHC address for PANA)? The address could be > provided with a short lease time if DoS is the issue. > Do people know of current deployments that use HTTP > redirect and do not provide an IP address at the beginning? > We can have the same model in PANA. What happens if you > connect to the WLAN today, get an address and then never > login the HTTP redirect? This is certainly possible. > >> >> For the third step, PANA should signal whether the current >> IP address can be >> kept, and whether the PaC can (or has to) to obtain a new IP >> address. > > => I wouldn't worry about that, I'd just provide the proper > address from the beginning. This doesn't help the networks where the address assignment depends on the client's identity. In such networks, final address assignment must take place after the client authentication. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 10:36:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24975 for ; Mon, 10 Nov 2003 10:36:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJE5J-0002Yz-Fo for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 10:36:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAFa9rR009849 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 10:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJE5H-0002Xu-TK for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 10:36:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24894 for ; Mon, 10 Nov 2003 10:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJE5F-0006Aa-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 10:36:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJE5F-0006AW-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 10:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJE5B-0002Wg-0m; Mon, 10 Nov 2003 10:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJE54-0002Vp-2F for pana@optimus.ietf.org; Mon, 10 Nov 2003 10:35:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24882 for ; Mon, 10 Nov 2003 10:35:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJE50-0006AM-00 for pana@ietf.org; Mon, 10 Nov 2003 10:35:50 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AJE50-0006AI-00 for pana@ietf.org; Mon, 10 Nov 2003 10:35:50 -0500 Date: Mon, 10 Nov 2003 09:35:13 -0800 Subject: Re: [Pana] on PANA's requirement to use the unspecified address From: Alper Yegin To: Soliman Hesham , Thomas Narten , Message-ID: In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922EAB@ftmail.lab.flarion.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11/8/03 6:42 PM, "Soliman Hesham" wrote: > >>> Thus, what I'd really like to understand is why the following isn't >>> the standard pana model: >>> >>> - device gets an address using standard mechanisms (either >> DHC, IPv4 >>> LL, or IPv6 LL). Since the PAA is required to be on the >> same IP link >>> as the PAC, LL addressing works just fine. >>> >>> - Use the address obtained in the previous step to run >> PANA. Because >>> its a proper address, IP-based protocols just work. >>> >>> - Once PANA has completed, obtain a proper/better address, >> if that is >>> what is needed. (And there are lots of ways of doing this, but that >>> comes later). >> >> Aside from the security issue, this approach has additional >> burden on the >> deployment. >> >> For the first step, either the PaC should be using an IPv4 link-local >> implemantation, or the access network must be maintaining a >> DHCP pool of >> temporary PANA addresses. The latter might mean having to >> add a DHCP server >> on that network, which otherwise could be using a DHCP relay only. > > => Why not just provide a normal address (not LL and not > a temp "special" DHC address for PANA)? The address could be > provided with a short lease time if DoS is the issue. > Do people know of current deployments that use HTTP > redirect and do not provide an IP address at the beginning? > We can have the same model in PANA. What happens if you > connect to the WLAN today, get an address and then never > login the HTTP redirect? This is certainly possible. > >> >> For the third step, PANA should signal whether the current >> IP address can be >> kept, and whether the PaC can (or has to) to obtain a new IP >> address. > > => I wouldn't worry about that, I'd just provide the proper > address from the beginning. This doesn't help the networks where the address assignment depends on the client's identity. In such networks, final address assignment must take place after the client authentication. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 11:02:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26795 for ; Mon, 10 Nov 2003 11:02:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUL-0004u3-O2; Mon, 10 Nov 2003 11:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJETv-0004qZ-Uc for pana@optimus.ietf.org; Mon, 10 Nov 2003 11:01:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26724 for ; Mon, 10 Nov 2003 11:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJETt-0006qn-00 for pana@ietf.org; Mon, 10 Nov 2003 11:01:33 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AJETs-0006qk-00 for pana@ietf.org; Mon, 10 Nov 2003 11:01:32 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5B4B76A903; Mon, 10 Nov 2003 18:01:23 +0200 (EET) Message-ID: <3FAFB550.5030802@piuha.net> Date: Mon, 10 Nov 2003 17:57:04 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: Soliman Hesham , Thomas Narten , pana@ietf.org Subject: Re: [Pana] on PANA's requirement to use the unspecified address References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit First, I'd like to echo Thomas' concern on the use of the unspecified address. I think it is likely that either PANA or EAP within PANA has a similar DoS issue as we are trying to avoid here. And then to what Alper said: > This doesn't help the networks where the address assignment depends on the > client's identity. In such networks, final address assignment must take > place after the client authentication. Yes, I agree that this can be a requirement in some cases. But in a way, it highlights another issue: what are the addresses that are used on the wire. Are they first some local addresses, and then *switch* to addresses from an ISP? If yes, I'd like to understand if both addresses are still considered to be "on-link" and whether you can use either one at any time? Or do we need to know that in state X of PANA the addresses are local and in state Y they are from the ISP? What if the ISP and the local addresses overlap? Or perhaps the intention is that there's *encapsulation* so that the local addresses always appear on the PANA packets or on the outer headers of payload packets, and the ISP addresses can appear only in the inner headers? --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 11:02:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26813 for ; Mon, 10 Nov 2003 11:02:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUS-0004wH-Dw for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 11:02:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAG28CE018984 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 11:02:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUS-0004ur-8B for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:02:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26754 for ; Mon, 10 Nov 2003 11:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEUM-0006ri-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 11:02:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEUM-0006rf-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 11:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUL-0004u3-O2; Mon, 10 Nov 2003 11:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJETv-0004qZ-Uc for pana@optimus.ietf.org; Mon, 10 Nov 2003 11:01:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26724 for ; Mon, 10 Nov 2003 11:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJETt-0006qn-00 for pana@ietf.org; Mon, 10 Nov 2003 11:01:33 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AJETs-0006qk-00 for pana@ietf.org; Mon, 10 Nov 2003 11:01:32 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5B4B76A903; Mon, 10 Nov 2003 18:01:23 +0200 (EET) Message-ID: <3FAFB550.5030802@piuha.net> Date: Mon, 10 Nov 2003 17:57:04 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: Soliman Hesham , Thomas Narten , pana@ietf.org Subject: Re: [Pana] on PANA's requirement to use the unspecified address References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit First, I'd like to echo Thomas' concern on the use of the unspecified address. I think it is likely that either PANA or EAP within PANA has a similar DoS issue as we are trying to avoid here. And then to what Alper said: > This doesn't help the networks where the address assignment depends on the > client's identity. In such networks, final address assignment must take > place after the client authentication. Yes, I agree that this can be a requirement in some cases. But in a way, it highlights another issue: what are the addresses that are used on the wire. Are they first some local addresses, and then *switch* to addresses from an ISP? If yes, I'd like to understand if both addresses are still considered to be "on-link" and whether you can use either one at any time? Or do we need to know that in state X of PANA the addresses are local and in state Y they are from the ISP? What if the ISP and the local addresses overlap? Or perhaps the intention is that there's *encapsulation* so that the local addresses always appear on the PANA packets or on the outer headers of payload packets, and the ISP addresses can appear only in the inner headers? --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 11:33:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28569 for ; Mon, 10 Nov 2003 11:33:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyL-0006pF-MQ; Mon, 10 Nov 2003 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJExW-0006oi-QE for pana@optimus.ietf.org; Mon, 10 Nov 2003 11:32:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28498 for ; Mon, 10 Nov 2003 11:31:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJExV-0007U5-00 for pana@ietf.org; Mon, 10 Nov 2003 11:32:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AJExV-0007TM-00 for pana@ietf.org; Mon, 10 Nov 2003 11:32:09 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Nov 2003 11:31:19 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EB7@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Thomas Narten , pana@ietf.org Subject: RE: [Pana] on PANA's requirement to use the unspecified address Date: Mon, 10 Nov 2003 11:30:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > => I wouldn't worry about that, I'd just provide the proper > > address from the beginning. > > This doesn't help the networks where the address assignment > depends on the > client's identity. In such networks, final address > assignment must take > place after the client authentication. => Or: The IP address is assigned before authentication and is communicated during the authentication. This could then be used to open up the filters for that address/MAC combination. The only argument against that is of course the fear of DoS (address depletion). But as I said earlier operators just don't seem to care about this, at least in the small deployments that I used. Perhaps others have different experiences? Hesham PS: FWIW my cable modem operator does exactly that, address assignment first, then login. I've also seen it wherever they have HTTP redirect used for authentication. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 11:33:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28584 for ; Mon, 10 Nov 2003 11:33:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyQ-0006qh-PI for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 11:33:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGX62P026321 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 11:33:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyQ-0006qS-1w for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:33:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28548 for ; Mon, 10 Nov 2003 11:32:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEyP-0007VB-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 11:33:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEyO-0007V8-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 11:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyL-0006pF-MQ; Mon, 10 Nov 2003 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJExW-0006oi-QE for pana@optimus.ietf.org; Mon, 10 Nov 2003 11:32:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28498 for ; Mon, 10 Nov 2003 11:31:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJExV-0007U5-00 for pana@ietf.org; Mon, 10 Nov 2003 11:32:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AJExV-0007TM-00 for pana@ietf.org; Mon, 10 Nov 2003 11:32:09 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Nov 2003 11:31:19 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EB7@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Thomas Narten , pana@ietf.org Subject: RE: [Pana] on PANA's requirement to use the unspecified address Date: Mon, 10 Nov 2003 11:30:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > => I wouldn't worry about that, I'd just provide the proper > > address from the beginning. > > This doesn't help the networks where the address assignment > depends on the > client's identity. In such networks, final address > assignment must take > place after the client authentication. => Or: The IP address is assigned before authentication and is communicated during the authentication. This could then be used to open up the filters for that address/MAC combination. The only argument against that is of course the fear of DoS (address depletion). But as I said earlier operators just don't seem to care about this, at least in the small deployments that I used. Perhaps others have different experiences? Hesham PS: FWIW my cable modem operator does exactly that, address assignment first, then login. I've also seen it wherever they have HTTP redirect used for authentication. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 11:54:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29803 for ; Mon, 10 Nov 2003 11:54:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFIf-0000mE-PE; Mon, 10 Nov 2003 11:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFHi-0000hS-0V for pana@optimus.ietf.org; Mon, 10 Nov 2003 11:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29705 for ; Mon, 10 Nov 2003 11:52:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFHg-00005i-00 for pana@ietf.org; Mon, 10 Nov 2003 11:53:00 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AJFHf-00005b-00 for pana@ietf.org; Mon, 10 Nov 2003 11:53:00 -0500 Date: Mon, 10 Nov 2003 10:50:12 -0800 Subject: Re: [Pana] on PANA's requirement to use the unspecified address From: Alper Yegin To: CC: Soliman Hesham , Thomas Narten , Message-ID: In-Reply-To: <3FAFB550.5030802@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > First, I'd like to echo Thomas' concern on the use of the unspecified > address. I think it is likely that either PANA or EAP within PANA has > a similar DoS issue as we are trying to avoid here. As I was saying earlier, we should look at the specifics of the DoS attacks. Are you thinking of any particular DoS attack in PANA or EAP? > > And then to what Alper said: > >> This doesn't help the networks where the address assignment depends on the >> client's identity. In such networks, final address assignment must take >> place after the client authentication. > > Yes, I agree that this can be a requirement in some cases. But in a way, > it highlights another issue: what are the addresses that are used on the > wire. Are they first some local addresses, and then *switch* to addresses > from an ISP? This switch is necessary if we require PaC to have an IP address prior to using PANA, and we are not using IPsec-based access control (i.e., no tunnel between PaC and EP). [if IPsec-based access control is used, then the "local address" becomes the local end-point of the tunnel, and the ISP-based address should be configured inside the tunnel] > If yes, I'd like to understand if both addresses are still > considered to be "on-link" and whether you can use either one at any > time? Or do we need to know that in state X of PANA the addresses are > local and in state Y they are from the ISP? What if the ISP and the > local addresses overlap? Local address should be used for PANA exchanges and tunneling data packets to EP when IPsec-based access control is used. If IPsec-based access control is not used, the local addresses are not needed. In case of IPv4, they can cause trouble. The host should not have more than one IPv4 address. In IPv6, the host can deal with this if the local address is a IPv6 link-local address. > > Or perhaps the intention is that there's *encapsulation* so that the > local addresses always appear on the PANA packets or on the outer > headers of payload packets, and the ISP addresses can appear only > in the inner headers? Yes. When the local addresses are maintained on the PaC, this should be their use. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 11:54:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29850 for ; Mon, 10 Nov 2003 11:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFIk-0000nA-KW for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 11:54:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGs6nS003044 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 11:54:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFIj-0000n1-Jo for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29774 for ; Mon, 10 Nov 2003 11:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFIi-000075-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 11:54:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFIh-000071-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 11:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFIf-0000mE-PE; Mon, 10 Nov 2003 11:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFHi-0000hS-0V for pana@optimus.ietf.org; Mon, 10 Nov 2003 11:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29705 for ; Mon, 10 Nov 2003 11:52:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFHg-00005i-00 for pana@ietf.org; Mon, 10 Nov 2003 11:53:00 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AJFHf-00005b-00 for pana@ietf.org; Mon, 10 Nov 2003 11:53:00 -0500 Date: Mon, 10 Nov 2003 10:50:12 -0800 Subject: Re: [Pana] on PANA's requirement to use the unspecified address From: Alper Yegin To: CC: Soliman Hesham , Thomas Narten , Message-ID: In-Reply-To: <3FAFB550.5030802@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > First, I'd like to echo Thomas' concern on the use of the unspecified > address. I think it is likely that either PANA or EAP within PANA has > a similar DoS issue as we are trying to avoid here. As I was saying earlier, we should look at the specifics of the DoS attacks. Are you thinking of any particular DoS attack in PANA or EAP? > > And then to what Alper said: > >> This doesn't help the networks where the address assignment depends on the >> client's identity. In such networks, final address assignment must take >> place after the client authentication. > > Yes, I agree that this can be a requirement in some cases. But in a way, > it highlights another issue: what are the addresses that are used on the > wire. Are they first some local addresses, and then *switch* to addresses > from an ISP? This switch is necessary if we require PaC to have an IP address prior to using PANA, and we are not using IPsec-based access control (i.e., no tunnel between PaC and EP). [if IPsec-based access control is used, then the "local address" becomes the local end-point of the tunnel, and the ISP-based address should be configured inside the tunnel] > If yes, I'd like to understand if both addresses are still > considered to be "on-link" and whether you can use either one at any > time? Or do we need to know that in state X of PANA the addresses are > local and in state Y they are from the ISP? What if the ISP and the > local addresses overlap? Local address should be used for PANA exchanges and tunneling data packets to EP when IPsec-based access control is used. If IPsec-based access control is not used, the local addresses are not needed. In case of IPv4, they can cause trouble. The host should not have more than one IPv4 address. In IPv6, the host can deal with this if the local address is a IPv6 link-local address. > > Or perhaps the intention is that there's *encapsulation* so that the > local addresses always appear on the PANA packets or on the outer > headers of payload packets, and the ISP addresses can appear only > in the inner headers? Yes. When the local addresses are maintained on the PaC, this should be their use. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 15:14:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10562 for ; Mon, 10 Nov 2003 15:14:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIQC-0006ho-Po; Mon, 10 Nov 2003 15:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIQA-0006hG-DD for pana@optimus.ietf.org; Mon, 10 Nov 2003 15:13:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10492 for ; Mon, 10 Nov 2003 15:13:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIQ9-0003j3-00 for pana@ietf.org; Mon, 10 Nov 2003 15:13:57 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AJIQ8-0003it-00 for pana@ietf.org; Mon, 10 Nov 2003 15:13:56 -0500 Date: Mon, 10 Nov 2003 13:56:40 -0800 Subject: Re: [Pana] on PANA's requirement to use the unspecified address From: Alper Yegin To: Soliman Hesham , Thomas Narten , Message-ID: In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922EB7@ftmail.lab.flarion.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>> => I wouldn't worry about that, I'd just provide the proper >>> address from the beginning. >> >> This doesn't help the networks where the address assignment >> depends on the >> client's identity. In such networks, final address >> assignment must take >> place after the client authentication. > > => Or: The IP address is assigned before authentication > and is communicated during the authentication. You mean one IP address is assigned prior to auth, and another one after auth? If so, this causes the additional complexity as I outlined earlier. [remember, I was trying to make the point that the IP address that is assigned prior to PANA might not be the final IP address Pac will use to access the Internet] > This could > then be used to open up the filters for that address/MAC > combination. The only argument against that is of course > the fear of DoS (address depletion). But as I said earlier > operators just don't seem to care about this, at least > in the small deployments that I used. Perhaps others > have different experiences? As I understand, the operators would like to authenticate the client before allocating any resources, when possible. In the case of captive portal this is not possible, because you need to have an IP address to access a web page. > > Hesham > > PS: FWIW my cable modem operator does exactly that, address > assignment first, then login. I've also seen it wherever > they have HTTP redirect used for authentication. They don't have any other option, when they need to carry HTTP packets over TCP. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 15:14:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10575 for ; Mon, 10 Nov 2003 15:14:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIQF-0006iX-OS for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 15:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKE3U5025815 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 15:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIQF-0006iI-Jy for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:14:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10510 for ; Mon, 10 Nov 2003 15:13:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIQE-0003jW-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 15:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJIQE-0003jT-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 15:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIQC-0006ho-Po; Mon, 10 Nov 2003 15:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIQA-0006hG-DD for pana@optimus.ietf.org; Mon, 10 Nov 2003 15:13:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10492 for ; Mon, 10 Nov 2003 15:13:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIQ9-0003j3-00 for pana@ietf.org; Mon, 10 Nov 2003 15:13:57 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AJIQ8-0003it-00 for pana@ietf.org; Mon, 10 Nov 2003 15:13:56 -0500 Date: Mon, 10 Nov 2003 13:56:40 -0800 Subject: Re: [Pana] on PANA's requirement to use the unspecified address From: Alper Yegin To: Soliman Hesham , Thomas Narten , Message-ID: In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922EB7@ftmail.lab.flarion.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>> => I wouldn't worry about that, I'd just provide the proper >>> address from the beginning. >> >> This doesn't help the networks where the address assignment >> depends on the >> client's identity. In such networks, final address >> assignment must take >> place after the client authentication. > > => Or: The IP address is assigned before authentication > and is communicated during the authentication. You mean one IP address is assigned prior to auth, and another one after auth? If so, this causes the additional complexity as I outlined earlier. [remember, I was trying to make the point that the IP address that is assigned prior to PANA might not be the final IP address Pac will use to access the Internet] > This could > then be used to open up the filters for that address/MAC > combination. The only argument against that is of course > the fear of DoS (address depletion). But as I said earlier > operators just don't seem to care about this, at least > in the small deployments that I used. Perhaps others > have different experiences? As I understand, the operators would like to authenticate the client before allocating any resources, when possible. In the case of captive portal this is not possible, because you need to have an IP address to access a web page. > > Hesham > > PS: FWIW my cable modem operator does exactly that, address > assignment first, then login. I've also seen it wherever > they have HTTP redirect used for authentication. They don't have any other option, when they need to carry HTTP packets over TCP. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 15:59:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13299 for ; Mon, 10 Nov 2003 15:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ7k-0002Lt-UK; Mon, 10 Nov 2003 15:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ2W-0001iY-Pd for pana@optimus.ietf.org; Mon, 10 Nov 2003 15:53:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12974 for ; Mon, 10 Nov 2003 15:53:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2U-0004Tx-00 for pana@ietf.org; Mon, 10 Nov 2003 15:53:34 -0500 Received: from mx03.net.com ([134.56.3.133]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2T-0004Ti-00 for pana@ietf.org; Mon, 10 Nov 2003 15:53:34 -0500 Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by mx03.net.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id hAAKnBn06095 for ; Mon, 10 Nov 2003 12:49:11 -0800 (PST) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx01-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id hAAKtWY15857 for ; Mon, 10 Nov 2003 12:55:32 -0800 (PST) Received: from net.com ([134.56.254.211]) by west-mail.net.com (Netscape Messaging Server 4.15) with ESMTP id HO5M3400.FNI; Mon, 10 Nov 2003 12:54:40 -0800 Message-ID: <3FAFFA3F.15154804@net.com> Date: Mon, 10 Nov 2003 14:51:11 -0600 From: "Prakash Jayaraman" Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.77 [en]C-NETv476west (Windows NT 5.0; U) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 To: Soliman Hesham CC: "'Alper Yegin'" , Thomas Narten , pana@ietf.org Subject: Re: [Pana] on PANA's requirement to use the unspecified address References: <748C6D0A58C0F94CA63C198B6674697A01922EB7@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > => I wouldn't worry about that, I'd just provide the proper > > > address from the beginning. > > > > This doesn't help the networks where the address assignment > > depends on the > > client's identity. In such networks, final address > > assignment must take > > place after the client authentication. > > => Or: The IP address is assigned before authentication > and is communicated during the authentication. This could > then be used to open up the filters for that address/MAC > combination. The only argument against that is of course > the fear of DoS (address depletion). But as I said earlier > operators just don't seem to care about this, at least > in the small deployments that I used. Perhaps others > have different experiences? This email is in response to Hesham's suggestion about assigning IP address before authentication phase: A typical NAS deployed in a large network usually serves multiple "Internet Service Providers" and "Application Service Providers". Every ISP owns a collection of IP address pools. Each collection is usually referred to as a "domain". A number of ISP's may use a single address space and hence a single routing context. Some NAS's support multiple routing contexts in the same physical device to allow the use of overlapping address spaces by multiple ISPs. (See the last paragraph about Application Service Providers). So, it is important for the NAS device to find out which ISP to allocate the IP address from. For PPP users, this is done by looking at the FQDN and associating the domain-part of it to an ISP. DHCP based access does not have this concept. It is primarily for host-configuration in a single routing context. All the hosts on a given interface must use a single ISP (and hence a single routing context), if they use DHCP. Cable modem operators own the NAS device as well as function as the only ISP. However, there are also wholesale models in which the NAS device is owned by one entity and the Internet Service is provided by multiple ISP's sharing the same NAS. If there is a single NAS and a single ISP, address-depletion-based DoS attack is equivalent to having a wrong-password. If there are multiple ISPs, the problem is more fundamental than that - NAS does not know which address to choose. In addition, this choice has to be dynamic (i.e. not statically configured) depending on the user's identity. Extending the host-configuration a bit beyond IP address assignment, the host should be configured depending on the user. A person usually connects to a domain creating a login-session. The domain has IP address pools, DNS servers, WINS servers, DHCP servers, email-server, access-control-lists, firewall rules etc. etc. and these parameters are specific to domains. NAS needs a way of figuring out the services to be offered to a user and it uses FQDN today. To offer the services successfully, host-configuration must be done after NAS performs a AAA procedure. - prakash > > Hesham > > PS: FWIW my cable modem operator does exactly that, address > assignment first, then login. I've also seen it wherever > they have HTTP redirect used for authentication. > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 15:59:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13314 for ; Mon, 10 Nov 2003 15:59:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ7o-0002Mm-Fb for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 15:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKx4Vs009090 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 15:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ7o-0002MX-Ai for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:59:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13289 for ; Mon, 10 Nov 2003 15:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ7m-0004Z9-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 15:59:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJ7m-0004Z5-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 15:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ7k-0002Lt-UK; Mon, 10 Nov 2003 15:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ2W-0001iY-Pd for pana@optimus.ietf.org; Mon, 10 Nov 2003 15:53:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12974 for ; Mon, 10 Nov 2003 15:53:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2U-0004Tx-00 for pana@ietf.org; Mon, 10 Nov 2003 15:53:34 -0500 Received: from mx03.net.com ([134.56.3.133]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2T-0004Ti-00 for pana@ietf.org; Mon, 10 Nov 2003 15:53:34 -0500 Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by mx03.net.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id hAAKnBn06095 for ; Mon, 10 Nov 2003 12:49:11 -0800 (PST) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx01-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id hAAKtWY15857 for ; Mon, 10 Nov 2003 12:55:32 -0800 (PST) Received: from net.com ([134.56.254.211]) by west-mail.net.com (Netscape Messaging Server 4.15) with ESMTP id HO5M3400.FNI; Mon, 10 Nov 2003 12:54:40 -0800 Message-ID: <3FAFFA3F.15154804@net.com> Date: Mon, 10 Nov 2003 14:51:11 -0600 From: "Prakash Jayaraman" Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.77 [en]C-NETv476west (Windows NT 5.0; U) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 To: Soliman Hesham CC: "'Alper Yegin'" , Thomas Narten , pana@ietf.org Subject: Re: [Pana] on PANA's requirement to use the unspecified address References: <748C6D0A58C0F94CA63C198B6674697A01922EB7@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > => I wouldn't worry about that, I'd just provide the proper > > > address from the beginning. > > > > This doesn't help the networks where the address assignment > > depends on the > > client's identity. In such networks, final address > > assignment must take > > place after the client authentication. > > => Or: The IP address is assigned before authentication > and is communicated during the authentication. This could > then be used to open up the filters for that address/MAC > combination. The only argument against that is of course > the fear of DoS (address depletion). But as I said earlier > operators just don't seem to care about this, at least > in the small deployments that I used. Perhaps others > have different experiences? This email is in response to Hesham's suggestion about assigning IP address before authentication phase: A typical NAS deployed in a large network usually serves multiple "Internet Service Providers" and "Application Service Providers". Every ISP owns a collection of IP address pools. Each collection is usually referred to as a "domain". A number of ISP's may use a single address space and hence a single routing context. Some NAS's support multiple routing contexts in the same physical device to allow the use of overlapping address spaces by multiple ISPs. (See the last paragraph about Application Service Providers). So, it is important for the NAS device to find out which ISP to allocate the IP address from. For PPP users, this is done by looking at the FQDN and associating the domain-part of it to an ISP. DHCP based access does not have this concept. It is primarily for host-configuration in a single routing context. All the hosts on a given interface must use a single ISP (and hence a single routing context), if they use DHCP. Cable modem operators own the NAS device as well as function as the only ISP. However, there are also wholesale models in which the NAS device is owned by one entity and the Internet Service is provided by multiple ISP's sharing the same NAS. If there is a single NAS and a single ISP, address-depletion-based DoS attack is equivalent to having a wrong-password. If there are multiple ISPs, the problem is more fundamental than that - NAS does not know which address to choose. In addition, this choice has to be dynamic (i.e. not statically configured) depending on the user's identity. Extending the host-configuration a bit beyond IP address assignment, the host should be configured depending on the user. A person usually connects to a domain creating a login-session. The domain has IP address pools, DNS servers, WINS servers, DHCP servers, email-server, access-control-lists, firewall rules etc. etc. and these parameters are specific to domains. NAS needs a way of figuring out the services to be offered to a user and it uses FQDN today. To offer the services successfully, host-configuration must be done after NAS performs a AAA procedure. - prakash > > Hesham > > PS: FWIW my cable modem operator does exactly that, address > assignment first, then login. I've also seen it wherever > they have HTTP redirect used for authentication. > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 20:37:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28155 for ; Mon, 10 Nov 2003 20:37:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNSn-0004F3-3Z; Mon, 10 Nov 2003 20:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLkK-0007ou-Nc for pana@optimus.ietf.org; Mon, 10 Nov 2003 18:47:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23591 for ; Mon, 10 Nov 2003 18:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLkH-00003Z-00 for pana@ietf.org; Mon, 10 Nov 2003 18:46:57 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AJLkG-00003U-00 for pana@ietf.org; Mon, 10 Nov 2003 18:46:56 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 00:46:44 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE : [Pana] on PANA's requirement to use the unspecified address Date: Tue, 11 Nov 2003 00:46:43 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0265B5518@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [Pana] on PANA's requirement to use the unspecified address Thread-Index: AcOnqFaWUXo13MS7QPCsp2j27hAvaQAMK1aA From: "MORAND Lionel FTRD/DAC/ISS" To: "Soliman Hesham" , "Alper Yegin" , "Thomas Narten" , X-OriginalArrivalTime: 10 Nov 2003 23:46:44.0226 (UTC) FILETIME=[E58F4620:01C3A7E4] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Hesham, All, > > > =3D> I wouldn't worry about that, I'd just provide the=20 > proper > > address from the beginning. >=20 > > This doesn't help the networks where the address assignment=20 > > depends on the > > client's identity. In such networks, final address=20 > > assignment must take > > place after the client authentication. >=20 > =3D> Or: The IP address is assigned before authentication > and is communicated during the authentication. This could > then be used to open up the filters for that address/MAC=20 > combination. The only argument against that is of course the=20 > fear of DoS (address depletion). But as I said earlier=20 > operators just don't seem to care about this, at least=20 > in the small deployments that I used. Perhaps others=20 > have different experiences?=20 >=20 > Hesham >=20 > PS: FWIW my cable modem operator does exactly that, address=20 > assignment first, then login. I've also seen it wherever they=20 > have HTTP redirect used for authentication. In the case of DSL networks, many scenarios require to authenticate the user before the IP address assignment. This is to configure the broadband access servers according to services subscribed by the user. This configuration is performed by the network access provider. When PPP is used, the configuration is based on information retrieved from the physical layer (ATM link). In the broadband server, there is actually a direct binding between the user, the ATM link and the PPP connection. When your are considering a small/personal/residential LAN connected to the Internet through a DSL access network, DHCP will be used. In that case, the binding user/access link is broken at the broadband access server level. A solution is then needed to authenticate the user. If HTTP redirect may be used when the user just wants to access to the Internet in early deployments (few requirements in terms of access configuration), this solution is not acceptable when you are thinking about the deployment of advanced service architectures on a large scale. By the way, when the DHCP server is located behind the brodband access server (belonging to the service provider) and you want to control any flow being sent over the access operator's IP backbone, you need to authenticate the user before any IP address allocation. If you refer to the mobile world, a user must be authenticated before requesting an IP address (using DHCP) through the GRX backbone (GRX is the private IP backbone interconnecting the mobile operator networks). This user authentication is also used to configure the access server according to subscribed services. So, from my point of view, there is indeed a need for supporting user authentication before any IP address allocation. Best regards, Lionel _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 20:37:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28170 for ; Mon, 10 Nov 2003 20:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNSr-0004Gu-JE for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 20:37:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB1b5WP016414 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 20:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNSq-0004GP-9s for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 20:37:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28137 for ; Mon, 10 Nov 2003 20:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNSo-0001wK-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 20:37:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNSn-0001wH-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 20:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNSn-0004F3-3Z; Mon, 10 Nov 2003 20:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLkK-0007ou-Nc for pana@optimus.ietf.org; Mon, 10 Nov 2003 18:47:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23591 for ; Mon, 10 Nov 2003 18:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLkH-00003Z-00 for pana@ietf.org; Mon, 10 Nov 2003 18:46:57 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AJLkG-00003U-00 for pana@ietf.org; Mon, 10 Nov 2003 18:46:56 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 00:46:44 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE : [Pana] on PANA's requirement to use the unspecified address Date: Tue, 11 Nov 2003 00:46:43 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0265B5518@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [Pana] on PANA's requirement to use the unspecified address Thread-Index: AcOnqFaWUXo13MS7QPCsp2j27hAvaQAMK1aA From: "MORAND Lionel FTRD/DAC/ISS" To: "Soliman Hesham" , "Alper Yegin" , "Thomas Narten" , X-OriginalArrivalTime: 10 Nov 2003 23:46:44.0226 (UTC) FILETIME=[E58F4620:01C3A7E4] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Hesham, All, > > > =3D> I wouldn't worry about that, I'd just provide the=20 > proper > > address from the beginning. >=20 > > This doesn't help the networks where the address assignment=20 > > depends on the > > client's identity. In such networks, final address=20 > > assignment must take > > place after the client authentication. >=20 > =3D> Or: The IP address is assigned before authentication > and is communicated during the authentication. This could > then be used to open up the filters for that address/MAC=20 > combination. The only argument against that is of course the=20 > fear of DoS (address depletion). But as I said earlier=20 > operators just don't seem to care about this, at least=20 > in the small deployments that I used. Perhaps others=20 > have different experiences?=20 >=20 > Hesham >=20 > PS: FWIW my cable modem operator does exactly that, address=20 > assignment first, then login. I've also seen it wherever they=20 > have HTTP redirect used for authentication. In the case of DSL networks, many scenarios require to authenticate the user before the IP address assignment. This is to configure the broadband access servers according to services subscribed by the user. This configuration is performed by the network access provider. When PPP is used, the configuration is based on information retrieved from the physical layer (ATM link). In the broadband server, there is actually a direct binding between the user, the ATM link and the PPP connection. When your are considering a small/personal/residential LAN connected to the Internet through a DSL access network, DHCP will be used. In that case, the binding user/access link is broken at the broadband access server level. A solution is then needed to authenticate the user. If HTTP redirect may be used when the user just wants to access to the Internet in early deployments (few requirements in terms of access configuration), this solution is not acceptable when you are thinking about the deployment of advanced service architectures on a large scale. By the way, when the DHCP server is located behind the brodband access server (belonging to the service provider) and you want to control any flow being sent over the access operator's IP backbone, you need to authenticate the user before any IP address allocation. If you refer to the mobile world, a user must be authenticated before requesting an IP address (using DHCP) through the GRX backbone (GRX is the private IP backbone interconnecting the mobile operator networks). This user authentication is also used to configure the access server according to subscribed services. So, from my point of view, there is indeed a need for supporting user authentication before any IP address allocation. Best regards, Lionel _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 21:11:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29945 for ; Mon, 10 Nov 2003 21:11:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNzi-0006l2-S0; Mon, 10 Nov 2003 21:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNyr-0006Xo-Jf for pana@optimus.ietf.org; Mon, 10 Nov 2003 21:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29809 for ; Mon, 10 Nov 2003 21:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNyc-0002YC-00 for pana@ietf.org; Mon, 10 Nov 2003 21:09:54 -0500 Received: from smtp809.mail.sc5.yahoo.com ([66.163.168.188]) by ietf-mx with smtp (Exim 4.12) id 1AJNyb-0002Y2-00 for pana@ietf.org; Mon, 10 Nov 2003 21:09:54 -0500 Received: from dyn135-181.ietf58.ietf.org (HELO adithya) (mohanp@sbcglobal.net@130.129.135.181 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 11 Nov 2003 02:09:53 -0000 Message-ID: <000201c3a7f8$e8544270$b5878182@adithya> From: "Mohan Parthasarathy" To: "Soliman Hesham" , "'Alper Yegin'" , "Thomas Narten" , References: <748C6D0A58C0F94CA63C198B6674697A01922EB7@ftmail.lab.flarion.com> Subject: Re: [Pana] on PANA's requirement to use the unspecified address Date: Mon, 10 Nov 2003 17:55:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > > => I wouldn't worry about that, I'd just provide the proper > > > address from the beginning. > > > > This doesn't help the networks where the address assignment > > depends on the > > client's identity. In such networks, final address > > assignment must take > > place after the client authentication. > > => Or: The IP address is assigned before authentication > and is communicated during the authentication. This could > then be used to open up the filters for that address/MAC > combination. The only argument against that is of course > the fear of DoS (address depletion). But as I said earlier > operators just don't seem to care about this, at least > in the small deployments that I used. Perhaps others > have different experiences? > I did not have enough battery power to test this. But at the airport, i got an address as soon as i connected to the network. It was a globally routable address. I could just use it for ping and any web access was redirected. It is easy to exhaust this and perhaps the airport operator does not care about this because not many people use it to access the internet ? -mohan > Hesham > > PS: FWIW my cable modem operator does exactly that, address > assignment first, then login. I've also seen it wherever > they have HTTP redirect used for authentication. > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 21:11:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29964 for ; Mon, 10 Nov 2003 21:11:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNzm-0006nJ-3j for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 21:11:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2B6RR026111 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 21:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNzl-0006n4-TL for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 21:11:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29910 for ; Mon, 10 Nov 2003 21:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNzj-0002aw-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 21:11:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNzi-0002at-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 21:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNzi-0006l2-S0; Mon, 10 Nov 2003 21:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNyr-0006Xo-Jf for pana@optimus.ietf.org; Mon, 10 Nov 2003 21:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29809 for ; Mon, 10 Nov 2003 21:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNyc-0002YC-00 for pana@ietf.org; Mon, 10 Nov 2003 21:09:54 -0500 Received: from smtp809.mail.sc5.yahoo.com ([66.163.168.188]) by ietf-mx with smtp (Exim 4.12) id 1AJNyb-0002Y2-00 for pana@ietf.org; Mon, 10 Nov 2003 21:09:54 -0500 Received: from dyn135-181.ietf58.ietf.org (HELO adithya) (mohanp@sbcglobal.net@130.129.135.181 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 11 Nov 2003 02:09:53 -0000 Message-ID: <000201c3a7f8$e8544270$b5878182@adithya> From: "Mohan Parthasarathy" To: "Soliman Hesham" , "'Alper Yegin'" , "Thomas Narten" , References: <748C6D0A58C0F94CA63C198B6674697A01922EB7@ftmail.lab.flarion.com> Subject: Re: [Pana] on PANA's requirement to use the unspecified address Date: Mon, 10 Nov 2003 17:55:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > => I wouldn't worry about that, I'd just provide the proper > > > address from the beginning. > > > > This doesn't help the networks where the address assignment > > depends on the > > client's identity. In such networks, final address > > assignment must take > > place after the client authentication. > > => Or: The IP address is assigned before authentication > and is communicated during the authentication. This could > then be used to open up the filters for that address/MAC > combination. The only argument against that is of course > the fear of DoS (address depletion). But as I said earlier > operators just don't seem to care about this, at least > in the small deployments that I used. Perhaps others > have different experiences? > I did not have enough battery power to test this. But at the airport, i got an address as soon as i connected to the network. It was a globally routable address. I could just use it for ping and any web access was redirected. It is easy to exhaust this and perhaps the airport operator does not care about this because not many people use it to access the internet ? -mohan > Hesham > > PS: FWIW my cable modem operator does exactly that, address > assignment first, then login. I've also seen it wherever > they have HTTP redirect used for authentication. > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 10 23:10:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04027 for ; Mon, 10 Nov 2003 23:10:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPqr-0006I0-Sm; Mon, 10 Nov 2003 23:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPqA-0006HV-GY for pana@optimus.ietf.org; Mon, 10 Nov 2003 23:09:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03953 for ; Mon, 10 Nov 2003 23:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPq6-0004Cj-00 for pana@ietf.org; Mon, 10 Nov 2003 23:09:14 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AJPq6-0004CM-00 for pana@ietf.org; Mon, 10 Nov 2003 23:09:14 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Nov 2003 23:08:42 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EBC@ftmail.lab.flarion.com> From: Soliman Hesham To: "'MORAND Lionel FTRD/DAC/ISS'" , Alper Yegin , Thomas Narten , pana@ietf.org Subject: RE: RE : [Pana] on PANA's requirement to use the unspecified addr ess Date: Mon, 10 Nov 2003 23:08:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Lionel, I wasn't referring to the mobile world. I was saying that today some operators allow you to get an IP address first then authenticate. So it seems like _those_ operators don't worry about the address depletion DoS. I'm wondering if that problem (that DoS) is not an artificial problem. I don't know if we can realistically satisfy both: Upper layer authentication and address allocation after authentication. Hesham > > > > => I wouldn't worry about that, I'd just provide the > > proper > > address from the beginning. > > > > This doesn't help the networks where the address assignment > > > depends on the > > > client's identity. In such networks, final address > > > assignment must take > > > place after the client authentication. > > > > => Or: The IP address is assigned before authentication > > and is communicated during the authentication. This could > > then be used to open up the filters for that address/MAC > > combination. The only argument against that is of course the > > fear of DoS (address depletion). But as I said earlier > > operators just don't seem to care about this, at least > > in the small deployments that I used. Perhaps others > > have different experiences? > > > > Hesham > > > > PS: FWIW my cable modem operator does exactly that, address > > assignment first, then login. I've also seen it wherever they > > have HTTP redirect used for authentication. > > In the case of DSL networks, many scenarios require to > authenticate the > user before the IP address assignment. This is to configure the > broadband access servers according to services subscribed by > the user. > This configuration is performed by the network access > provider. When PPP > is used, the configuration is based on information retrieved from the > physical layer (ATM link). In the broadband server, there is > actually a > direct binding between the user, the ATM link and the PPP connection. > > When your are considering a small/personal/residential LAN > connected to > the Internet through a DSL access network, DHCP will be used. In that > case, the binding user/access link is broken at the broadband access > server level. A solution is then needed to authenticate the user. If > HTTP redirect may be used when the user just wants to access to the > Internet in early deployments (few requirements in terms of access > configuration), this solution is not acceptable when you are thinking > about the deployment of advanced service architectures on a > large scale. > > By the way, when the DHCP server is located behind the > brodband access > server (belonging to the service provider) and you want to > control any > flow being sent over the access operator's IP backbone, you need to > authenticate the user before any IP address allocation. If > you refer to > the mobile world, a user must be authenticated before > requesting an IP > address (using DHCP) through the GRX backbone (GRX is the private IP > backbone interconnecting the mobile operator networks). This user > authentication is also used to configure the access server > according to > subscribed services. > > So, from my point of view, there is indeed a need for supporting user > authentication before any IP address allocation. > > Best regards, > > Lionel > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 10 23:10:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04084 for ; Mon, 10 Nov 2003 23:10:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPrB-0006J4-1t for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 23:10:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB4AD3o024216 for pana-archive@odin.ietf.org; Mon, 10 Nov 2003 23:10:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPqy-0006IV-6X for pana-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 23:10:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04000 for ; Mon, 10 Nov 2003 23:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPqu-0004DV-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 23:10:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPqu-0004DS-00 for pana-web-archive@ietf.org; Mon, 10 Nov 2003 23:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPqr-0006I0-Sm; Mon, 10 Nov 2003 23:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPqA-0006HV-GY for pana@optimus.ietf.org; Mon, 10 Nov 2003 23:09:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03953 for ; Mon, 10 Nov 2003 23:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPq6-0004Cj-00 for pana@ietf.org; Mon, 10 Nov 2003 23:09:14 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AJPq6-0004CM-00 for pana@ietf.org; Mon, 10 Nov 2003 23:09:14 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Nov 2003 23:08:42 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EBC@ftmail.lab.flarion.com> From: Soliman Hesham To: "'MORAND Lionel FTRD/DAC/ISS'" , Alper Yegin , Thomas Narten , pana@ietf.org Subject: RE: RE : [Pana] on PANA's requirement to use the unspecified addr ess Date: Mon, 10 Nov 2003 23:08:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Lionel, I wasn't referring to the mobile world. I was saying that today some operators allow you to get an IP address first then authenticate. So it seems like _those_ operators don't worry about the address depletion DoS. I'm wondering if that problem (that DoS) is not an artificial problem. I don't know if we can realistically satisfy both: Upper layer authentication and address allocation after authentication. Hesham > > > > => I wouldn't worry about that, I'd just provide the > > proper > > address from the beginning. > > > > This doesn't help the networks where the address assignment > > > depends on the > > > client's identity. In such networks, final address > > > assignment must take > > > place after the client authentication. > > > > => Or: The IP address is assigned before authentication > > and is communicated during the authentication. This could > > then be used to open up the filters for that address/MAC > > combination. The only argument against that is of course the > > fear of DoS (address depletion). But as I said earlier > > operators just don't seem to care about this, at least > > in the small deployments that I used. Perhaps others > > have different experiences? > > > > Hesham > > > > PS: FWIW my cable modem operator does exactly that, address > > assignment first, then login. I've also seen it wherever they > > have HTTP redirect used for authentication. > > In the case of DSL networks, many scenarios require to > authenticate the > user before the IP address assignment. This is to configure the > broadband access servers according to services subscribed by > the user. > This configuration is performed by the network access > provider. When PPP > is used, the configuration is based on information retrieved from the > physical layer (ATM link). In the broadband server, there is > actually a > direct binding between the user, the ATM link and the PPP connection. > > When your are considering a small/personal/residential LAN > connected to > the Internet through a DSL access network, DHCP will be used. In that > case, the binding user/access link is broken at the broadband access > server level. A solution is then needed to authenticate the user. If > HTTP redirect may be used when the user just wants to access to the > Internet in early deployments (few requirements in terms of access > configuration), this solution is not acceptable when you are thinking > about the deployment of advanced service architectures on a > large scale. > > By the way, when the DHCP server is located behind the > brodband access > server (belonging to the service provider) and you want to > control any > flow being sent over the access operator's IP backbone, you need to > authenticate the user before any IP address allocation. If > you refer to > the mobile world, a user must be authenticated before > requesting an IP > address (using DHCP) through the GRX backbone (GRX is the private IP > backbone interconnecting the mobile operator networks). This user > authentication is also used to configure the access server > according to > subscribed services. > > So, from my point of view, there is indeed a need for supporting user > authentication before any IP address allocation. > > Best regards, > > Lionel > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 11 05:16:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26064 for ; Tue, 11 Nov 2003 05:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVZ4-0001GS-Kk; Tue, 11 Nov 2003 05:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVYN-0001Fj-1J for pana@optimus.ietf.org; Tue, 11 Nov 2003 05:15:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26045 for ; Tue, 11 Nov 2003 05:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJVYJ-0000iO-00 for pana@ietf.org; Tue, 11 Nov 2003 05:15:15 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AJVYJ-0000i9-00 for pana@ietf.org; Tue, 11 Nov 2003 05:15:15 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Nov 2003 05:14:38 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EBE@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Prakash Jayaraman'" Cc: "'Alper Yegin'" , Thomas Narten , pana@ietf.org Subject: RE: [Pana] on PANA's requirement to use the unspecified address Date: Tue, 11 Nov 2003 05:14:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > This email is in response to Hesham's suggestion about assigning IP > address before authentication phase: > > A typical NAS deployed in a large network usually serves multiple > "Internet Service Providers" and "Application Service > Providers". Every > ISP owns a collection of IP address pools. Each collection is usually > referred to as a "domain". A number of ISP's may use a > single address > space and hence a single routing context. Some NAS's support multiple > routing contexts in the same physical device to allow the use of > overlapping address spaces by multiple ISPs. (See the last paragraph > about Application Service Providers). > > So, it is important for the NAS device to find out which ISP > to allocate > the IP address from. => Agreed. I also agree that this is a typical wholesale/retail split scenario where the wholesaler would want to use the right address pool for the retailer and therefore needs to know the client's id first. There is no dispute with the scenario itself, the question is whether PANA should be designed to do that as a default behaviour. If a certain optimisation requires that we require auth before address allocation then it can be added to the base PANA. But having that as a default behaviour introduces its own set of (significant) problems. The models you refer to do not use an upper layer auth protocol (please correct me if I'm wrong here). The only ones that do (I've cited a couple) allocate addresses first then authenticate. Why? because as Alper said "they don't have a choice". I wonder whether we could "magically" provide that choice, i.e. there is a cost involved. Hesham For PPP users, this is done by looking > at the FQDN > and associating the domain-part of it to an ISP. > > DHCP based access does not have this concept. It is primarily for > host-configuration in a single routing context. All the > hosts on a given > interface must use a single ISP (and hence a single routing > context), if > they use DHCP. Cable modem operators own the NAS device as well as > function as the only ISP. However, there are also wholesale models in > which the NAS device is owned by one entity and the Internet > Service is > provided by multiple ISP's sharing the same NAS. > > If there is a single NAS and a single ISP, > address-depletion-based DoS > attack is equivalent to having a wrong-password. If there > are multiple > ISPs, the problem is more fundamental than that - NAS does not know > which address to choose. In addition, this choice has to be dynamic > (i.e. not statically configured) depending on the user's identity. > > Extending the host-configuration a bit beyond IP address > assignment, the > host should be configured depending on the user. A person usually > connects to a domain creating a login-session. The domain > has IP address > pools, DNS servers, WINS servers, DHCP servers, email-server, > access-control-lists, firewall rules etc. etc. and these > parameters are > specific to domains. NAS needs a way of figuring out the > services to be > offered to a user and it uses FQDN today. To offer the services > successfully, host-configuration must be done after NAS > performs a AAA > procedure. > > - prakash > > > > > > Hesham > > > > PS: FWIW my cable modem operator does exactly that, address > > assignment first, then login. I've also seen it wherever > > they have HTTP redirect used for authentication. > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 11 05:16:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26087 for ; Tue, 11 Nov 2003 05:16:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVZB-0001JD-G4 for pana-archive@odin.ietf.org; Tue, 11 Nov 2003 05:16:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABAG9W7005026 for pana-archive@odin.ietf.org; Tue, 11 Nov 2003 05:16:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVZA-0001Il-1J for pana-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 05:16:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26057 for ; Tue, 11 Nov 2003 05:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJVZ6-0000l2-00 for pana-web-archive@ietf.org; Tue, 11 Nov 2003 05:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJVZ6-0000kz-00 for pana-web-archive@ietf.org; Tue, 11 Nov 2003 05:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVZ4-0001GS-Kk; Tue, 11 Nov 2003 05:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVYN-0001Fj-1J for pana@optimus.ietf.org; Tue, 11 Nov 2003 05:15:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26045 for ; Tue, 11 Nov 2003 05:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJVYJ-0000iO-00 for pana@ietf.org; Tue, 11 Nov 2003 05:15:15 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AJVYJ-0000i9-00 for pana@ietf.org; Tue, 11 Nov 2003 05:15:15 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Nov 2003 05:14:38 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EBE@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Prakash Jayaraman'" Cc: "'Alper Yegin'" , Thomas Narten , pana@ietf.org Subject: RE: [Pana] on PANA's requirement to use the unspecified address Date: Tue, 11 Nov 2003 05:14:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > This email is in response to Hesham's suggestion about assigning IP > address before authentication phase: > > A typical NAS deployed in a large network usually serves multiple > "Internet Service Providers" and "Application Service > Providers". Every > ISP owns a collection of IP address pools. Each collection is usually > referred to as a "domain". A number of ISP's may use a > single address > space and hence a single routing context. Some NAS's support multiple > routing contexts in the same physical device to allow the use of > overlapping address spaces by multiple ISPs. (See the last paragraph > about Application Service Providers). > > So, it is important for the NAS device to find out which ISP > to allocate > the IP address from. => Agreed. I also agree that this is a typical wholesale/retail split scenario where the wholesaler would want to use the right address pool for the retailer and therefore needs to know the client's id first. There is no dispute with the scenario itself, the question is whether PANA should be designed to do that as a default behaviour. If a certain optimisation requires that we require auth before address allocation then it can be added to the base PANA. But having that as a default behaviour introduces its own set of (significant) problems. The models you refer to do not use an upper layer auth protocol (please correct me if I'm wrong here). The only ones that do (I've cited a couple) allocate addresses first then authenticate. Why? because as Alper said "they don't have a choice". I wonder whether we could "magically" provide that choice, i.e. there is a cost involved. Hesham For PPP users, this is done by looking > at the FQDN > and associating the domain-part of it to an ISP. > > DHCP based access does not have this concept. It is primarily for > host-configuration in a single routing context. All the > hosts on a given > interface must use a single ISP (and hence a single routing > context), if > they use DHCP. Cable modem operators own the NAS device as well as > function as the only ISP. However, there are also wholesale models in > which the NAS device is owned by one entity and the Internet > Service is > provided by multiple ISP's sharing the same NAS. > > If there is a single NAS and a single ISP, > address-depletion-based DoS > attack is equivalent to having a wrong-password. If there > are multiple > ISPs, the problem is more fundamental than that - NAS does not know > which address to choose. In addition, this choice has to be dynamic > (i.e. not statically configured) depending on the user's identity. > > Extending the host-configuration a bit beyond IP address > assignment, the > host should be configured depending on the user. A person usually > connects to a domain creating a login-session. The domain > has IP address > pools, DNS servers, WINS servers, DHCP servers, email-server, > access-control-lists, firewall rules etc. etc. and these > parameters are > specific to domains. NAS needs a way of figuring out the > services to be > offered to a user and it uses FQDN today. To offer the services > successfully, host-configuration must be done after NAS > performs a AAA > procedure. > > - prakash > > > > > > Hesham > > > > PS: FWIW my cable modem operator does exactly that, address > > assignment first, then login. I've also seen it wherever > > they have HTTP redirect used for authentication. > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 11 10:22:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05316 for ; Tue, 11 Nov 2003 10:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaLB-0007Le-SW; Tue, 11 Nov 2003 10:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaKR-0007HT-GN for pana@optimus.ietf.org; Tue, 11 Nov 2003 10:21:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05195 for ; Tue, 11 Nov 2003 10:21:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJaKP-0004U2-00 for pana@ietf.org; Tue, 11 Nov 2003 10:21:13 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AJaKO-0004Th-00 for pana@ietf.org; Tue, 11 Nov 2003 10:21:12 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hABFKdcF421858; Tue, 11 Nov 2003 10:20:39 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-234-33.mts.ibm.com [9.65.234.33]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hABFKcwj161832; Tue, 11 Nov 2003 08:20:39 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id hABFHW310302; Tue, 11 Nov 2003 09:17:34 -0600 Message-Id: <200311111517.hABFHW310302@cichlid.raleigh.ibm.com> To: "Mohan Parthasarathy" cc: pana@ietf.org Subject: Re: [Pana] on PANA's requirement to use the unspecified address In-Reply-To: Message from mohanp@sbcglobal.net of "Fri, 07 Nov 2003 14:10:55 PST." <001d01c3a57c$03f59620$34100a0a@adithya> Date: Tue, 11 Nov 2003 09:17:28 -0600 From: Thomas Narten Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > > PANA SHOULD not assume that the PaC has acquired an IP address before > > > PANA begins. > It is a "SHOULD" above. Perhaps you are saying that it should be a "MAY" ? What I'd prefer, is that it not be even a MAY. I.e, just drop this completely. The basic problem here is that we are talking about a capability that the PANA protocol would need to support, even if it is only a MAY. It's like being a little pregnant. If there is a need (however rare in practice) that the unspecified address needs to be used, the PANA protocol has to include this and implementations will need to support it. So you have to deal with all the ramifications in the PANA protocol. > > a) the address depletion one is significant in the overall scheme of > > things. > > > > b) using the unspecified address would not leave the network > > vulnerable to other DOS attacks that make solving the previous one > > a waste of time. Note: folk might want to look at > > draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security > > mechanisms after concluding they were useless due to bigger DOS > > issues related to IP's reliance on ARP. > > > The basic idea is to see whether it is possible to mitigate against > address depletion attack assuming there are good tradeoffs. I am > not sure why this DoS attack needs special treatment compared > to other DoS attacks. Yep. That is what I'm trying to understand. > > Second, there are significant stack complications to allowing generic > > communication with an unspecified address. Things to consider: > > > > - IP fragmentation doesn't work reliably anymore (a recieving machine > > might think two fragments that are actually from two different > > machines are from the same machine, and reassemble them improperly). > > > Agreed. Some stacks maintain the reassembly queue per interface which solves > problem with link-local addresses in general. But for unspecified address, > unless mac addresses are used (which may not be reasonable), the problem > will exist. It is not reasonable, IMO, because this is a change to the IP stack itself. Not in the scope of PANA to require. Thomas _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 11 10:22:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05336 for ; Tue, 11 Nov 2003 10:22:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaLG-0007MO-MB for pana-archive@odin.ietf.org; Tue, 11 Nov 2003 10:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFM66p028288 for pana-archive@odin.ietf.org; Tue, 11 Nov 2003 10:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaLG-0007MB-HN for pana-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 10:22:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05279 for ; Tue, 11 Nov 2003 10:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJaLE-0004Ux-00 for pana-web-archive@ietf.org; Tue, 11 Nov 2003 10:22:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJaLD-0004Uu-00 for pana-web-archive@ietf.org; Tue, 11 Nov 2003 10:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaLB-0007Le-SW; Tue, 11 Nov 2003 10:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaKR-0007HT-GN for pana@optimus.ietf.org; Tue, 11 Nov 2003 10:21:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05195 for ; Tue, 11 Nov 2003 10:21:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJaKP-0004U2-00 for pana@ietf.org; Tue, 11 Nov 2003 10:21:13 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AJaKO-0004Th-00 for pana@ietf.org; Tue, 11 Nov 2003 10:21:12 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hABFKdcF421858; Tue, 11 Nov 2003 10:20:39 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-234-33.mts.ibm.com [9.65.234.33]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hABFKcwj161832; Tue, 11 Nov 2003 08:20:39 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id hABFHW310302; Tue, 11 Nov 2003 09:17:34 -0600 Message-Id: <200311111517.hABFHW310302@cichlid.raleigh.ibm.com> To: "Mohan Parthasarathy" cc: pana@ietf.org Subject: Re: [Pana] on PANA's requirement to use the unspecified address In-Reply-To: Message from mohanp@sbcglobal.net of "Fri, 07 Nov 2003 14:10:55 PST." <001d01c3a57c$03f59620$34100a0a@adithya> Date: Tue, 11 Nov 2003 09:17:28 -0600 From: Thomas Narten Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > > PANA SHOULD not assume that the PaC has acquired an IP address before > > > PANA begins. > It is a "SHOULD" above. Perhaps you are saying that it should be a "MAY" ? What I'd prefer, is that it not be even a MAY. I.e, just drop this completely. The basic problem here is that we are talking about a capability that the PANA protocol would need to support, even if it is only a MAY. It's like being a little pregnant. If there is a need (however rare in practice) that the unspecified address needs to be used, the PANA protocol has to include this and implementations will need to support it. So you have to deal with all the ramifications in the PANA protocol. > > a) the address depletion one is significant in the overall scheme of > > things. > > > > b) using the unspecified address would not leave the network > > vulnerable to other DOS attacks that make solving the previous one > > a waste of time. Note: folk might want to look at > > draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security > > mechanisms after concluding they were useless due to bigger DOS > > issues related to IP's reliance on ARP. > > > The basic idea is to see whether it is possible to mitigate against > address depletion attack assuming there are good tradeoffs. I am > not sure why this DoS attack needs special treatment compared > to other DoS attacks. Yep. That is what I'm trying to understand. > > Second, there are significant stack complications to allowing generic > > communication with an unspecified address. Things to consider: > > > > - IP fragmentation doesn't work reliably anymore (a recieving machine > > might think two fragments that are actually from two different > > machines are from the same machine, and reassemble them improperly). > > > Agreed. Some stacks maintain the reassembly queue per interface which solves > problem with link-local addresses in general. But for unspecified address, > unless mac addresses are used (which may not be reasonable), the problem > will exist. It is not reasonable, IMO, because this is a change to the IP stack itself. Not in the scope of PANA to require. Thomas _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 13 12:47:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10399 for ; Thu, 13 Nov 2003 12:47:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLYb-00085c-2b; Thu, 13 Nov 2003 12:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLYY-00085L-Rl for pana@optimus.ietf.org; Thu, 13 Nov 2003 12:46:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10377 for ; Thu, 13 Nov 2003 12:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLYX-0001s3-00 for pana@ietf.org; Thu, 13 Nov 2003 12:46:57 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AKLYW-0001rw-00 for pana@ietf.org; Thu, 13 Nov 2003 12:46:56 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 69AC36A908; Thu, 13 Nov 2003 19:46:48 +0200 (EET) Message-ID: <3FB39F1D.8050901@piuha.net> Date: Thu, 13 Nov 2003 17:11:25 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pana@ietf.org, Mohan Parthasarathy Cc: Bernard Aboba , James Kempf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] comments on draft-ietf-pana-ipsec-00.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have read draft-ietf-pana-ipsec-00.txt, and I have a few comments. Apologies if this has been discussed before, I was unable to participate the WG session due to other commitments. Here are the comments: - Section 3.0, bullet 3. This document appears to assume that the IPv6 node has a single address. What about RFC 3041 etc? - Section 4.0, Session ID. I'm glad that the document uses a session ID -- those are indeed needed, as it is possible that more than one EAP session was run, and we need to know where to refer to. However, I still have one problem with this. The problem is that it is not enough to use the Session ID as a part of the IKE pre-shared secret. It is also necessary to carry the session id information in IKE so that the two peers know which key to use. How do you intend to do that? The usual IKE payloads don't appear to carry this information, though it might be that ID_KEY_ID identity type might be usable. (The IKEv1 documents appear to imply that this type is normally used for vendor specific identification.) Or perhaps a new IKE identity type is needed. - Section 5.0, manual keying comment. It seems inappropriate. The purpose of PANA is to do an auth and then use those keys to protect traffic. If manual keys were used in IPsec, those would not be linked to the authentication, so it does not seem like a valid combination. - Section 5.0, main mode. I think the IP addresses are apparent from the packets themselves, but the session ID would have to be transported (perhaps in the identity payload) to distinguish possibly different EAP runs that you had done before. However, this seems problematic, as IKEv1 pre-shared secret mode does not allow the transport of the identity before the identity needs to be known. Are you relying on IKEv2, or would you have to resort to the use of aggressive mode only? - Section 5.0, aggressive mode. I don't understand what the issue with link-locals is. If the link-local addresses were not unique, how would the client - EP communication succeed in the first place? Anyway, as I said above I think the ID_KEY_ID may be needed just to differentiate EAP runs. - Section 6.0, I wish there was some notation to show that the inner and outer addresses are different. They are, right? The text is vague since it only talks about the outer addresses being link-local, but does not say anything about the inner addresses. - Section 7.2, ICMP type selectors. I believe this was added to the IPsec documents a couple of months ago. They are not RFCs yet, but neither is PANA, so maybe you could refer to them. And if you do that, you could use more specific SPD entries, as suggested by draft-arkko-icmpv6-ike-effects-01.txt. Its expired, but you can find it here: http://www.arkko.com/publications/draft-arkko-icmpv6-ike-effects-01.txt - Section 9.0, stealing another PaC's traffic. This is interesting. I believe you are talking about the *inner* addresses in the packets, right? Note that if the PAA were responsible for inner IP address assignment, this would not be a problem. But I'm not sure how. Perhaps you could use IKEv2 and its address assignment function, then the EC and PAA would communicate via a AAA protocol to get the address. But this needs more thought. Bernard, do you know what 802.11i says about this subject? It seems that its a similar issue in there. Or is there a need to do some SEND-like address ownership verification? I'm not sure how all the pieces fit together. Is there a PANA document somewhere that describes what the other mechanisms are that you say the PAA can use? Editorial: - I don't see how the NC-DC-PL-DRL discussion fits section 7.2. Move it elsewhere? - s/TUNEL/TUNNEL/g --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 13 12:47:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10415 for ; Thu, 13 Nov 2003 12:47:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLYd-00086X-EX for pana-archive@odin.ietf.org; Thu, 13 Nov 2003 12:47:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADHl3Dv031147 for pana-archive@odin.ietf.org; Thu, 13 Nov 2003 12:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLYd-00086I-7x for pana-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 12:47:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10383 for ; Thu, 13 Nov 2003 12:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLYb-0001sC-00 for pana-web-archive@ietf.org; Thu, 13 Nov 2003 12:47:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKLYb-0001s8-00 for pana-web-archive@ietf.org; Thu, 13 Nov 2003 12:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLYb-00085c-2b; Thu, 13 Nov 2003 12:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLYY-00085L-Rl for pana@optimus.ietf.org; Thu, 13 Nov 2003 12:46:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10377 for ; Thu, 13 Nov 2003 12:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLYX-0001s3-00 for pana@ietf.org; Thu, 13 Nov 2003 12:46:57 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AKLYW-0001rw-00 for pana@ietf.org; Thu, 13 Nov 2003 12:46:56 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 69AC36A908; Thu, 13 Nov 2003 19:46:48 +0200 (EET) Message-ID: <3FB39F1D.8050901@piuha.net> Date: Thu, 13 Nov 2003 17:11:25 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pana@ietf.org, Mohan Parthasarathy Cc: Bernard Aboba , James Kempf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] comments on draft-ietf-pana-ipsec-00.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have read draft-ietf-pana-ipsec-00.txt, and I have a few comments. Apologies if this has been discussed before, I was unable to participate the WG session due to other commitments. Here are the comments: - Section 3.0, bullet 3. This document appears to assume that the IPv6 node has a single address. What about RFC 3041 etc? - Section 4.0, Session ID. I'm glad that the document uses a session ID -- those are indeed needed, as it is possible that more than one EAP session was run, and we need to know where to refer to. However, I still have one problem with this. The problem is that it is not enough to use the Session ID as a part of the IKE pre-shared secret. It is also necessary to carry the session id information in IKE so that the two peers know which key to use. How do you intend to do that? The usual IKE payloads don't appear to carry this information, though it might be that ID_KEY_ID identity type might be usable. (The IKEv1 documents appear to imply that this type is normally used for vendor specific identification.) Or perhaps a new IKE identity type is needed. - Section 5.0, manual keying comment. It seems inappropriate. The purpose of PANA is to do an auth and then use those keys to protect traffic. If manual keys were used in IPsec, those would not be linked to the authentication, so it does not seem like a valid combination. - Section 5.0, main mode. I think the IP addresses are apparent from the packets themselves, but the session ID would have to be transported (perhaps in the identity payload) to distinguish possibly different EAP runs that you had done before. However, this seems problematic, as IKEv1 pre-shared secret mode does not allow the transport of the identity before the identity needs to be known. Are you relying on IKEv2, or would you have to resort to the use of aggressive mode only? - Section 5.0, aggressive mode. I don't understand what the issue with link-locals is. If the link-local addresses were not unique, how would the client - EP communication succeed in the first place? Anyway, as I said above I think the ID_KEY_ID may be needed just to differentiate EAP runs. - Section 6.0, I wish there was some notation to show that the inner and outer addresses are different. They are, right? The text is vague since it only talks about the outer addresses being link-local, but does not say anything about the inner addresses. - Section 7.2, ICMP type selectors. I believe this was added to the IPsec documents a couple of months ago. They are not RFCs yet, but neither is PANA, so maybe you could refer to them. And if you do that, you could use more specific SPD entries, as suggested by draft-arkko-icmpv6-ike-effects-01.txt. Its expired, but you can find it here: http://www.arkko.com/publications/draft-arkko-icmpv6-ike-effects-01.txt - Section 9.0, stealing another PaC's traffic. This is interesting. I believe you are talking about the *inner* addresses in the packets, right? Note that if the PAA were responsible for inner IP address assignment, this would not be a problem. But I'm not sure how. Perhaps you could use IKEv2 and its address assignment function, then the EC and PAA would communicate via a AAA protocol to get the address. But this needs more thought. Bernard, do you know what 802.11i says about this subject? It seems that its a similar issue in there. Or is there a need to do some SEND-like address ownership verification? I'm not sure how all the pieces fit together. Is there a PANA document somewhere that describes what the other mechanisms are that you say the PAA can use? Editorial: - I don't see how the NC-DC-PL-DRL discussion fits section 7.2. Move it elsewhere? - s/TUNEL/TUNNEL/g --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 13 15:05:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16285 for ; Thu, 13 Nov 2003 15:05:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNi9-0001A7-BX; Thu, 13 Nov 2003 15:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNhf-00019L-UP for pana@optimus.ietf.org; Thu, 13 Nov 2003 15:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16132 for ; Thu, 13 Nov 2003 15:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNhc-00042D-00 for pana@ietf.org; Thu, 13 Nov 2003 15:04:28 -0500 Received: from smtp801.mail.sc5.yahoo.com ([66.163.168.180]) by ietf-mx with smtp (Exim 4.12) id 1AKNhZ-00041w-00 for pana@ietf.org; Thu, 13 Nov 2003 15:04:25 -0500 Received: from dyn135-203.ietf58.ietf.org (HELO adithya) (mohanp@sbcglobal.net@130.129.135.203 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 13 Nov 2003 20:04:11 -0000 Message-ID: <002d01c3aa21$4e175320$cb878182@adithya> From: "Mohan Parthasarathy" To: , , "Mohan Parthasarathy" Cc: "Bernard Aboba" , "James Kempf" References: <3FB39F1D.8050901@piuha.net> Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt Date: Thu, 13 Nov 2003 12:04:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari, Thanks for your comments. Comments inline.. > > I have read draft-ietf-pana-ipsec-00.txt, and I have a few > comments. Apologies if this has been discussed before, I was > unable to participate the WG session due to other commitments. > > Here are the comments: > > - Section 3.0, bullet 3. This document appears to assume > that the IPv6 node has a single address. What about RFC 3041 > etc? > This is the same problem that we had in Mobile IPv6 i guess. PANA supports device-id AVP which can be used to communicate the RFC3041 address to PAA. As we are not solving the address ownership problem here, this should be okay i guess. See more on this below. > - Section 4.0, Session ID. I'm glad that the document uses > a session ID -- those are indeed needed, as it is possible > that more than one EAP session was run, and we need to know > where to refer to. > > However, I still have one problem with this. The problem > is that it is not enough to use the Session ID as a part > of the IKE pre-shared secret. It is also necessary to > carry the session id information in IKE so that the > two peers know which key to use. > > How do you intend to do that? The usual IKE payloads don't > appear to carry this information, though it might be that > ID_KEY_ID identity type might be usable. (The IKEv1 documents > appear to imply that this type is normally used for vendor > specific identification.) Or perhaps a new IKE identity type > is needed. > I have checked with a few implementors and it is not that uncommon. I heard that cisco VPN software uses this. ID_KEY_ID. As i mentioned else where, ID_KEY_ID is typically used to hide identities in agressive mode by using opaque blobs. Session Id can be seen as opaque blob. > - Section 5.0, manual keying comment. It seems inappropriate. > The purpose of PANA is to do an auth and then use those keys > to protect traffic. If manual keys were used in IPsec, those > would not be linked to the authentication, so it does not seem like > a valid combination. > Okay. > - Section 5.0, main mode. I think the IP addresses are apparent > from the packets themselves, but the session ID would have to > be transported (perhaps in the identity payload) to distinguish > possibly different EAP runs that you had done before. However, > this seems problematic, as IKEv1 pre-shared secret mode does > not allow the transport of the identity before the identity > needs to be known. Are you relying on IKEv2, or would you have > to resort to the use of aggressive mode only? > I am planning to use just the aggressive mode in future versions. > - Section 5.0, aggressive mode. I don't understand what the > issue with link-locals is. If the link-local addresses were > not unique, how would the client - EP communication succeed > in the first place? Anyway, as I said above I think the ID_KEY_ID > may be needed just to differentiate EAP runs. > This issue was brought up by Francis Dupont. And it is more philosophical than technical. I guess as it will go away now, it should not be confusing anymore. > - Section 6.0, I wish there was some notation to show that the > inner and outer addresses are different. They are, right? > The text is vague since it only talks about the outer addresses > being link-local, but does not say anything about the inner > addresses. Yes. For IPv4, it is even more ambiguous intentionally. Up until now, in IPv4, PaC's start off with unspecified address and once the authentication is complete, they configure an address and thus really had one address. So, outer and inner source address would be same. After IETF58 PANA meeting, i think we are not going to use unspecified address anymore. This means, both in IPv4 and IPv6 mode, it will always now start off with link-local address and then acquire a real address /autoconfigure a real address. So, i will clarify this in future document. > > - Section 7.2, ICMP type selectors. I believe this was added > to the IPsec documents a couple of months ago. They are not > RFCs yet, but neither is PANA, so maybe you could refer to them. > Okay. > And if you do that, you could use more specific SPD entries, > as suggested by draft-arkko-icmpv6-ike-effects-01.txt. Its > expired, but you can find it here: > http://www.arkko.com/publications/draft-arkko-icmpv6-ike-effects-01.txt > Thanks. > - Section 9.0, stealing another PaC's traffic. This is interesting. > I believe you are talking about the *inner* addresses in the packets, > right? > Yes. > Note that if the PAA were responsible for inner IP address assignment, > this would not be a problem. But I'm not sure how. Perhaps you could > use IKEv2 and its address assignment function, then the EC and PAA > would communicate via a AAA protocol to get the address. But this > needs more thought. Bernard, do you know what 802.11i says about > this subject? It seems that its a similar issue in there. > Yes, we are having some private discussion on this looking at some possibilities. Following are possible scenarios. Not yet fully analysed. 1) You can do PANA first, followed by DHCP (pana-dhcp-draft), followed by IPsec access control. Thus, when DHCP is used, this can be used to solve the address ownership problem. 2) You can do PANA first, followed by IPsec access control to protect the router discovery part of SEND. > Or is there a need to do some SEND-like address ownership > verification? I'm not sure how all the pieces fit together. Like in 802.11i where there is no mac address ownership, we are not solving IP address ownership here. But possible in some cases as i mention above. I think we can at least document them if needed. > Is there a PANA document somewhere that describes what the > other mechanisms are that you say the PAA can use? > I really had SEND in mind when i wrote this. Since then, we have been thinking of other possibilities. > Editorial: > > - I don't see how the NC-DC-PL-DRL discussion fits section 7.2. > Move it elsewhere? This comment came from Francis. His idea was to describe more from RFC2461's point of view. I will think about this. > > - s/TUNEL/TUNNEL/g > Okay. Thanks mohan > --Jari > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 13 15:05:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16308 for ; Thu, 13 Nov 2003 15:05:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNiE-0001As-2i for pana-archive@odin.ietf.org; Thu, 13 Nov 2003 15:05:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADK568q004514 for pana-archive@odin.ietf.org; Thu, 13 Nov 2003 15:05:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNiD-0001Aj-7P for pana-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 15:05:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16224 for ; Thu, 13 Nov 2003 15:04:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNi9-00043S-00 for pana-web-archive@ietf.org; Thu, 13 Nov 2003 15:05:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKNi9-00043O-00 for pana-web-archive@ietf.org; Thu, 13 Nov 2003 15:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNi9-0001A7-BX; Thu, 13 Nov 2003 15:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNhf-00019L-UP for pana@optimus.ietf.org; Thu, 13 Nov 2003 15:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16132 for ; Thu, 13 Nov 2003 15:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNhc-00042D-00 for pana@ietf.org; Thu, 13 Nov 2003 15:04:28 -0500 Received: from smtp801.mail.sc5.yahoo.com ([66.163.168.180]) by ietf-mx with smtp (Exim 4.12) id 1AKNhZ-00041w-00 for pana@ietf.org; Thu, 13 Nov 2003 15:04:25 -0500 Received: from dyn135-203.ietf58.ietf.org (HELO adithya) (mohanp@sbcglobal.net@130.129.135.203 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 13 Nov 2003 20:04:11 -0000 Message-ID: <002d01c3aa21$4e175320$cb878182@adithya> From: "Mohan Parthasarathy" To: , , "Mohan Parthasarathy" Cc: "Bernard Aboba" , "James Kempf" References: <3FB39F1D.8050901@piuha.net> Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt Date: Thu, 13 Nov 2003 12:04:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari, Thanks for your comments. Comments inline.. > > I have read draft-ietf-pana-ipsec-00.txt, and I have a few > comments. Apologies if this has been discussed before, I was > unable to participate the WG session due to other commitments. > > Here are the comments: > > - Section 3.0, bullet 3. This document appears to assume > that the IPv6 node has a single address. What about RFC 3041 > etc? > This is the same problem that we had in Mobile IPv6 i guess. PANA supports device-id AVP which can be used to communicate the RFC3041 address to PAA. As we are not solving the address ownership problem here, this should be okay i guess. See more on this below. > - Section 4.0, Session ID. I'm glad that the document uses > a session ID -- those are indeed needed, as it is possible > that more than one EAP session was run, and we need to know > where to refer to. > > However, I still have one problem with this. The problem > is that it is not enough to use the Session ID as a part > of the IKE pre-shared secret. It is also necessary to > carry the session id information in IKE so that the > two peers know which key to use. > > How do you intend to do that? The usual IKE payloads don't > appear to carry this information, though it might be that > ID_KEY_ID identity type might be usable. (The IKEv1 documents > appear to imply that this type is normally used for vendor > specific identification.) Or perhaps a new IKE identity type > is needed. > I have checked with a few implementors and it is not that uncommon. I heard that cisco VPN software uses this. ID_KEY_ID. As i mentioned else where, ID_KEY_ID is typically used to hide identities in agressive mode by using opaque blobs. Session Id can be seen as opaque blob. > - Section 5.0, manual keying comment. It seems inappropriate. > The purpose of PANA is to do an auth and then use those keys > to protect traffic. If manual keys were used in IPsec, those > would not be linked to the authentication, so it does not seem like > a valid combination. > Okay. > - Section 5.0, main mode. I think the IP addresses are apparent > from the packets themselves, but the session ID would have to > be transported (perhaps in the identity payload) to distinguish > possibly different EAP runs that you had done before. However, > this seems problematic, as IKEv1 pre-shared secret mode does > not allow the transport of the identity before the identity > needs to be known. Are you relying on IKEv2, or would you have > to resort to the use of aggressive mode only? > I am planning to use just the aggressive mode in future versions. > - Section 5.0, aggressive mode. I don't understand what the > issue with link-locals is. If the link-local addresses were > not unique, how would the client - EP communication succeed > in the first place? Anyway, as I said above I think the ID_KEY_ID > may be needed just to differentiate EAP runs. > This issue was brought up by Francis Dupont. And it is more philosophical than technical. I guess as it will go away now, it should not be confusing anymore. > - Section 6.0, I wish there was some notation to show that the > inner and outer addresses are different. They are, right? > The text is vague since it only talks about the outer addresses > being link-local, but does not say anything about the inner > addresses. Yes. For IPv4, it is even more ambiguous intentionally. Up until now, in IPv4, PaC's start off with unspecified address and once the authentication is complete, they configure an address and thus really had one address. So, outer and inner source address would be same. After IETF58 PANA meeting, i think we are not going to use unspecified address anymore. This means, both in IPv4 and IPv6 mode, it will always now start off with link-local address and then acquire a real address /autoconfigure a real address. So, i will clarify this in future document. > > - Section 7.2, ICMP type selectors. I believe this was added > to the IPsec documents a couple of months ago. They are not > RFCs yet, but neither is PANA, so maybe you could refer to them. > Okay. > And if you do that, you could use more specific SPD entries, > as suggested by draft-arkko-icmpv6-ike-effects-01.txt. Its > expired, but you can find it here: > http://www.arkko.com/publications/draft-arkko-icmpv6-ike-effects-01.txt > Thanks. > - Section 9.0, stealing another PaC's traffic. This is interesting. > I believe you are talking about the *inner* addresses in the packets, > right? > Yes. > Note that if the PAA were responsible for inner IP address assignment, > this would not be a problem. But I'm not sure how. Perhaps you could > use IKEv2 and its address assignment function, then the EC and PAA > would communicate via a AAA protocol to get the address. But this > needs more thought. Bernard, do you know what 802.11i says about > this subject? It seems that its a similar issue in there. > Yes, we are having some private discussion on this looking at some possibilities. Following are possible scenarios. Not yet fully analysed. 1) You can do PANA first, followed by DHCP (pana-dhcp-draft), followed by IPsec access control. Thus, when DHCP is used, this can be used to solve the address ownership problem. 2) You can do PANA first, followed by IPsec access control to protect the router discovery part of SEND. > Or is there a need to do some SEND-like address ownership > verification? I'm not sure how all the pieces fit together. Like in 802.11i where there is no mac address ownership, we are not solving IP address ownership here. But possible in some cases as i mention above. I think we can at least document them if needed. > Is there a PANA document somewhere that describes what the > other mechanisms are that you say the PAA can use? > I really had SEND in mind when i wrote this. Since then, we have been thinking of other possibilities. > Editorial: > > - I don't see how the NC-DC-PL-DRL discussion fits section 7.2. > Move it elsewhere? This comment came from Francis. His idea was to describe more from RFC2461's point of view. I will think about this. > > - s/TUNEL/TUNNEL/g > Okay. Thanks mohan > --Jari > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 14 09:31:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11554 for ; Fri, 14 Nov 2003 09:31:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeyU-0001lc-W3; Fri, 14 Nov 2003 09:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeyI-0001ko-3Z for pana@optimus.ietf.org; Fri, 14 Nov 2003 09:30:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11534 for ; Fri, 14 Nov 2003 09:30:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeyG-0005sd-00 for pana@ietf.org; Fri, 14 Nov 2003 09:30:48 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AKeyF-0005sX-00 for pana@ietf.org; Fri, 14 Nov 2003 09:30:48 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B23466A905; Fri, 14 Nov 2003 16:30:38 +0200 (EET) Message-ID: <3FB47410.9040603@piuha.net> Date: Fri, 14 Nov 2003 08:20:00 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Cc: pana@ietf.org, Mohan Parthasarathy , Bernard Aboba , James Kempf Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt References: <3FB39F1D.8050901@piuha.net> <002d01c3aa21$4e175320$cb878182@adithya> In-Reply-To: <002d01c3aa21$4e175320$cb878182@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Mohan, As I find most of your answers quite satisfactory, I will only comment on some remaining items below: >>- Section 3.0, bullet 3. This document appears to assume >> that the IPv6 node has a single address. What about RFC 3041 >> etc? >> > > This is the same problem that we had in Mobile IPv6 i guess. > PANA supports device-id AVP which can be used to communicate > the RFC3041 address to PAA. As we are not solving the address > ownership problem here, this should be okay i guess. See more > on this below. Hmm... Seems like in the mobile IPv6 case its different. A node chooses to use _one_ fixed address in order to make it possible for others to reach you while you're mobile. In the PANA case the network access scheme on a link forces every node to never have more than one address. But I'm not sure the text is right, maybe it can just be corrected and there is no problem. And I haven't read yet all of your documents. Some sort of a section in one of pana documents should be devoted to addressing. Not sure if one already exists, but I think it is needed. >> Note that if the PAA were responsible for inner IP address assignment, >> this would not be a problem. But I'm not sure how. Perhaps you could >> use IKEv2 and its address assignment function, then the EC and PAA >> would communicate via a AAA protocol to get the address. But this >> needs more thought. Bernard, do you know what 802.11i says about >> this subject? It seems that its a similar issue in there. >> > > Yes, we are having some private discussion on this looking at some > possibilities. Following are possible scenarios. Not yet fully analysed. > > 1) You can do PANA first, followed by DHCP (pana-dhcp-draft), > followed by IPsec access control. Thus, when DHCP is used, > this can be used to solve the address ownership problem. Ok, though the triggers to turn on IPsec may prove interesting. > 2) You can do PANA first, followed by IPsec access control > to protect the router discovery part of SEND. It might be OK even without SEND in this particular case. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 14 09:31:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11569 for ; Fri, 14 Nov 2003 09:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeyZ-0001mb-1J for pana-archive@odin.ietf.org; Fri, 14 Nov 2003 09:31:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEEV7Uk006853 for pana-archive@odin.ietf.org; Fri, 14 Nov 2003 09:31:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeyY-0001mS-Jl for pana-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 09:31:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11538 for ; Fri, 14 Nov 2003 09:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeyW-0005un-00 for pana-web-archive@ietf.org; Fri, 14 Nov 2003 09:31:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKeyW-0005uk-00 for pana-web-archive@ietf.org; Fri, 14 Nov 2003 09:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeyU-0001lc-W3; Fri, 14 Nov 2003 09:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeyI-0001ko-3Z for pana@optimus.ietf.org; Fri, 14 Nov 2003 09:30:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11534 for ; Fri, 14 Nov 2003 09:30:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeyG-0005sd-00 for pana@ietf.org; Fri, 14 Nov 2003 09:30:48 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AKeyF-0005sX-00 for pana@ietf.org; Fri, 14 Nov 2003 09:30:48 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B23466A905; Fri, 14 Nov 2003 16:30:38 +0200 (EET) Message-ID: <3FB47410.9040603@piuha.net> Date: Fri, 14 Nov 2003 08:20:00 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Cc: pana@ietf.org, Mohan Parthasarathy , Bernard Aboba , James Kempf Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt References: <3FB39F1D.8050901@piuha.net> <002d01c3aa21$4e175320$cb878182@adithya> In-Reply-To: <002d01c3aa21$4e175320$cb878182@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Mohan, As I find most of your answers quite satisfactory, I will only comment on some remaining items below: >>- Section 3.0, bullet 3. This document appears to assume >> that the IPv6 node has a single address. What about RFC 3041 >> etc? >> > > This is the same problem that we had in Mobile IPv6 i guess. > PANA supports device-id AVP which can be used to communicate > the RFC3041 address to PAA. As we are not solving the address > ownership problem here, this should be okay i guess. See more > on this below. Hmm... Seems like in the mobile IPv6 case its different. A node chooses to use _one_ fixed address in order to make it possible for others to reach you while you're mobile. In the PANA case the network access scheme on a link forces every node to never have more than one address. But I'm not sure the text is right, maybe it can just be corrected and there is no problem. And I haven't read yet all of your documents. Some sort of a section in one of pana documents should be devoted to addressing. Not sure if one already exists, but I think it is needed. >> Note that if the PAA were responsible for inner IP address assignment, >> this would not be a problem. But I'm not sure how. Perhaps you could >> use IKEv2 and its address assignment function, then the EC and PAA >> would communicate via a AAA protocol to get the address. But this >> needs more thought. Bernard, do you know what 802.11i says about >> this subject? It seems that its a similar issue in there. >> > > Yes, we are having some private discussion on this looking at some > possibilities. Following are possible scenarios. Not yet fully analysed. > > 1) You can do PANA first, followed by DHCP (pana-dhcp-draft), > followed by IPsec access control. Thus, when DHCP is used, > this can be used to solve the address ownership problem. Ok, though the triggers to turn on IPsec may prove interesting. > 2) You can do PANA first, followed by IPsec access control > to protect the router discovery part of SEND. It might be OK even without SEND in this particular case. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 14 11:00:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17262 for ; Fri, 14 Nov 2003 11:00:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgMb-00014A-Bq; Fri, 14 Nov 2003 11:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgMP-00013d-HU for pana@optimus.ietf.org; Fri, 14 Nov 2003 10:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17207 for ; Fri, 14 Nov 2003 10:59:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgMM-0007ed-00 for pana@ietf.org; Fri, 14 Nov 2003 10:59:46 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AKgML-0007eP-00 for pana@ietf.org; Fri, 14 Nov 2003 10:59:45 -0500 Date: Fri, 14 Nov 2003 09:59:42 -0800 Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt From: Alper Yegin To: , Mohan Parthasarathy CC: , Mohan Parthasarathy , Bernard Aboba , James Kempf Message-ID: In-Reply-To: <3FB47410.9040603@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>> - Section 3.0, bullet 3. This document appears to assume >>> that the IPv6 node has a single address. What about RFC 3041 >>> etc? >>> >> >> This is the same problem that we had in Mobile IPv6 i guess. >> PANA supports device-id AVP which can be used to communicate >> the RFC3041 address to PAA. As we are not solving the address >> ownership problem here, this should be okay i guess. See more >> on this below. > > Hmm... Seems like in the mobile IPv6 case its different. A > node chooses to use _one_ fixed address in order to make it > possible for others to reach you while you're mobile. In the > PANA case the network access scheme on a link forces > every node to never have more than one address. When IPsec-based access control is used with IPv6, a link-local address can be used as the tunnel end-point on the PaC. This IP address will appear as the so-called "device ID" of the PaC. EP will allow any packet received from this address given that it passes IPsec processing. The PaC would configure additional IP addresses inside this tunnel. These are the global addresses that are used for end2end data communication. These might be RFC3041 addresses. Configuring new ones will be transparent to PANA. > > But I'm not sure the text is right, maybe it can just > be corrected and there is no problem. And I haven't > read yet all of your documents. Some sort of a > section in one of pana documents should be devoted > to addressing. Not sure if one already exists, but I > think it is needed. I agree. We have "4.7 Device ID Choice" in base draft, but it is insufficient. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 14 11:00:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17280 for ; Fri, 14 Nov 2003 11:00:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgMg-00015Q-3a for pana-archive@odin.ietf.org; Fri, 14 Nov 2003 11:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEG05ox004157 for pana-archive@odin.ietf.org; Fri, 14 Nov 2003 11:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgMd-00014w-Sz for pana-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 11:00:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17220 for ; Fri, 14 Nov 2003 10:59:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgMb-0007er-00 for pana-web-archive@ietf.org; Fri, 14 Nov 2003 11:00:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKgMa-0007eo-00 for pana-web-archive@ietf.org; Fri, 14 Nov 2003 11:00:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgMb-00014A-Bq; Fri, 14 Nov 2003 11:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgMP-00013d-HU for pana@optimus.ietf.org; Fri, 14 Nov 2003 10:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17207 for ; Fri, 14 Nov 2003 10:59:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgMM-0007ed-00 for pana@ietf.org; Fri, 14 Nov 2003 10:59:46 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AKgML-0007eP-00 for pana@ietf.org; Fri, 14 Nov 2003 10:59:45 -0500 Date: Fri, 14 Nov 2003 09:59:42 -0800 Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt From: Alper Yegin To: , Mohan Parthasarathy CC: , Mohan Parthasarathy , Bernard Aboba , James Kempf Message-ID: In-Reply-To: <3FB47410.9040603@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>> - Section 3.0, bullet 3. This document appears to assume >>> that the IPv6 node has a single address. What about RFC 3041 >>> etc? >>> >> >> This is the same problem that we had in Mobile IPv6 i guess. >> PANA supports device-id AVP which can be used to communicate >> the RFC3041 address to PAA. As we are not solving the address >> ownership problem here, this should be okay i guess. See more >> on this below. > > Hmm... Seems like in the mobile IPv6 case its different. A > node chooses to use _one_ fixed address in order to make it > possible for others to reach you while you're mobile. In the > PANA case the network access scheme on a link forces > every node to never have more than one address. When IPsec-based access control is used with IPv6, a link-local address can be used as the tunnel end-point on the PaC. This IP address will appear as the so-called "device ID" of the PaC. EP will allow any packet received from this address given that it passes IPsec processing. The PaC would configure additional IP addresses inside this tunnel. These are the global addresses that are used for end2end data communication. These might be RFC3041 addresses. Configuring new ones will be transparent to PANA. > > But I'm not sure the text is right, maybe it can just > be corrected and there is no problem. And I haven't > read yet all of your documents. Some sort of a > section in one of pana documents should be devoted > to addressing. Not sure if one already exists, but I > think it is needed. I agree. We have "4.7 Device ID Choice" in base draft, but it is insufficient. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 14 11:13:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17962 for ; Fri, 14 Nov 2003 11:13:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgZ8-0002uZ-DZ; Fri, 14 Nov 2003 11:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgYP-0002tF-As for pana@optimus.ietf.org; Fri, 14 Nov 2003 11:12:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17836 for ; Fri, 14 Nov 2003 11:11:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgYO-00003b-00 for pana@ietf.org; Fri, 14 Nov 2003 11:12:12 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AKgYN-00003X-00 for pana@ietf.org; Fri, 14 Nov 2003 11:12:12 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 33AAC6A905; Fri, 14 Nov 2003 18:12:09 +0200 (EET) Message-ID: <3FB4FDD5.7030204@piuha.net> Date: Fri, 14 Nov 2003 18:07:49 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: Mohan Parthasarathy , pana@ietf.org, Mohan Parthasarathy , Bernard Aboba , James Kempf Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>>>- Section 3.0, bullet 3. This document appears to assume >>>> that the IPv6 node has a single address. What about RFC 3041 >>>> etc? >>>> >>> >>>This is the same problem that we had in Mobile IPv6 i guess. >>>PANA supports device-id AVP which can be used to communicate >>>the RFC3041 address to PAA. As we are not solving the address >>>ownership problem here, this should be okay i guess. See more >>>on this below. >> >>Hmm... Seems like in the mobile IPv6 case its different. A >>node chooses to use _one_ fixed address in order to make it >>possible for others to reach you while you're mobile. In the >>PANA case the network access scheme on a link forces >>every node to never have more than one address. > > > When IPsec-based access control is used with IPv6, a link-local address can > be used as the tunnel end-point on the PaC. This IP address will appear as > the so-called "device ID" of the PaC. EP will allow any packet received from > this address given that it passes IPsec processing. > > The PaC would configure additional IP addresses inside this tunnel. These > are the global addresses that are used for end2end data communication. These > might be RFC3041 addresses. Configuring new ones will be transparent to > PANA. This makes sense in the general way, but we need more details. Also, it might be that there are difficult issues in this. For instance, if network access is based on RA/ND, then we have quite a bit of functionality and freedom. But I'm not sure we have that much if we, say, just assign an address through IKEv2. Or maybe I just don't know where that functionality exists. Anyway, I'd rather have the basic IPv6 functionality available somehow, but I'm not sure if you can actually run it through a tunnel. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 14 11:13:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17980 for ; Fri, 14 Nov 2003 11:13:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgZA-0002vG-3F for pana-archive@odin.ietf.org; Fri, 14 Nov 2003 11:13:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEGD0mU011228 for pana-archive@odin.ietf.org; Fri, 14 Nov 2003 11:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgZ9-0002v1-UA for pana-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 11:13:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17913 for ; Fri, 14 Nov 2003 11:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgZ8-00006M-00 for pana-web-archive@ietf.org; Fri, 14 Nov 2003 11:12:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKgZ8-00006J-00 for pana-web-archive@ietf.org; Fri, 14 Nov 2003 11:12:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgZ8-0002uZ-DZ; Fri, 14 Nov 2003 11:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgYP-0002tF-As for pana@optimus.ietf.org; Fri, 14 Nov 2003 11:12:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17836 for ; Fri, 14 Nov 2003 11:11:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgYO-00003b-00 for pana@ietf.org; Fri, 14 Nov 2003 11:12:12 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AKgYN-00003X-00 for pana@ietf.org; Fri, 14 Nov 2003 11:12:12 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 33AAC6A905; Fri, 14 Nov 2003 18:12:09 +0200 (EET) Message-ID: <3FB4FDD5.7030204@piuha.net> Date: Fri, 14 Nov 2003 18:07:49 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: Mohan Parthasarathy , pana@ietf.org, Mohan Parthasarathy , Bernard Aboba , James Kempf Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>>>- Section 3.0, bullet 3. This document appears to assume >>>> that the IPv6 node has a single address. What about RFC 3041 >>>> etc? >>>> >>> >>>This is the same problem that we had in Mobile IPv6 i guess. >>>PANA supports device-id AVP which can be used to communicate >>>the RFC3041 address to PAA. As we are not solving the address >>>ownership problem here, this should be okay i guess. See more >>>on this below. >> >>Hmm... Seems like in the mobile IPv6 case its different. A >>node chooses to use _one_ fixed address in order to make it >>possible for others to reach you while you're mobile. In the >>PANA case the network access scheme on a link forces >>every node to never have more than one address. > > > When IPsec-based access control is used with IPv6, a link-local address can > be used as the tunnel end-point on the PaC. This IP address will appear as > the so-called "device ID" of the PaC. EP will allow any packet received from > this address given that it passes IPsec processing. > > The PaC would configure additional IP addresses inside this tunnel. These > are the global addresses that are used for end2end data communication. These > might be RFC3041 addresses. Configuring new ones will be transparent to > PANA. This makes sense in the general way, but we need more details. Also, it might be that there are difficult issues in this. For instance, if network access is based on RA/ND, then we have quite a bit of functionality and freedom. But I'm not sure we have that much if we, say, just assign an address through IKEv2. Or maybe I just don't know where that functionality exists. Anyway, I'd rather have the basic IPv6 functionality available somehow, but I'm not sure if you can actually run it through a tunnel. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sun Nov 16 00:46:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06397 for ; Sun, 16 Nov 2003 00:46:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALFjV-0007IQ-Tn; Sun, 16 Nov 2003 00:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALFjD-0007Hq-Uv for pana@optimus.ietf.org; Sun, 16 Nov 2003 00:45:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06366 for ; Sun, 16 Nov 2003 00:45:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALFjB-0005ns-00 for pana@ietf.org; Sun, 16 Nov 2003 00:45:41 -0500 Received: from smtp804.mail.ukl.yahoo.com ([217.12.12.141]) by ietf-mx with smtp (Exim 4.12) id 1ALFjA-0005nX-00 for pana@ietf.org; Sun, 16 Nov 2003 00:45:40 -0500 Received: from adsl-64-160-53-248.dsl.snfc21.pacbell.net (HELO adithya) (mohanp@sbcglobal.net@64.160.53.248 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 16 Nov 2003 05:45:09 -0000 Message-ID: <00a501c3ac04$cdc19b50$6401a8c0@adithya> From: "Mohan Parthasarathy" To: Cc: , "Mohan Parthasarathy" , "Bernard Aboba" , "James Kempf" References: <3FB39F1D.8050901@piuha.net> <002d01c3aa21$4e175320$cb878182@adithya> <3FB47410.9040603@piuha.net> Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt Date: Sat, 15 Nov 2003 21:45:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Hello Mohan, > > As I find most of your answers quite satisfactory, I will > only comment on some remaining items below: > > >>- Section 3.0, bullet 3. This document appears to assume > >> that the IPv6 node has a single address. What about RFC 3041 > >> etc? > >> > > > > This is the same problem that we had in Mobile IPv6 i guess. > > PANA supports device-id AVP which can be used to communicate > > the RFC3041 address to PAA. As we are not solving the address > > ownership problem here, this should be okay i guess. See more > > on this below. > > Hmm... Seems like in the mobile IPv6 case its different. A > node chooses to use _one_ fixed address in order to make it > possible for others to reach you while you're mobile. In the > PANA case the network access scheme on a link forces > every node to never have more than one address. > I am not sure i understood all of what you said. Let me try to understand. The way i see it is there is a link-local address over which all packets are tunneled. In the case of IPv6, it does not matter whether the packets sourced by the PaC is with global address or 3041 address. The address of the PANA client needs to be communicated to the EP for setting up proper SPD entries. This can be done by Device-ID AVP. The reason i compared this with Mobile IP is because there is the issue of how the home agent learns of any new home address e.g. 3041 address (part of the new mip6 charter) and also there is the issue of ownership of the address by the MN. > But I'm not sure the text is right, maybe it can just > be corrected and there is no problem. And I haven't > read yet all of your documents. Some sort of a > section in one of pana documents should be devoted > to addressing. Not sure if one already exists, but I > think it is needed. > Yes, explaining the addressing would be a good thing to do i guess. > >> Note that if the PAA were responsible for inner IP address assignment, > >> this would not be a problem. But I'm not sure how. Perhaps you could > >> use IKEv2 and its address assignment function, then the EC and PAA > >> would communicate via a AAA protocol to get the address. But this > >> needs more thought. Bernard, do you know what 802.11i says about > >> this subject? It seems that its a similar issue in there. > >> > > > > Yes, we are having some private discussion on this looking at some > > possibilities. Following are possible scenarios. Not yet fully analysed. > > > > 1) You can do PANA first, followed by DHCP (pana-dhcp-draft), > > followed by IPsec access control. Thus, when DHCP is used, > > this can be used to solve the address ownership problem. > > Ok, though the triggers to turn on IPsec may prove interesting. > I would like to know more of what you have in mind. IPsec is triggered by the SPD entries that are setup at the end of DHCP. Any issues ? > > 2) You can do PANA first, followed by IPsec access control > > to protect the router discovery part of SEND. > > It might be OK even without SEND in this particular case. > I am not sure i undestood this. Could you clarify ? -thanks mohan > --Jari > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sun Nov 16 00:46:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06414 for ; Sun, 16 Nov 2003 00:46:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALFjY-0007JF-AX for pana-archive@odin.ietf.org; Sun, 16 Nov 2003 00:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAG5k4rK028091 for pana-archive@odin.ietf.org; Sun, 16 Nov 2003 00:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALFjY-0007J0-4U for pana-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 00:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06378 for ; Sun, 16 Nov 2003 00:45:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALFjV-0005py-00 for pana-web-archive@ietf.org; Sun, 16 Nov 2003 00:46:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALFjV-0005pv-00 for pana-web-archive@ietf.org; Sun, 16 Nov 2003 00:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALFjV-0007IQ-Tn; Sun, 16 Nov 2003 00:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALFjD-0007Hq-Uv for pana@optimus.ietf.org; Sun, 16 Nov 2003 00:45:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06366 for ; Sun, 16 Nov 2003 00:45:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALFjB-0005ns-00 for pana@ietf.org; Sun, 16 Nov 2003 00:45:41 -0500 Received: from smtp804.mail.ukl.yahoo.com ([217.12.12.141]) by ietf-mx with smtp (Exim 4.12) id 1ALFjA-0005nX-00 for pana@ietf.org; Sun, 16 Nov 2003 00:45:40 -0500 Received: from adsl-64-160-53-248.dsl.snfc21.pacbell.net (HELO adithya) (mohanp@sbcglobal.net@64.160.53.248 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 16 Nov 2003 05:45:09 -0000 Message-ID: <00a501c3ac04$cdc19b50$6401a8c0@adithya> From: "Mohan Parthasarathy" To: Cc: , "Mohan Parthasarathy" , "Bernard Aboba" , "James Kempf" References: <3FB39F1D.8050901@piuha.net> <002d01c3aa21$4e175320$cb878182@adithya> <3FB47410.9040603@piuha.net> Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt Date: Sat, 15 Nov 2003 21:45:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Hello Mohan, > > As I find most of your answers quite satisfactory, I will > only comment on some remaining items below: > > >>- Section 3.0, bullet 3. This document appears to assume > >> that the IPv6 node has a single address. What about RFC 3041 > >> etc? > >> > > > > This is the same problem that we had in Mobile IPv6 i guess. > > PANA supports device-id AVP which can be used to communicate > > the RFC3041 address to PAA. As we are not solving the address > > ownership problem here, this should be okay i guess. See more > > on this below. > > Hmm... Seems like in the mobile IPv6 case its different. A > node chooses to use _one_ fixed address in order to make it > possible for others to reach you while you're mobile. In the > PANA case the network access scheme on a link forces > every node to never have more than one address. > I am not sure i understood all of what you said. Let me try to understand. The way i see it is there is a link-local address over which all packets are tunneled. In the case of IPv6, it does not matter whether the packets sourced by the PaC is with global address or 3041 address. The address of the PANA client needs to be communicated to the EP for setting up proper SPD entries. This can be done by Device-ID AVP. The reason i compared this with Mobile IP is because there is the issue of how the home agent learns of any new home address e.g. 3041 address (part of the new mip6 charter) and also there is the issue of ownership of the address by the MN. > But I'm not sure the text is right, maybe it can just > be corrected and there is no problem. And I haven't > read yet all of your documents. Some sort of a > section in one of pana documents should be devoted > to addressing. Not sure if one already exists, but I > think it is needed. > Yes, explaining the addressing would be a good thing to do i guess. > >> Note that if the PAA were responsible for inner IP address assignment, > >> this would not be a problem. But I'm not sure how. Perhaps you could > >> use IKEv2 and its address assignment function, then the EC and PAA > >> would communicate via a AAA protocol to get the address. But this > >> needs more thought. Bernard, do you know what 802.11i says about > >> this subject? It seems that its a similar issue in there. > >> > > > > Yes, we are having some private discussion on this looking at some > > possibilities. Following are possible scenarios. Not yet fully analysed. > > > > 1) You can do PANA first, followed by DHCP (pana-dhcp-draft), > > followed by IPsec access control. Thus, when DHCP is used, > > this can be used to solve the address ownership problem. > > Ok, though the triggers to turn on IPsec may prove interesting. > I would like to know more of what you have in mind. IPsec is triggered by the SPD entries that are setup at the end of DHCP. Any issues ? > > 2) You can do PANA first, followed by IPsec access control > > to protect the router discovery part of SEND. > > It might be OK even without SEND in this particular case. > I am not sure i undestood this. Could you clarify ? -thanks mohan > --Jari > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 18 19:07:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26980 for ; Tue, 18 Nov 2003 19:07:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFs5-0002XW-GD; Tue, 18 Nov 2003 19:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFrO-0002Wa-TE for pana@optimus.ietf.org; Tue, 18 Nov 2003 19:06:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26925 for ; Tue, 18 Nov 2003 19:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMFrL-0003DY-00 for pana@ietf.org; Tue, 18 Nov 2003 19:06:15 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMFrK-0003DT-00 for pana@ietf.org; Tue, 18 Nov 2003 19:06:14 -0500 Date: Tue, 18 Nov 2003 16:07:12 -0800 Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt From: Alper Yegin To: CC: Mohan Parthasarathy , , Mohan Parthasarathy , Bernard Aboba , James Kempf Message-ID: In-Reply-To: <3FB4FDD5.7030204@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> When IPsec-based access control is used with IPv6, a link-local address can >> be used as the tunnel end-point on the PaC. This IP address will appear as >> the so-called "device ID" of the PaC. EP will allow any packet received from >> this address given that it passes IPsec processing. >> >> The PaC would configure additional IP addresses inside this tunnel. These >> are the global addresses that are used for end2end data communication. These >> might be RFC3041 addresses. Configuring new ones will be transparent to >> PANA. > > This makes sense in the general way, but we need more details. Also, > it might be that there are difficult issues in this. For instance, > if network access is based on RA/ND, then we have quite a bit of > functionality and freedom. But I'm not sure we have that much if > we, say, just assign an address through IKEv2. Or maybe I just > don't know where that functionality exists. Anyway, I'd rather > have the basic IPv6 functionality available somehow, but I'm not > sure if you can actually run it through a tunnel. You mean configuring DHCP-based or autoconfigured IPv6 addresses inside an IPv6 tunnel might have issues? Any specific issues in your mind? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 18 19:07:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26995 for ; Tue, 18 Nov 2003 19:07:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFs8-0002Yl-C0 for pana-archive@odin.ietf.org; Tue, 18 Nov 2003 19:07:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ074Oq009838 for pana-archive@odin.ietf.org; Tue, 18 Nov 2003 19:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFs7-0002YS-Pd for pana-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 19:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26966 for ; Tue, 18 Nov 2003 19:06:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMFs4-0003EZ-00 for pana-web-archive@ietf.org; Tue, 18 Nov 2003 19:07:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMFs4-0003EU-00 for pana-web-archive@ietf.org; Tue, 18 Nov 2003 19:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFs5-0002XW-GD; Tue, 18 Nov 2003 19:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFrO-0002Wa-TE for pana@optimus.ietf.org; Tue, 18 Nov 2003 19:06:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26925 for ; Tue, 18 Nov 2003 19:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMFrL-0003DY-00 for pana@ietf.org; Tue, 18 Nov 2003 19:06:15 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMFrK-0003DT-00 for pana@ietf.org; Tue, 18 Nov 2003 19:06:14 -0500 Date: Tue, 18 Nov 2003 16:07:12 -0800 Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt From: Alper Yegin To: CC: Mohan Parthasarathy , , Mohan Parthasarathy , Bernard Aboba , James Kempf Message-ID: In-Reply-To: <3FB4FDD5.7030204@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> When IPsec-based access control is used with IPv6, a link-local address can >> be used as the tunnel end-point on the PaC. This IP address will appear as >> the so-called "device ID" of the PaC. EP will allow any packet received from >> this address given that it passes IPsec processing. >> >> The PaC would configure additional IP addresses inside this tunnel. These >> are the global addresses that are used for end2end data communication. These >> might be RFC3041 addresses. Configuring new ones will be transparent to >> PANA. > > This makes sense in the general way, but we need more details. Also, > it might be that there are difficult issues in this. For instance, > if network access is based on RA/ND, then we have quite a bit of > functionality and freedom. But I'm not sure we have that much if > we, say, just assign an address through IKEv2. Or maybe I just > don't know where that functionality exists. Anyway, I'd rather > have the basic IPv6 functionality available somehow, but I'm not > sure if you can actually run it through a tunnel. You mean configuring DHCP-based or autoconfigured IPv6 addresses inside an IPv6 tunnel might have issues? Any specific issues in your mind? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 18 20:18:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29717 for ; Tue, 18 Nov 2003 20:18:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGym-0006UB-Tm; Tue, 18 Nov 2003 20:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGxp-0006TU-3I for pana@optimus.ietf.org; Tue, 18 Nov 2003 20:17:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29660 for ; Tue, 18 Nov 2003 20:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMGxm-0004fm-00 for pana@ietf.org; Tue, 18 Nov 2003 20:16:58 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMGxm-0004fj-00 for pana@ietf.org; Tue, 18 Nov 2003 20:16:58 -0500 Date: Tue, 18 Nov 2003 17:17:57 -0800 From: Alper Yegin To: CC: Jari Arkko , Bernard Aboba , James Kempf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] IP address configuration Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here is an attempt to describe how IP addresses are configured in various PANA scenarios.. - Physically secured links: The device ID can be set to the MAC address of the PaC. Hence the IP address of the PaC has no significance for the PANA session or the access control mechnanism. If we don't allow unspecified IP addresses in the PANA design, than a pre-PANA IP address should be configured via address autoconfig or DHCP before running PANA. If the IP address assignment relies on the identity of the PaC, a post-PANA address will be configured after PANA authentication. A statically configured IP address on the PaC can be used as both pre-PANA and post-PANA address. If pre-PANA address is not the globally routable (ultimate) IP address, then the PaC should be prompted to obtain a new (post-PANA) IP address upon successful PANA authentication. PANA-Bind-Request message can carry the relevant indication. [If pre-PANA address is the same as post-PANA address, then we are done.] If IPv6 is used, the pre-PANA address would be a link-local address. The post-PANA address might be configured via DHCP or address autoconfiguration. Both pre-PANA address and post-PANA address can be retained by the PaC at the same time. If IPv4 is used, the pre-PANA address should be released before configuring the post-PANA address. Post-PANA address would be obtained from DHCP in that case. - L2-ciphered before PANA: Same as physically secured links. - L2-ciphered after PANA: Same as physically secured links. - IPsec-based access control after PANA: This time IP addresses are used as the device ID and they have significance for the access control and PANA session. Pre-PANA addresses are configured the same way as before (via DHCP or stateless address autoconfiguration). IPv6 link-locals used for IPv6, and IPv4 link-local or DHCP for IPv4. A pre-PANA address is bound to the PaC as the device ID. It will be used as the local end-point of the IPsec tunnel to the EP. If PaC needs to configure a post-PANA address, this should be indicated by the PANA-Bind-Request message. PaC should attempt this configuration inside the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address autoconfiguration or DHCP can be used. Both pre-PANA and post-PANA addresses are used by the PaC at the same time, though post-PANA addresses only appear inside the tunnel. A post-PANA address has no significance for the PANA session or access control. If pre-PANA and post-PANA addresses are the same, they will be used both inside and outside the tunnel (any issues with IPsec processing?). This can be the case when the client has a static IP address, or the DHCP address assignment does not depend on the client identity. Comments? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 18 20:18:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29732 for ; Tue, 18 Nov 2003 20:18:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGyu-0006V9-EM for pana-archive@odin.ietf.org; Tue, 18 Nov 2003 20:18:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ1I8RM024985 for pana-archive@odin.ietf.org; Tue, 18 Nov 2003 20:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGyu-0006Uu-66 for pana-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 20:18:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29681 for ; Tue, 18 Nov 2003 20:17:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMGyp-0004gs-00 for pana-web-archive@ietf.org; Tue, 18 Nov 2003 20:18:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMGyo-0004gp-00 for pana-web-archive@ietf.org; Tue, 18 Nov 2003 20:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGym-0006UB-Tm; Tue, 18 Nov 2003 20:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGxp-0006TU-3I for pana@optimus.ietf.org; Tue, 18 Nov 2003 20:17:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29660 for ; Tue, 18 Nov 2003 20:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMGxm-0004fm-00 for pana@ietf.org; Tue, 18 Nov 2003 20:16:58 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMGxm-0004fj-00 for pana@ietf.org; Tue, 18 Nov 2003 20:16:58 -0500 Date: Tue, 18 Nov 2003 17:17:57 -0800 From: Alper Yegin To: CC: Jari Arkko , Bernard Aboba , James Kempf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] IP address configuration Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is an attempt to describe how IP addresses are configured in various PANA scenarios.. - Physically secured links: The device ID can be set to the MAC address of the PaC. Hence the IP address of the PaC has no significance for the PANA session or the access control mechnanism. If we don't allow unspecified IP addresses in the PANA design, than a pre-PANA IP address should be configured via address autoconfig or DHCP before running PANA. If the IP address assignment relies on the identity of the PaC, a post-PANA address will be configured after PANA authentication. A statically configured IP address on the PaC can be used as both pre-PANA and post-PANA address. If pre-PANA address is not the globally routable (ultimate) IP address, then the PaC should be prompted to obtain a new (post-PANA) IP address upon successful PANA authentication. PANA-Bind-Request message can carry the relevant indication. [If pre-PANA address is the same as post-PANA address, then we are done.] If IPv6 is used, the pre-PANA address would be a link-local address. The post-PANA address might be configured via DHCP or address autoconfiguration. Both pre-PANA address and post-PANA address can be retained by the PaC at the same time. If IPv4 is used, the pre-PANA address should be released before configuring the post-PANA address. Post-PANA address would be obtained from DHCP in that case. - L2-ciphered before PANA: Same as physically secured links. - L2-ciphered after PANA: Same as physically secured links. - IPsec-based access control after PANA: This time IP addresses are used as the device ID and they have significance for the access control and PANA session. Pre-PANA addresses are configured the same way as before (via DHCP or stateless address autoconfiguration). IPv6 link-locals used for IPv6, and IPv4 link-local or DHCP for IPv4. A pre-PANA address is bound to the PaC as the device ID. It will be used as the local end-point of the IPsec tunnel to the EP. If PaC needs to configure a post-PANA address, this should be indicated by the PANA-Bind-Request message. PaC should attempt this configuration inside the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address autoconfiguration or DHCP can be used. Both pre-PANA and post-PANA addresses are used by the PaC at the same time, though post-PANA addresses only appear inside the tunnel. A post-PANA address has no significance for the PANA session or access control. If pre-PANA and post-PANA addresses are the same, they will be used both inside and outside the tunnel (any issues with IPsec processing?). This can be the case when the client has a static IP address, or the DHCP address assignment does not depend on the client identity. Comments? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 18 21:44:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02481 for ; Tue, 18 Nov 2003 21:44:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMIK1-00024J-HX; Tue, 18 Nov 2003 21:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMIJX-00023v-D6 for pana@optimus.ietf.org; Tue, 18 Nov 2003 21:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02450 for ; Tue, 18 Nov 2003 21:43:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMIJU-0005wY-00 for pana@ietf.org; Tue, 18 Nov 2003 21:43:28 -0500 Received: from breeze.research.telcordia.com ([192.4.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AMIJP-0005vw-00 for pana@ietf.org; Tue, 18 Nov 2003 21:43:23 -0500 Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.12.8/8.12.1) with ESMTP id hAJ2gen6005382; Tue, 18 Nov 2003 21:42:40 -0500 (EST) Message-Id: <200311190242.hAJ2gen6005382@breeze.research.telcordia.com> To: Alper Yegin cc: pana@ietf.org, Jari Arkko , Bernard Aboba , James Kempf Subject: Re: [Pana] IP address configuration In-reply-to: Your message of "Tue, 18 Nov 2003 17:17:57 PST." Date: Tue, 18 Nov 2003 21:42:40 -0500 From: Ashutosh Dutta Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > If we don't allow unspecified IP addresses in the PANA design, than a > pre-PANA IP address should be configured via address autoconfig or DHCP > before running PANA. If the IP address assignment relies on the identity of > the PaC, a post-PANA address will be configured after PANA authentication. A > statically configured IP address on the PaC can be used as both pre-PANA and > post-PANA address. If a Pac is configured to use DHCP as a means for address configuration, then Pre-PANA and post-PANA address would always be same, PaC will be talking to the same DHCP server in the subnet for address configuration. Things may be different if one configures Pac to have a static address as Pre-PANA and then uses DHCP as the post-Pana. But then how do you toggle between static and DHCP in the network configuration file. Things do not work that well if you have have BOOTPROTO set to both static and DHCP. > If pre-PANA address is not the globally routable (ultimate) IP address, then > the PaC should be prompted to obtain a new (post-PANA) IP address upon > successful PANA authentication. PANA-Bind-Request message can carry the > relevant indication. [If pre-PANA address is the same as post-PANA address, > then we are done.] Who is going to provide this globally routable IP address, I assume Pac is behind a NAT here, and the pre-PANA address it has obtained is from a DHCP server within the NAT. > If IPv6 is used, the pre-PANA address would be a link-local address. The > post-PANA address might be configured via DHCP or address autoconfiguration. > Both pre-PANA address and post-PANA address can be retained by the PaC at > the same time. What is the compexity of having both addresses active at the same time on the same interface of Pac. > A pre-PANA address is bound to the PaC as the device ID. It will be used as > the local end-point of the IPsec tunnel to the EP. > > If PaC needs to configure a post-PANA address, this should be indicated by > the PANA-Bind-Request message. PaC should attempt this configuration inside > the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address > autoconfiguration or DHCP can be used. How well DHCP messages work over an IPSEC tunnel, in the above case? Thanks Ashutosh _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 18 21:44:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02496 for ; Tue, 18 Nov 2003 21:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMIK4-000256-5F for pana-archive@odin.ietf.org; Tue, 18 Nov 2003 21:44:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ2i40W007994 for pana-archive@odin.ietf.org; Tue, 18 Nov 2003 21:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMIK3-00024r-Vs for pana-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 21:44:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02457 for ; Tue, 18 Nov 2003 21:43:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMIK1-0005wv-00 for pana-web-archive@ietf.org; Tue, 18 Nov 2003 21:44:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMIK0-0005ws-00 for pana-web-archive@ietf.org; Tue, 18 Nov 2003 21:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMIK1-00024J-HX; Tue, 18 Nov 2003 21:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMIJX-00023v-D6 for pana@optimus.ietf.org; Tue, 18 Nov 2003 21:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02450 for ; Tue, 18 Nov 2003 21:43:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMIJU-0005wY-00 for pana@ietf.org; Tue, 18 Nov 2003 21:43:28 -0500 Received: from breeze.research.telcordia.com ([192.4.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AMIJP-0005vw-00 for pana@ietf.org; Tue, 18 Nov 2003 21:43:23 -0500 Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.12.8/8.12.1) with ESMTP id hAJ2gen6005382; Tue, 18 Nov 2003 21:42:40 -0500 (EST) Message-Id: <200311190242.hAJ2gen6005382@breeze.research.telcordia.com> To: Alper Yegin cc: pana@ietf.org, Jari Arkko , Bernard Aboba , James Kempf Subject: Re: [Pana] IP address configuration In-reply-to: Your message of "Tue, 18 Nov 2003 17:17:57 PST." Date: Tue, 18 Nov 2003 21:42:40 -0500 From: Ashutosh Dutta Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > If we don't allow unspecified IP addresses in the PANA design, than a > pre-PANA IP address should be configured via address autoconfig or DHCP > before running PANA. If the IP address assignment relies on the identity of > the PaC, a post-PANA address will be configured after PANA authentication. A > statically configured IP address on the PaC can be used as both pre-PANA and > post-PANA address. If a Pac is configured to use DHCP as a means for address configuration, then Pre-PANA and post-PANA address would always be same, PaC will be talking to the same DHCP server in the subnet for address configuration. Things may be different if one configures Pac to have a static address as Pre-PANA and then uses DHCP as the post-Pana. But then how do you toggle between static and DHCP in the network configuration file. Things do not work that well if you have have BOOTPROTO set to both static and DHCP. > If pre-PANA address is not the globally routable (ultimate) IP address, then > the PaC should be prompted to obtain a new (post-PANA) IP address upon > successful PANA authentication. PANA-Bind-Request message can carry the > relevant indication. [If pre-PANA address is the same as post-PANA address, > then we are done.] Who is going to provide this globally routable IP address, I assume Pac is behind a NAT here, and the pre-PANA address it has obtained is from a DHCP server within the NAT. > If IPv6 is used, the pre-PANA address would be a link-local address. The > post-PANA address might be configured via DHCP or address autoconfiguration. > Both pre-PANA address and post-PANA address can be retained by the PaC at > the same time. What is the compexity of having both addresses active at the same time on the same interface of Pac. > A pre-PANA address is bound to the PaC as the device ID. It will be used as > the local end-point of the IPsec tunnel to the EP. > > If PaC needs to configure a post-PANA address, this should be indicated by > the PANA-Bind-Request message. PaC should attempt this configuration inside > the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address > autoconfiguration or DHCP can be used. How well DHCP messages work over an IPSEC tunnel, in the above case? Thanks Ashutosh _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 18 23:40:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06078 for ; Tue, 18 Nov 2003 23:40:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMK8J-00076u-63; Tue, 18 Nov 2003 23:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMK8C-00076E-E9 for pana@optimus.ietf.org; Tue, 18 Nov 2003 23:39:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06046 for ; Tue, 18 Nov 2003 23:39:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMK8A-0007gE-00 for pana@ietf.org; Tue, 18 Nov 2003 23:39:54 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMK89-0007gB-00 for pana@ietf.org; Tue, 18 Nov 2003 23:39:53 -0500 Date: Tue, 18 Nov 2003 20:40:50 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: Ashutosh Dutta CC: , Jari Arkko , Bernard Aboba , James Kempf Message-ID: In-Reply-To: <200311190242.hAJ2gen6005382@breeze.research.telcordia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 11/18/03 6:42 PM, "Ashutosh Dutta" wrote: >> >> If we don't allow unspecified IP addresses in the PANA design, than a >> pre-PANA IP address should be configured via address autoconfig or DHCP >> before running PANA. If the IP address assignment relies on the identity of >> the PaC, a post-PANA address will be configured after PANA authentication. A >> statically configured IP address on the PaC can be used as both pre-PANA and >> post-PANA address. > > > If a Pac is configured to use DHCP as a means for address > configuration, then Pre-PANA and post-PANA address would always be > same, PaC will be talking to the same DHCP server in the subnet for > address configuration. Not necessarily. Pre-PANA address might be allocated from the address pool of the NAP, whereas post-PANA address might be allocated from the ISP's pool. > Things may be different if one configures Pac > to have a static address as Pre-PANA and then uses DHCP as the > post-Pana. But then how do you toggle between static and DHCP in the > network configuration file. Things do not work that well if you have > have BOOTPROTO set to both static and DHCP. If a PaC is already configured with a static IP address, it does not have to configure another one via DHCP after PANA. The same IP address can be used before and after PANA. >> If pre-PANA address is not the globally routable (ultimate) IP address, then >> the PaC should be prompted to obtain a new (post-PANA) IP address upon >> successful PANA authentication. PANA-Bind-Request message can carry the >> relevant indication. [If pre-PANA address is the same as post-PANA address, >> then we are done.] > > Who is going to provide this globally routable IP address, I assume > Pac is behind a NAT here, and the pre-PANA address it has obtained is > from a DHCP server within the NAT. I shouldn't have said "globally routable". Yes, you are right, it can also be a RFC1918 address. I meant to refer to the address that will be used for data communication after the client is authorized to access the network. > >> If IPv6 is used, the pre-PANA address would be a link-local address. The >> post-PANA address might be configured via DHCP or address autoconfiguration. >> Both pre-PANA address and post-PANA address can be retained by the PaC at >> the same time. > > What is the compexity of having both addresses active at the same time > on the same interface of Pac. It's part of the base IPv6 design to have a link-local and global IPv6 address at the same time. > > >> A pre-PANA address is bound to the PaC as the device ID. It will be used as >> the local end-point of the IPsec tunnel to the EP. >> >> If PaC needs to configure a post-PANA address, this should be indicated by >> the PANA-Bind-Request message. PaC should attempt this configuration inside >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address >> autoconfiguration or DHCP can be used. > > How well DHCP messages work over an IPSEC tunnel, in the above case? > Alper > Thanks > Ashutosh > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 18 23:40:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06093 for ; Tue, 18 Nov 2003 23:40:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMK8P-00077j-TF for pana-archive@odin.ietf.org; Tue, 18 Nov 2003 23:40:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ4e977027377 for pana-archive@odin.ietf.org; Tue, 18 Nov 2003 23:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMK8O-00077U-NE for pana-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 23:40:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06061 for ; Tue, 18 Nov 2003 23:39:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMK8M-0007gZ-00 for pana-web-archive@ietf.org; Tue, 18 Nov 2003 23:40:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMK8M-0007gW-00 for pana-web-archive@ietf.org; Tue, 18 Nov 2003 23:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMK8J-00076u-63; Tue, 18 Nov 2003 23:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMK8C-00076E-E9 for pana@optimus.ietf.org; Tue, 18 Nov 2003 23:39:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06046 for ; Tue, 18 Nov 2003 23:39:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMK8A-0007gE-00 for pana@ietf.org; Tue, 18 Nov 2003 23:39:54 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMK89-0007gB-00 for pana@ietf.org; Tue, 18 Nov 2003 23:39:53 -0500 Date: Tue, 18 Nov 2003 20:40:50 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: Ashutosh Dutta CC: , Jari Arkko , Bernard Aboba , James Kempf Message-ID: In-Reply-To: <200311190242.hAJ2gen6005382@breeze.research.telcordia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11/18/03 6:42 PM, "Ashutosh Dutta" wrote: >> >> If we don't allow unspecified IP addresses in the PANA design, than a >> pre-PANA IP address should be configured via address autoconfig or DHCP >> before running PANA. If the IP address assignment relies on the identity of >> the PaC, a post-PANA address will be configured after PANA authentication. A >> statically configured IP address on the PaC can be used as both pre-PANA and >> post-PANA address. > > > If a Pac is configured to use DHCP as a means for address > configuration, then Pre-PANA and post-PANA address would always be > same, PaC will be talking to the same DHCP server in the subnet for > address configuration. Not necessarily. Pre-PANA address might be allocated from the address pool of the NAP, whereas post-PANA address might be allocated from the ISP's pool. > Things may be different if one configures Pac > to have a static address as Pre-PANA and then uses DHCP as the > post-Pana. But then how do you toggle between static and DHCP in the > network configuration file. Things do not work that well if you have > have BOOTPROTO set to both static and DHCP. If a PaC is already configured with a static IP address, it does not have to configure another one via DHCP after PANA. The same IP address can be used before and after PANA. >> If pre-PANA address is not the globally routable (ultimate) IP address, then >> the PaC should be prompted to obtain a new (post-PANA) IP address upon >> successful PANA authentication. PANA-Bind-Request message can carry the >> relevant indication. [If pre-PANA address is the same as post-PANA address, >> then we are done.] > > Who is going to provide this globally routable IP address, I assume > Pac is behind a NAT here, and the pre-PANA address it has obtained is > from a DHCP server within the NAT. I shouldn't have said "globally routable". Yes, you are right, it can also be a RFC1918 address. I meant to refer to the address that will be used for data communication after the client is authorized to access the network. > >> If IPv6 is used, the pre-PANA address would be a link-local address. The >> post-PANA address might be configured via DHCP or address autoconfiguration. >> Both pre-PANA address and post-PANA address can be retained by the PaC at >> the same time. > > What is the compexity of having both addresses active at the same time > on the same interface of Pac. It's part of the base IPv6 design to have a link-local and global IPv6 address at the same time. > > >> A pre-PANA address is bound to the PaC as the device ID. It will be used as >> the local end-point of the IPsec tunnel to the EP. >> >> If PaC needs to configure a post-PANA address, this should be indicated by >> the PANA-Bind-Request message. PaC should attempt this configuration inside >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address >> autoconfiguration or DHCP can be used. > > How well DHCP messages work over an IPSEC tunnel, in the above case? > Alper > Thanks > Ashutosh > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Nov 19 05:23:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11048 for ; Wed, 19 Nov 2003 05:23:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPUD-0008LQ-Ul; Wed, 19 Nov 2003 05:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPTw-0008Kf-UW for pana@optimus.ietf.org; Wed, 19 Nov 2003 05:22:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11012 for ; Wed, 19 Nov 2003 05:22:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMPTt-0004Gy-00 for pana@ietf.org; Wed, 19 Nov 2003 05:22:41 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMPTs-0004Gv-00 for pana@ietf.org; Wed, 19 Nov 2003 05:22:41 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 305F26A90B; Wed, 19 Nov 2003 12:22:40 +0200 (EET) Message-ID: <3FBB436E.3000105@piuha.net> Date: Wed, 19 Nov 2003 12:18:22 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: Mohan Parthasarathy , pana@ietf.org, Mohan Parthasarathy , Bernard Aboba Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>This makes sense in the general way, but we need more details. Also, >>it might be that there are difficult issues in this. For instance, >>if network access is based on RA/ND, then we have quite a bit of >>functionality and freedom. But I'm not sure we have that much if >>we, say, just assign an address through IKEv2. Or maybe I just >>don't know where that functionality exists. Anyway, I'd rather >>have the basic IPv6 functionality available somehow, but I'm not >>sure if you can actually run it through a tunnel. > > You mean configuring DHCP-based or autoconfigured IPv6 addresses inside an > IPv6 tunnel might have issues? Any specific issues in your mind? It could be that I just don't know enough about the subject (please educate me), but has the use of ND over a tunnel been defined somewhere? And what if you run things over an IPsec tunnel, do you have to use the IKEv2 facilities only for address assignment, or can you also do DHCP and ND? --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Nov 19 05:23:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11063 for ; Wed, 19 Nov 2003 05:23:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPUI-0008MP-D7 for pana-archive@odin.ietf.org; Wed, 19 Nov 2003 05:23:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJAN6x3032136 for pana-archive@odin.ietf.org; Wed, 19 Nov 2003 05:23:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPUI-0008MF-73 for pana-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 05:23:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11024 for ; Wed, 19 Nov 2003 05:22:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMPUE-0004HG-00 for pana-web-archive@ietf.org; Wed, 19 Nov 2003 05:23:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMPUE-0004HD-00 for pana-web-archive@ietf.org; Wed, 19 Nov 2003 05:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPUD-0008LQ-Ul; Wed, 19 Nov 2003 05:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPTw-0008Kf-UW for pana@optimus.ietf.org; Wed, 19 Nov 2003 05:22:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11012 for ; Wed, 19 Nov 2003 05:22:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMPTt-0004Gy-00 for pana@ietf.org; Wed, 19 Nov 2003 05:22:41 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMPTs-0004Gv-00 for pana@ietf.org; Wed, 19 Nov 2003 05:22:41 -0500 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 305F26A90B; Wed, 19 Nov 2003 12:22:40 +0200 (EET) Message-ID: <3FBB436E.3000105@piuha.net> Date: Wed, 19 Nov 2003 12:18:22 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: Mohan Parthasarathy , pana@ietf.org, Mohan Parthasarathy , Bernard Aboba Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>This makes sense in the general way, but we need more details. Also, >>it might be that there are difficult issues in this. For instance, >>if network access is based on RA/ND, then we have quite a bit of >>functionality and freedom. But I'm not sure we have that much if >>we, say, just assign an address through IKEv2. Or maybe I just >>don't know where that functionality exists. Anyway, I'd rather >>have the basic IPv6 functionality available somehow, but I'm not >>sure if you can actually run it through a tunnel. > > You mean configuring DHCP-based or autoconfigured IPv6 addresses inside an > IPv6 tunnel might have issues? Any specific issues in your mind? It could be that I just don't know enough about the subject (please educate me), but has the use of ND over a tunnel been defined somewhere? And what if you run things over an IPsec tunnel, do you have to use the IKEv2 facilities only for address assignment, or can you also do DHCP and ND? --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Nov 19 12:27:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28091 for ; Wed, 19 Nov 2003 12:27:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMW6X-00015v-Vh; Wed, 19 Nov 2003 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMW6K-000123-Tj for pana@optimus.ietf.org; Wed, 19 Nov 2003 12:26:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28021 for ; Wed, 19 Nov 2003 12:26:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMW6I-0003yU-00 for pana@ietf.org; Wed, 19 Nov 2003 12:26:46 -0500 Received: from smtp809.mail.sc5.yahoo.com ([66.163.168.188]) by ietf-mx with smtp (Exim 4.12) id 1AMW6H-0003yQ-00 for pana@ietf.org; Wed, 19 Nov 2003 12:26:45 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 19 Nov 2003 17:26:42 -0000 Message-ID: <001701c3aec2$4c760fc0$681067c0@adithya> From: "Mohan Parthasarathy" To: , "Alper Yegin" Cc: , "Mohan Parthasarathy" , "Bernard Aboba" References: <3FBB436E.3000105@piuha.net> Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt Date: Wed, 19 Nov 2003 09:26:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Alper Yegin wrote: > > >>This makes sense in the general way, but we need more details. Also, > >>it might be that there are difficult issues in this. For instance, > >>if network access is based on RA/ND, then we have quite a bit of > >>functionality and freedom. But I'm not sure we have that much if > >>we, say, just assign an address through IKEv2. Or maybe I just > >>don't know where that functionality exists. Anyway, I'd rather > >>have the basic IPv6 functionality available somehow, but I'm not > >>sure if you can actually run it through a tunnel. > > > > You mean configuring DHCP-based or autoconfigured IPv6 addresses inside an > > IPv6 tunnel might have issues? Any specific issues in your mind? > > It could be that I just don't know enough about the subject (please > educate me), but has the use of ND over a tunnel been defined > somewhere? There is only one on-link prefix i.e the link-local prefix. All other prefixes are considered off-link i.e you have to send it to the default router. Thus, the only node you ever do ND is for the default router's link-local address and the SPD bypasses IPsec for such packets. So, i don't understand where the ND over tunnel issue comes up. Could you clarify ? >And what if you run things over an IPsec tunnel, do > you have to use the IKEv2 facilities only for address assignment, > or can you also do DHCP and ND? > The steps are 1) PANA authentication is performed. Also EP/PaC learn each other address at the end of the authentication. 2) PaC gets a "global" address - DHCP/ND. Need to update the EP about the address for it to be able to setup SPD. At the end of this step, SPD has been setup on both PaC and EP. 3) Setup IKE/IPsec SAs. After this, ND/RD is bypassed explicitly by the SPD. Any more DHCP packets may run over the IPsec tunnel mode SA. These steps were not mentioned in the draft and i can clarify them. Does it answer your question ? -mohan > --Jari > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Nov 19 12:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28110 for ; Wed, 19 Nov 2003 12:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMW6b-000186-NZ for pana-archive@odin.ietf.org; Wed, 19 Nov 2003 12:27:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHR5Qh004340 for pana-archive@odin.ietf.org; Wed, 19 Nov 2003 12:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMW6b-00016Z-GT for pana-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28057 for ; Wed, 19 Nov 2003 12:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMW6Y-0003z8-00 for pana-web-archive@ietf.org; Wed, 19 Nov 2003 12:27:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMW6Y-0003z3-00 for pana-web-archive@ietf.org; Wed, 19 Nov 2003 12:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMW6X-00015v-Vh; Wed, 19 Nov 2003 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMW6K-000123-Tj for pana@optimus.ietf.org; Wed, 19 Nov 2003 12:26:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28021 for ; Wed, 19 Nov 2003 12:26:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMW6I-0003yU-00 for pana@ietf.org; Wed, 19 Nov 2003 12:26:46 -0500 Received: from smtp809.mail.sc5.yahoo.com ([66.163.168.188]) by ietf-mx with smtp (Exim 4.12) id 1AMW6H-0003yQ-00 for pana@ietf.org; Wed, 19 Nov 2003 12:26:45 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 19 Nov 2003 17:26:42 -0000 Message-ID: <001701c3aec2$4c760fc0$681067c0@adithya> From: "Mohan Parthasarathy" To: , "Alper Yegin" Cc: , "Mohan Parthasarathy" , "Bernard Aboba" References: <3FBB436E.3000105@piuha.net> Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt Date: Wed, 19 Nov 2003 09:26:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Alper Yegin wrote: > > >>This makes sense in the general way, but we need more details. Also, > >>it might be that there are difficult issues in this. For instance, > >>if network access is based on RA/ND, then we have quite a bit of > >>functionality and freedom. But I'm not sure we have that much if > >>we, say, just assign an address through IKEv2. Or maybe I just > >>don't know where that functionality exists. Anyway, I'd rather > >>have the basic IPv6 functionality available somehow, but I'm not > >>sure if you can actually run it through a tunnel. > > > > You mean configuring DHCP-based or autoconfigured IPv6 addresses inside an > > IPv6 tunnel might have issues? Any specific issues in your mind? > > It could be that I just don't know enough about the subject (please > educate me), but has the use of ND over a tunnel been defined > somewhere? There is only one on-link prefix i.e the link-local prefix. All other prefixes are considered off-link i.e you have to send it to the default router. Thus, the only node you ever do ND is for the default router's link-local address and the SPD bypasses IPsec for such packets. So, i don't understand where the ND over tunnel issue comes up. Could you clarify ? >And what if you run things over an IPsec tunnel, do > you have to use the IKEv2 facilities only for address assignment, > or can you also do DHCP and ND? > The steps are 1) PANA authentication is performed. Also EP/PaC learn each other address at the end of the authentication. 2) PaC gets a "global" address - DHCP/ND. Need to update the EP about the address for it to be able to setup SPD. At the end of this step, SPD has been setup on both PaC and EP. 3) Setup IKE/IPsec SAs. After this, ND/RD is bypassed explicitly by the SPD. Any more DHCP packets may run over the IPsec tunnel mode SA. These steps were not mentioned in the draft and i can clarify them. Does it answer your question ? -mohan > --Jari > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 20 17:40:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03894 for ; Thu, 20 Nov 2003 17:40:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxT0-0002Wg-Oz; Thu, 20 Nov 2003 17:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrGO-0003S8-Rr for pana@optimus.ietf.org; Thu, 20 Nov 2003 11:02:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10518 for ; Thu, 20 Nov 2003 11:02:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrGM-000574-00 for pana@ietf.org; Thu, 20 Nov 2003 11:02:34 -0500 Received: from fep03-svc.mail.telepac.pt ([194.65.5.202]) by ietf-mx with esmtp (Exim 4.12) id 1AMrGL-00056g-00 for pana@ietf.org; Thu, 20 Nov 2003 11:02:33 -0500 Received: from escritorio1 ([81.193.102.33]) by fep03-svc.mail.telepac.pt (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with SMTP id <20031120160201.ULHZ13358.fep03-svc.mail.telepac.pt@escritorio1> for ; Thu, 20 Nov 2003 16:02:01 +0000 Message-ID: <000901c3af7f$b57a89c0$ef74fea9@escritorio1> From: "Joaquim Moreira" To: Date: Thu, 20 Nov 2003 16:02:33 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C3AF7F.B53F0760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Pana] informations Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C3AF7F.B53F0760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Let me to 'put some questions (if I'm wrong, please, correct me): PANA goals: 1) One of them is : "IP: the winner interface" - with IP network and = connect all types of hosts (signalling-oriented and without signalling) = ? To build an embedded Internet (mobile, cabled,wireless networks + = internet) ? =20 2) The network has to be transparent. Security, Qos, Mobility - Security, Authentication , filter,QoS,Billing. 3) Access control is mandatory in many environments, like a connection = wireless cell - IP network. 4) For reach all this points (1, 2 and 3) a security sub-system is need: = authentication infrastructure (AAA, EAP), Packet filtering (Filter, = firewall); VPN (VLAN, IPSEC), authentication procedure (IEE 802.1x). 5) When a station is linked to a Authentication Server (RADIUS), an EAP = identity request and EAP identity response are exchanged by a PaC and a = PAA. They shared a session key ? What are the conditions to have = success ? What =20 6) EAP: Defines use Identity concept - a network acecess identifier ? how many authentication scheme per authentication server ? 7) What are Operating Software glue ? 8) Technical goals: AAA; security end to end model; for VPN - create a secured "tunnel" = between a client and a server; IPSec. 9) IP policy-based networking: Mobility, Security, Qos; Real time, Best-effort. How to do all of this ? With a policy server ? Thanks, for all Jo=E3o Moreira ------=_NextPart_000_0006_01C3AF7F.B53F0760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Let me to 'put some questions (if I'm = wrong,=20 please, correct me):
 
PANA goals:
1) One of them is : "IP: the winner = interface"=20 - with IP network and connect all types of hosts = (signalling-oriented and=20 without signalling) ?
To build an embedded Internet (mobile,=20 cabled,wireless networks + internet) ?
 
2) The network has to be = transparent.
Security, Qos, Mobility - Security, = Authentication=20 , filter,QoS,Billing.
 
3) Access control is mandatory in many=20 environments, like a connection wireless cell - IP network.
 
4) For reach all this points (1, 2 and = 3) a=20 security sub-system is need: authentication infrastructure (AAA, EAP), = Packet=20 filtering (Filter, firewall); VPN (VLAN, IPSEC), authentication = procedure (IEE=20 802.1x).
 
5) When a station is linked to a = Authentication=20 Server (RADIUS), an EAP identity request and EAP identity response are = exchanged=20 by a PaC and a PAA.  They shared a session key ? What are the=20 conditions to have success ? What  
 
6) EAP:
Defines use Identity concept - a = network acecess=20 identifier ?
how many authentication scheme per = authentication=20 server ?
 
7) What are Operating Software =  glue=20 ?
 
8) Technical goals:
AAA; security end to end model; for VPN = - create a=20 secured "tunnel" between a client and a server; IPSec.
 
9) IP policy-based = networking:
Mobility, Security, Qos; Real time, = Best-effort.=20 How to do all of this ?
With a policy server ?
 
Thanks, for all
 
Jo=E3o = Moreira
------=_NextPart_000_0006_01C3AF7F.B53F0760-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 20 17:40:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03909 for ; Thu, 20 Nov 2003 17:40:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxT7-0002XZ-JS for pana-archive@odin.ietf.org; Thu, 20 Nov 2003 17:40:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMe9CS009761 for pana-archive@odin.ietf.org; Thu, 20 Nov 2003 17:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxT6-0002XI-9c for pana-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 17:40:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03868 for ; Thu, 20 Nov 2003 17:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxT3-0005ag-00 for pana-web-archive@ietf.org; Thu, 20 Nov 2003 17:40:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMxT3-0005ac-00 for pana-web-archive@ietf.org; Thu, 20 Nov 2003 17:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxT0-0002Wg-Oz; Thu, 20 Nov 2003 17:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrGO-0003S8-Rr for pana@optimus.ietf.org; Thu, 20 Nov 2003 11:02:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10518 for ; Thu, 20 Nov 2003 11:02:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrGM-000574-00 for pana@ietf.org; Thu, 20 Nov 2003 11:02:34 -0500 Received: from fep03-svc.mail.telepac.pt ([194.65.5.202]) by ietf-mx with esmtp (Exim 4.12) id 1AMrGL-00056g-00 for pana@ietf.org; Thu, 20 Nov 2003 11:02:33 -0500 Received: from escritorio1 ([81.193.102.33]) by fep03-svc.mail.telepac.pt (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with SMTP id <20031120160201.ULHZ13358.fep03-svc.mail.telepac.pt@escritorio1> for ; Thu, 20 Nov 2003 16:02:01 +0000 Message-ID: <000901c3af7f$b57a89c0$ef74fea9@escritorio1> From: "Joaquim Moreira" To: Date: Thu, 20 Nov 2003 16:02:33 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C3AF7F.B53F0760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Pana] informations Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C3AF7F.B53F0760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Let me to 'put some questions (if I'm wrong, please, correct me): PANA goals: 1) One of them is : "IP: the winner interface" - with IP network and = connect all types of hosts (signalling-oriented and without signalling) = ? To build an embedded Internet (mobile, cabled,wireless networks + = internet) ? =20 2) The network has to be transparent. Security, Qos, Mobility - Security, Authentication , filter,QoS,Billing. 3) Access control is mandatory in many environments, like a connection = wireless cell - IP network. 4) For reach all this points (1, 2 and 3) a security sub-system is need: = authentication infrastructure (AAA, EAP), Packet filtering (Filter, = firewall); VPN (VLAN, IPSEC), authentication procedure (IEE 802.1x). 5) When a station is linked to a Authentication Server (RADIUS), an EAP = identity request and EAP identity response are exchanged by a PaC and a = PAA. They shared a session key ? What are the conditions to have = success ? What =20 6) EAP: Defines use Identity concept - a network acecess identifier ? how many authentication scheme per authentication server ? 7) What are Operating Software glue ? 8) Technical goals: AAA; security end to end model; for VPN - create a secured "tunnel" = between a client and a server; IPSec. 9) IP policy-based networking: Mobility, Security, Qos; Real time, Best-effort. How to do all of this ? With a policy server ? Thanks, for all Jo=E3o Moreira ------=_NextPart_000_0006_01C3AF7F.B53F0760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Let me to 'put some questions (if I'm = wrong,=20 please, correct me):
 
PANA goals:
1) One of them is : "IP: the winner = interface"=20 - with IP network and connect all types of hosts = (signalling-oriented and=20 without signalling) ?
To build an embedded Internet (mobile,=20 cabled,wireless networks + internet) ?
 
2) The network has to be = transparent.
Security, Qos, Mobility - Security, = Authentication=20 , filter,QoS,Billing.
 
3) Access control is mandatory in many=20 environments, like a connection wireless cell - IP network.
 
4) For reach all this points (1, 2 and = 3) a=20 security sub-system is need: authentication infrastructure (AAA, EAP), = Packet=20 filtering (Filter, firewall); VPN (VLAN, IPSEC), authentication = procedure (IEE=20 802.1x).
 
5) When a station is linked to a = Authentication=20 Server (RADIUS), an EAP identity request and EAP identity response are = exchanged=20 by a PaC and a PAA.  They shared a session key ? What are the=20 conditions to have success ? What  
 
6) EAP:
Defines use Identity concept - a = network acecess=20 identifier ?
how many authentication scheme per = authentication=20 server ?
 
7) What are Operating Software =  glue=20 ?
 
8) Technical goals:
AAA; security end to end model; for VPN = - create a=20 secured "tunnel" between a client and a server; IPSec.
 
9) IP policy-based = networking:
Mobility, Security, Qos; Real time, = Best-effort.=20 How to do all of this ?
With a policy server ?
 
Thanks, for all
 
Jo=E3o = Moreira
------=_NextPart_000_0006_01C3AF7F.B53F0760-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 20 21:12:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13885 for ; Thu, 20 Nov 2003 21:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0m9-0006eX-A9; Thu, 20 Nov 2003 21:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0m2-0006eL-Gq for pana@optimus.ietf.org; Thu, 20 Nov 2003 21:11:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13866 for ; Thu, 20 Nov 2003 21:11:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0lz-0001WA-00 for pana@ietf.org; Thu, 20 Nov 2003 21:11:51 -0500 Received: from smtp802.mail.ukl.yahoo.com ([217.12.12.139]) by ietf-mx with smtp (Exim 4.12) id 1AN0lz-0001Vy-00 for pana@ietf.org; Thu, 20 Nov 2003 21:11:51 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 21 Nov 2003 02:11:21 -0000 Message-ID: <016501c3afd4$c16364f0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , Cc: "Jari Arkko" , "Bernard Aboba" , "James Kempf" References: Subject: Re: [Pana] IP address configuration Date: Thu, 20 Nov 2003 18:11:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper, > - IPsec-based access control after PANA: > > This time IP addresses are used as the device ID and they have significance > for the access control and PANA session. > > Pre-PANA addresses are configured the same way as before (via DHCP or > stateless address autoconfiguration). IPv6 link-locals used for IPv6, and > IPv4 link-local or DHCP for IPv4. > > A pre-PANA address is bound to the PaC as the device ID. It will be used as > the local end-point of the IPsec tunnel to the EP. > > If PaC needs to configure a post-PANA address, this should be indicated by I am not sure i understood the "need" part. The PaC most likely would configure a routeable address. And why does the network operator control this ? > the PANA-Bind-Request message. PaC should attempt this configuration inside > the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address > autoconfiguration or DHCP can be used. > As i clarified in my other email, you don't setup the IPsec selectors until you have acquired the "routeable" (inner) address. And these addresses are used as selectors in the SPD. > Both pre-PANA and post-PANA addresses are used by the PaC at the same time, > though post-PANA addresses only appear inside the tunnel. A post-PANA > address has no significance for the PANA session or access control. > For tunnel mode SA, the outer addresses are not significant for access control. The inner addresses are used for access control. SPD selectors are inner addresses. > If pre-PANA and post-PANA addresses are the same, they will be used both > inside and outside the tunnel (any issues with IPsec processing?). This can Some implementations have problem with this when the packets are destined to the tunnel end point address itself. Here, these will be PANA messages which will anway be bypassed (mentioned in the draft) i.e no IPsec for PANA messages flowing between PaC and PAA/EP. > be the case when the client has a static IP address, or the DHCP address > assignment does not depend on the client identity. > > Comments? > > Alper > mohan > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 20 21:12:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13900 for ; Thu, 20 Nov 2003 21:12:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0mD-0006fC-1R for pana-archive@odin.ietf.org; Thu, 20 Nov 2003 21:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL2C5RR025610 for pana-archive@odin.ietf.org; Thu, 20 Nov 2003 21:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0mC-0006ez-RX for pana-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 21:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13873 for ; Thu, 20 Nov 2003 21:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0mA-0001WG-00 for pana-web-archive@ietf.org; Thu, 20 Nov 2003 21:12:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN0m9-0001WD-00 for pana-web-archive@ietf.org; Thu, 20 Nov 2003 21:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0m9-0006eX-A9; Thu, 20 Nov 2003 21:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0m2-0006eL-Gq for pana@optimus.ietf.org; Thu, 20 Nov 2003 21:11:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13866 for ; Thu, 20 Nov 2003 21:11:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0lz-0001WA-00 for pana@ietf.org; Thu, 20 Nov 2003 21:11:51 -0500 Received: from smtp802.mail.ukl.yahoo.com ([217.12.12.139]) by ietf-mx with smtp (Exim 4.12) id 1AN0lz-0001Vy-00 for pana@ietf.org; Thu, 20 Nov 2003 21:11:51 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 21 Nov 2003 02:11:21 -0000 Message-ID: <016501c3afd4$c16364f0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , Cc: "Jari Arkko" , "Bernard Aboba" , "James Kempf" References: Subject: Re: [Pana] IP address configuration Date: Thu, 20 Nov 2003 18:11:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper, > - IPsec-based access control after PANA: > > This time IP addresses are used as the device ID and they have significance > for the access control and PANA session. > > Pre-PANA addresses are configured the same way as before (via DHCP or > stateless address autoconfiguration). IPv6 link-locals used for IPv6, and > IPv4 link-local or DHCP for IPv4. > > A pre-PANA address is bound to the PaC as the device ID. It will be used as > the local end-point of the IPsec tunnel to the EP. > > If PaC needs to configure a post-PANA address, this should be indicated by I am not sure i understood the "need" part. The PaC most likely would configure a routeable address. And why does the network operator control this ? > the PANA-Bind-Request message. PaC should attempt this configuration inside > the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address > autoconfiguration or DHCP can be used. > As i clarified in my other email, you don't setup the IPsec selectors until you have acquired the "routeable" (inner) address. And these addresses are used as selectors in the SPD. > Both pre-PANA and post-PANA addresses are used by the PaC at the same time, > though post-PANA addresses only appear inside the tunnel. A post-PANA > address has no significance for the PANA session or access control. > For tunnel mode SA, the outer addresses are not significant for access control. The inner addresses are used for access control. SPD selectors are inner addresses. > If pre-PANA and post-PANA addresses are the same, they will be used both > inside and outside the tunnel (any issues with IPsec processing?). This can Some implementations have problem with this when the packets are destined to the tunnel end point address itself. Here, these will be PANA messages which will anway be bypassed (mentioned in the draft) i.e no IPsec for PANA messages flowing between PaC and PAA/EP. > be the case when the client has a static IP address, or the DHCP address > assignment does not depend on the client identity. > > Comments? > > Alper > mohan > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 21 08:53:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13477 for ; Fri, 21 Nov 2003 08:53:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBiX-0007b1-Bw; Fri, 21 Nov 2003 08:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBhn-0007Yy-1l for pana@optimus.ietf.org; Fri, 21 Nov 2003 08:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13453 for ; Fri, 21 Nov 2003 08:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBhl-0002Po-00 for pana@ietf.org; Fri, 21 Nov 2003 08:52:13 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1ANBhk-0002PV-00 for pana@ietf.org; Fri, 21 Nov 2003 08:52:12 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0CFE234785; Fri, 21 Nov 2003 14:51:41 +0100 (CET) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 2F619343C1; Fri, 21 Nov 2003 14:51:39 +0100 (CET) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id 151D314431; Fri, 21 Nov 2003 14:39:02 +0100 (MET) Message-ID: <3FBE185D.5040304@dif.um.es> Date: Fri, 21 Nov 2003 14:51:25 +0100 From: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: es-es, es MIME-Version: 1.0 To: Mohan Parthasarathy Cc: jari.arkko@piuha.net, Alper Yegin , pana@ietf.org, Mohan Parthasarathy , Bernard Aboba Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt References: <3FBB436E.3000105@piuha.net> <001701c3aec2$4c760fc0$681067c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello all ... I have a question about process you comment at the end of the e-mail...=20 should not stept 2) be changed by 3) step? I mean after PANA=20 authentication , we would establish a IPSec SA between PaC and EP and=20 then to get a global address. Thanks. Mohan Parthasarathy escribi=F3: > =20 > >>Alper Yegin wrote: >> >> =20 >> >>>>This makes sense in the general way, but we need more details. Also, >>>>it might be that there are difficult issues in this. For instance, >>>>if network access is based on RA/ND, then we have quite a bit of >>>>functionality and freedom. But I'm not sure we have that much if >>>>we, say, just assign an address through IKEv2. Or maybe I just >>>>don't know where that functionality exists. Anyway, I'd rather >>>>have the basic IPv6 functionality available somehow, but I'm not >>>>sure if you can actually run it through a tunnel. >>>> =20 >>>> >>>You mean configuring DHCP-based or autoconfigured IPv6 addresses insid= e >>> =20 >>> >an > =20 > >>>IPv6 tunnel might have issues? Any specific issues in your mind? >>> =20 >>> >>It could be that I just don't know enough about the subject (please >>educate me), but has the use of ND over a tunnel been defined >>somewhere? >> =20 >> > >There is only one on-link prefix i.e the link-local prefix. All other >prefixes >are considered off-link i.e you have to send it to the default router. T= hus, >the only node you ever do ND is for the default router's link-local addr= ess >and the SPD bypasses IPsec for such packets. So, i don't understand wher= e >the >ND over tunnel issue comes up. Could you clarify ? > > =20 > >>And what if you run things over an IPsec tunnel, do >>you have to use the IKEv2 facilities only for address assignment, >>or can you also do DHCP and ND? >> >> =20 >> >The steps are > >1) PANA authentication is performed. Also EP/PaC learn each other addres= s at >the > end of the authentication. >2) PaC gets a "global" address - DHCP/ND. Need to update the EP about > the address for it to be able to setup SPD. At the end of this step= , >SPD has > been setup on both PaC and EP. >3) Setup IKE/IPsec SAs. > >After this, ND/RD is bypassed explicitly by the SPD. Any more DHCP packe= ts >may run >over the IPsec tunnel mode SA. > >These steps were not mentioned in the draft and i can clarify them. Doe= s it >answer >your question ? > >-mohan > > =20 > >>--Jari >> >> >>_______________________________________________ >>Pana mailing list >>Pana@ietf.org >>https://www1.ietf.org/mailman/listinfo/pana >> =20 >> > > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > =20 > --=20 ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 21 08:53:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13493 for ; Fri, 21 Nov 2003 08:53:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBid-0007bm-26 for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 08:53:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALDr7gk029245 for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 08:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBic-0007bc-T1 for pana-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 08:53:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13461 for ; Fri, 21 Nov 2003 08:52:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBib-0002Pw-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 08:53:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANBib-0002Pt-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 08:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBiX-0007b1-Bw; Fri, 21 Nov 2003 08:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBhn-0007Yy-1l for pana@optimus.ietf.org; Fri, 21 Nov 2003 08:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13453 for ; Fri, 21 Nov 2003 08:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBhl-0002Po-00 for pana@ietf.org; Fri, 21 Nov 2003 08:52:13 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1ANBhk-0002PV-00 for pana@ietf.org; Fri, 21 Nov 2003 08:52:12 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0CFE234785; Fri, 21 Nov 2003 14:51:41 +0100 (CET) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 2F619343C1; Fri, 21 Nov 2003 14:51:39 +0100 (CET) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id 151D314431; Fri, 21 Nov 2003 14:39:02 +0100 (MET) Message-ID: <3FBE185D.5040304@dif.um.es> Date: Fri, 21 Nov 2003 14:51:25 +0100 From: =?ISO-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: es-es, es MIME-Version: 1.0 To: Mohan Parthasarathy Cc: jari.arkko@piuha.net, Alper Yegin , pana@ietf.org, Mohan Parthasarathy , Bernard Aboba Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt References: <3FBB436E.3000105@piuha.net> <001701c3aec2$4c760fc0$681067c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello all ... I have a question about process you comment at the end of the e-mail...=20 should not stept 2) be changed by 3) step? I mean after PANA=20 authentication , we would establish a IPSec SA between PaC and EP and=20 then to get a global address. Thanks. Mohan Parthasarathy escribi=F3: > =20 > >>Alper Yegin wrote: >> >> =20 >> >>>>This makes sense in the general way, but we need more details. Also, >>>>it might be that there are difficult issues in this. For instance, >>>>if network access is based on RA/ND, then we have quite a bit of >>>>functionality and freedom. But I'm not sure we have that much if >>>>we, say, just assign an address through IKEv2. Or maybe I just >>>>don't know where that functionality exists. Anyway, I'd rather >>>>have the basic IPv6 functionality available somehow, but I'm not >>>>sure if you can actually run it through a tunnel. >>>> =20 >>>> >>>You mean configuring DHCP-based or autoconfigured IPv6 addresses insid= e >>> =20 >>> >an > =20 > >>>IPv6 tunnel might have issues? Any specific issues in your mind? >>> =20 >>> >>It could be that I just don't know enough about the subject (please >>educate me), but has the use of ND over a tunnel been defined >>somewhere? >> =20 >> > >There is only one on-link prefix i.e the link-local prefix. All other >prefixes >are considered off-link i.e you have to send it to the default router. T= hus, >the only node you ever do ND is for the default router's link-local addr= ess >and the SPD bypasses IPsec for such packets. So, i don't understand wher= e >the >ND over tunnel issue comes up. Could you clarify ? > > =20 > >>And what if you run things over an IPsec tunnel, do >>you have to use the IKEv2 facilities only for address assignment, >>or can you also do DHCP and ND? >> >> =20 >> >The steps are > >1) PANA authentication is performed. Also EP/PaC learn each other addres= s at >the > end of the authentication. >2) PaC gets a "global" address - DHCP/ND. Need to update the EP about > the address for it to be able to setup SPD. At the end of this step= , >SPD has > been setup on both PaC and EP. >3) Setup IKE/IPsec SAs. > >After this, ND/RD is bypassed explicitly by the SPD. Any more DHCP packe= ts >may run >over the IPsec tunnel mode SA. > >These steps were not mentioned in the draft and i can clarify them. Doe= s it >answer >your question ? > >-mohan > > =20 > >>--Jari >> >> >>_______________________________________________ >>Pana mailing list >>Pana@ietf.org >>https://www1.ietf.org/mailman/listinfo/pana >> =20 >> > > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > =20 > --=20 ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 21 18:36:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12266 for ; Fri, 21 Nov 2003 18:36:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKoi-0007B0-JC; Fri, 21 Nov 2003 18:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKo8-0007AI-Ue for pana@optimus.ietf.org; Fri, 21 Nov 2003 18:35:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12179 for ; Fri, 21 Nov 2003 18:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKnv-00043p-00 for pana@ietf.org; Fri, 21 Nov 2003 18:35:11 -0500 Received: from smtp807.mail.sc5.yahoo.com ([66.163.168.186]) by ietf-mx with smtp (Exim 4.12) id 1ANKnk-00043f-00 for pana@ietf.org; Fri, 21 Nov 2003 18:35:00 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 21 Nov 2003 23:34:50 -0000 Message-ID: <00f901c3b088$0ed8dcc0$681067c0@adithya> From: "Mohan Parthasarathy" To: =?iso-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= Cc: , "Alper Yegin" , , "Bernard Aboba" References: <00e601c3b080$9f9488c0$681067c0@adithya> Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt Date: Fri, 21 Nov 2003 15:34:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA12201 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Hello all ... > > I have a question about process you comment at the end of the e-mail... > should not stept 2) be changed by 3) step? I mean after PANA > authentication , we would establish a IPSec SA between PaC and EP and > then to get a global address. > The selector that triggers setting up the SA is the inner address i.e global/routeable address that is acquired by DHCP/ND. Let us say, you have 2 clients with GLOB_ADDR1, GLOB_ADDR2 respectively. On the EP, packets whose destination address matches either one of the above will send the packets encrypted/authenticated to the client. This means EP has to know the client address before negotiating t= he SA. Similarly PaC has to know which address the SA is being bound to. Thus, y= ou have to acquire an address before setting up the SA. -mohan > Thanks. > > Mohan Parthasarathy escribi=F3: > > > > > > >>Alper Yegin wrote: > >> > >> > >> > >>>>This makes sense in the general way, but we need more details. Also= , > >>>>it might be that there are difficult issues in this. For instance, > >>>>if network access is based on RA/ND, then we have quite a bit of > >>>>functionality and freedom. But I'm not sure we have that much if > >>>>we, say, just assign an address through IKEv2. Or maybe I just > >>>>don't know where that functionality exists. Anyway, I'd rather > >>>>have the basic IPv6 functionality available somehow, but I'm not > >>>>sure if you can actually run it through a tunnel. > >>>> > >>>> > >>>You mean configuring DHCP-based or autoconfigured IPv6 addresses ins= ide > >>> > >>> > >an > > > > > >>>IPv6 tunnel might have issues? Any specific issues in your mind? > >>> > >>> > >>It could be that I just don't know enough about the subject (please > >>educate me), but has the use of ND over a tunnel been defined > >>somewhere? > >> > >> > > > >There is only one on-link prefix i.e the link-local prefix. All other > >prefixes > >are considered off-link i.e you have to send it to the default router. > Thus, > >the only node you ever do ND is for the default router's link-local address > >and the SPD bypasses IPsec for such packets. So, i don't understand wh= ere > >the > >ND over tunnel issue comes up. Could you clarify ? > > > > > > > >>And what if you run things over an IPsec tunnel, do > >>you have to use the IKEv2 facilities only for address assignment, > >>or can you also do DHCP and ND? > >> > >> > >> > >The steps are > > > >1) PANA authentication is performed. Also EP/PaC learn each other addr= ess > at > >the > > end of the authentication. > >2) PaC gets a "global" address - DHCP/ND. Need to update the EP about > > the address for it to be able to setup SPD. At the end of this st= ep, > >SPD has > > been setup on both PaC and EP. > >3) Setup IKE/IPsec SAs. > > > >After this, ND/RD is bypassed explicitly by the SPD. Any more DHCP packets > >may run > >over the IPsec tunnel mode SA. > > > >These steps were not mentioned in the draft and i can clarify them. D= oes > it > >answer > >your question ? > > > >-mohan > > > > > > > >>--Jari > >> > >> > >>_______________________________________________ > >>Pana mailing list > >>Pana@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pana > >> > >> > > > > > >_______________________________________________ > >Pana mailing list > >Pana@ietf.org > >https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > --=20 > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------=20 > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 21 18:36:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12284 for ; Fri, 21 Nov 2003 18:36:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKol-0007Bh-Mo for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 18:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALNa3G4027628 for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 18:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKol-0007BW-He for pana-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 18:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12254 for ; Fri, 21 Nov 2003 18:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKoi-00044F-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 18:36:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANKoi-00044B-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 18:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKoi-0007B0-JC; Fri, 21 Nov 2003 18:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKo8-0007AI-Ue for pana@optimus.ietf.org; Fri, 21 Nov 2003 18:35:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12179 for ; Fri, 21 Nov 2003 18:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKnv-00043p-00 for pana@ietf.org; Fri, 21 Nov 2003 18:35:11 -0500 Received: from smtp807.mail.sc5.yahoo.com ([66.163.168.186]) by ietf-mx with smtp (Exim 4.12) id 1ANKnk-00043f-00 for pana@ietf.org; Fri, 21 Nov 2003 18:35:00 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 21 Nov 2003 23:34:50 -0000 Message-ID: <00f901c3b088$0ed8dcc0$681067c0@adithya> From: "Mohan Parthasarathy" To: =?iso-8859-1?Q?Rafa_Mar=EDn_L=F3pez?= Cc: , "Alper Yegin" , , "Bernard Aboba" References: <00e601c3b080$9f9488c0$681067c0@adithya> Subject: Re: [Pana] comments on draft-ietf-pana-ipsec-00.txt Date: Fri, 21 Nov 2003 15:34:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA12201 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Hello all ... > > I have a question about process you comment at the end of the e-mail... > should not stept 2) be changed by 3) step? I mean after PANA > authentication , we would establish a IPSec SA between PaC and EP and > then to get a global address. > The selector that triggers setting up the SA is the inner address i.e global/routeable address that is acquired by DHCP/ND. Let us say, you have 2 clients with GLOB_ADDR1, GLOB_ADDR2 respectively. On the EP, packets whose destination address matches either one of the above will send the packets encrypted/authenticated to the client. This means EP has to know the client address before negotiating t= he SA. Similarly PaC has to know which address the SA is being bound to. Thus, y= ou have to acquire an address before setting up the SA. -mohan > Thanks. > > Mohan Parthasarathy escribi=F3: > > > > > > >>Alper Yegin wrote: > >> > >> > >> > >>>>This makes sense in the general way, but we need more details. Also= , > >>>>it might be that there are difficult issues in this. For instance, > >>>>if network access is based on RA/ND, then we have quite a bit of > >>>>functionality and freedom. But I'm not sure we have that much if > >>>>we, say, just assign an address through IKEv2. Or maybe I just > >>>>don't know where that functionality exists. Anyway, I'd rather > >>>>have the basic IPv6 functionality available somehow, but I'm not > >>>>sure if you can actually run it through a tunnel. > >>>> > >>>> > >>>You mean configuring DHCP-based or autoconfigured IPv6 addresses ins= ide > >>> > >>> > >an > > > > > >>>IPv6 tunnel might have issues? Any specific issues in your mind? > >>> > >>> > >>It could be that I just don't know enough about the subject (please > >>educate me), but has the use of ND over a tunnel been defined > >>somewhere? > >> > >> > > > >There is only one on-link prefix i.e the link-local prefix. All other > >prefixes > >are considered off-link i.e you have to send it to the default router. > Thus, > >the only node you ever do ND is for the default router's link-local address > >and the SPD bypasses IPsec for such packets. So, i don't understand wh= ere > >the > >ND over tunnel issue comes up. Could you clarify ? > > > > > > > >>And what if you run things over an IPsec tunnel, do > >>you have to use the IKEv2 facilities only for address assignment, > >>or can you also do DHCP and ND? > >> > >> > >> > >The steps are > > > >1) PANA authentication is performed. Also EP/PaC learn each other addr= ess > at > >the > > end of the authentication. > >2) PaC gets a "global" address - DHCP/ND. Need to update the EP about > > the address for it to be able to setup SPD. At the end of this st= ep, > >SPD has > > been setup on both PaC and EP. > >3) Setup IKE/IPsec SAs. > > > >After this, ND/RD is bypassed explicitly by the SPD. Any more DHCP packets > >may run > >over the IPsec tunnel mode SA. > > > >These steps were not mentioned in the draft and i can clarify them. D= oes > it > >answer > >your question ? > > > >-mohan > > > > > > > >>--Jari > >> > >> > >>_______________________________________________ > >>Pana mailing list > >>Pana@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pana > >> > >> > > > > > >_______________________________________________ > >Pana mailing list > >Pana@ietf.org > >https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > --=20 > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------=20 > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 21 20:18:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14836 for ; Fri, 21 Nov 2003 20:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMPR-0005LJ-RA; Fri, 21 Nov 2003 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMPM-0005KA-3g for pana@optimus.ietf.org; Fri, 21 Nov 2003 20:17:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14794 for ; Fri, 21 Nov 2003 20:17:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMPJ-0005EO-00 for pana@ietf.org; Fri, 21 Nov 2003 20:17:53 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ANMPJ-0005EK-00 for pana@ietf.org; Fri, 21 Nov 2003 20:17:53 -0500 Date: Fri, 21 Nov 2003 17:18:48 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: Mohan Parthasarathy , CC: Jari Arkko , Bernard Aboba , James Kempf Message-ID: In-Reply-To: <016501c3afd4$c16364f0$681067c0@adithya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> A pre-PANA address is bound to the PaC as the device ID. It will be used > as >> the local end-point of the IPsec tunnel to the EP. >> >> If PaC needs to configure a post-PANA address, this should be indicated by > > I am not sure i understood the "need" part. The PaC most likely would > configure > a routeable address. And why does the network operator control this ? Actually pre-PANA and post-PANA addresses do not necessarily mean link-local/non-routable and globally routable addresses. Pre-PANA address is configured prior to PANA and used during the authentication. Post-PANA address is configured after the PaC is authorized. In case the PaC is statically configured, or the IP address assignment does not depend on the PaC identity and the network is willing to assign the ultimate IP address to the client before authentication, then pre- and post-PANA addresses can be the same. In an access network, the ultimate IP address assignment might rely on the identity of the PaC (e.g., DSL networks). In that case, the NAP might assign a pre-PANA address first. Later, the PaC needs to configure post-PANA address that belongs to the ISP network. > >> the PANA-Bind-Request message. PaC should attempt this configuration > inside >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address >> autoconfiguration or DHCP can be used. >> > As i clarified in my other email, you don't setup the IPsec selectors until > you have > acquired the "routeable" (inner) address. And these addresses are used as > selectors > in the SPD. > >> Both pre-PANA and post-PANA addresses are used by the PaC at the same > time, >> though post-PANA addresses only appear inside the tunnel. A post-PANA >> address has no significance for the PANA session or access control. >> > For tunnel mode SA, the outer addresses are not significant for access > control. > The inner addresses are used for access control. SPD selectors are inner > addresses. Apparently I was still thinking in terms of IP-IP transport mode (the older version of the draft). Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's phase 2 identity, so that the inner IP addresses can be anything. And run address autoconfiguration or DHCP inside the tunnel. > >> If pre-PANA and post-PANA addresses are the same, they will be used both >> inside and outside the tunnel (any issues with IPsec processing?). This > can > > Some implementations have problem with this when the packets are destined to > the tunnel end point address itself. Does this have anyting to do with the specification, or the intended use of it? Or, is this simple a shortcoming or a bug in some implementations? > Here, these will be PANA messages > which will anway be bypassed (mentioned in the draft) i.e no IPsec for PANA > messages flowing between PaC and PAA/EP. Alper > >> be the case when the client has a static IP address, or the DHCP address >> assignment does not depend on the client identity. >> >> Comments? >> >> Alper >> > mohan > >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 21 20:18:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14851 for ; Fri, 21 Nov 2003 20:18:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMPV-0005Mp-0a for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 20:18:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM1I4B8020625 for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 20:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMPU-0005MX-RL for pana-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 20:18:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14809 for ; Fri, 21 Nov 2003 20:17:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMPS-0005Es-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 20:18:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANMPS-0005Ep-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 20:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMPR-0005LJ-RA; Fri, 21 Nov 2003 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMPM-0005KA-3g for pana@optimus.ietf.org; Fri, 21 Nov 2003 20:17:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14794 for ; Fri, 21 Nov 2003 20:17:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMPJ-0005EO-00 for pana@ietf.org; Fri, 21 Nov 2003 20:17:53 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ANMPJ-0005EK-00 for pana@ietf.org; Fri, 21 Nov 2003 20:17:53 -0500 Date: Fri, 21 Nov 2003 17:18:48 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: Mohan Parthasarathy , CC: Jari Arkko , Bernard Aboba , James Kempf Message-ID: In-Reply-To: <016501c3afd4$c16364f0$681067c0@adithya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> A pre-PANA address is bound to the PaC as the device ID. It will be used > as >> the local end-point of the IPsec tunnel to the EP. >> >> If PaC needs to configure a post-PANA address, this should be indicated by > > I am not sure i understood the "need" part. The PaC most likely would > configure > a routeable address. And why does the network operator control this ? Actually pre-PANA and post-PANA addresses do not necessarily mean link-local/non-routable and globally routable addresses. Pre-PANA address is configured prior to PANA and used during the authentication. Post-PANA address is configured after the PaC is authorized. In case the PaC is statically configured, or the IP address assignment does not depend on the PaC identity and the network is willing to assign the ultimate IP address to the client before authentication, then pre- and post-PANA addresses can be the same. In an access network, the ultimate IP address assignment might rely on the identity of the PaC (e.g., DSL networks). In that case, the NAP might assign a pre-PANA address first. Later, the PaC needs to configure post-PANA address that belongs to the ISP network. > >> the PANA-Bind-Request message. PaC should attempt this configuration > inside >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address >> autoconfiguration or DHCP can be used. >> > As i clarified in my other email, you don't setup the IPsec selectors until > you have > acquired the "routeable" (inner) address. And these addresses are used as > selectors > in the SPD. > >> Both pre-PANA and post-PANA addresses are used by the PaC at the same > time, >> though post-PANA addresses only appear inside the tunnel. A post-PANA >> address has no significance for the PANA session or access control. >> > For tunnel mode SA, the outer addresses are not significant for access > control. > The inner addresses are used for access control. SPD selectors are inner > addresses. Apparently I was still thinking in terms of IP-IP transport mode (the older version of the draft). Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's phase 2 identity, so that the inner IP addresses can be anything. And run address autoconfiguration or DHCP inside the tunnel. > >> If pre-PANA and post-PANA addresses are the same, they will be used both >> inside and outside the tunnel (any issues with IPsec processing?). This > can > > Some implementations have problem with this when the packets are destined to > the tunnel end point address itself. Does this have anyting to do with the specification, or the intended use of it? Or, is this simple a shortcoming or a bug in some implementations? > Here, these will be PANA messages > which will anway be bypassed (mentioned in the draft) i.e no IPsec for PANA > messages flowing between PaC and PAA/EP. Alper > >> be the case when the client has a static IP address, or the DHCP address >> assignment does not depend on the client identity. >> >> Comments? >> >> Alper >> > mohan > >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 21 20:39:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15541 for ; Fri, 21 Nov 2003 20:39:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMjk-0006vi-H9; Fri, 21 Nov 2003 20:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMiv-0006s6-Sf for pana@optimus.ietf.org; Fri, 21 Nov 2003 20:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15515 for ; Fri, 21 Nov 2003 20:37:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMit-0005Vy-00 for pana@ietf.org; Fri, 21 Nov 2003 20:38:07 -0500 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1ANMis-0005Vv-00 for pana@ietf.org; Fri, 21 Nov 2003 20:38:06 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 22 Nov 2003 01:38:06 -0000 Message-ID: <013501c3b099$47712c70$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , Cc: "Jari Arkko" , "Bernard Aboba" , "James Kempf" References: Subject: Re: [Pana] IP address configuration Date: Fri, 21 Nov 2003 17:38:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > > >> the PANA-Bind-Request message. PaC should attempt this configuration > > inside > >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address > >> autoconfiguration or DHCP can be used. > >> > > As i clarified in my other email, you don't setup the IPsec selectors until > > you have > > acquired the "routeable" (inner) address. And these addresses are used as > > selectors > > in the SPD. > > > >> Both pre-PANA and post-PANA addresses are used by the PaC at the same > > time, > >> though post-PANA addresses only appear inside the tunnel. A post-PANA > >> address has no significance for the PANA session or access control. > >> > > For tunnel mode SA, the outer addresses are not significant for access > > control. > > The inner addresses are used for access control. SPD selectors are inner > > addresses. > > Apparently I was still thinking in terms of IP-IP transport mode (the older > version of the draft). > Yes. The older version of the draft used just the link-local address as selectors. So, it is possible to do IPsec as soon as you are done with PANA. > Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's phase > 2 identity, so that the inner IP addresses can be anything. And run address > autoconfiguration or DHCP inside the tunnel. > I am not sure whether the EP would accept the range. EP may just accept only one address as it lets any authenticated nodes spoof each other very easily. I have only seen ranges used by VPN gateways and not sure whether any host uses it or not. Again, if we can fix this in other ways e.g. using IP-IP transport mode, we should do that. > > > > >> If pre-PANA and post-PANA addresses are the same, they will be used both > >> inside and outside the tunnel (any issues with IPsec processing?). This > > can > > > > Some implementations have problem with this when the packets are destined to > > the tunnel end point address itself. > > Does this have anyting to do with the specification, or the intended use of > it? Or, is this simple a shortcoming or a bug in some implementations? > It is just an implementation artefact. I send packets to "DEST", route lookup returns a tunnel interface, which in turn encapsulated with outer header "DEST" , re-enters IP and loops again. This comes as a side effect of implementing IPsec tunnel mode SA as an "interface". This is not a real issue here as we can always bypass IPsec for messages sent to EP. -mohan > > Here, these will be PANA messages > > which will anway be bypassed (mentioned in the draft) i.e no IPsec for PANA > > messages flowing between PaC and PAA/EP. > > > > Alper > > > > > >> be the case when the client has a static IP address, or the DHCP address > >> assignment does not depend on the client identity. > >> > >> Comments? > >> > >> Alper > >> > > mohan > > > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 21 20:39:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15556 for ; Fri, 21 Nov 2003 20:39:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMjn-0006wQ-Ta for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 20:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM1d379026676 for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 20:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMjn-0006wB-OP for pana-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 20:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15529 for ; Fri, 21 Nov 2003 20:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMjl-0005W8-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 20:39:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANMjl-0005W5-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 20:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMjk-0006vi-H9; Fri, 21 Nov 2003 20:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMiv-0006s6-Sf for pana@optimus.ietf.org; Fri, 21 Nov 2003 20:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15515 for ; Fri, 21 Nov 2003 20:37:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMit-0005Vy-00 for pana@ietf.org; Fri, 21 Nov 2003 20:38:07 -0500 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1ANMis-0005Vv-00 for pana@ietf.org; Fri, 21 Nov 2003 20:38:06 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 22 Nov 2003 01:38:06 -0000 Message-ID: <013501c3b099$47712c70$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , Cc: "Jari Arkko" , "Bernard Aboba" , "James Kempf" References: Subject: Re: [Pana] IP address configuration Date: Fri, 21 Nov 2003 17:38:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > >> the PANA-Bind-Request message. PaC should attempt this configuration > > inside > >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address > >> autoconfiguration or DHCP can be used. > >> > > As i clarified in my other email, you don't setup the IPsec selectors until > > you have > > acquired the "routeable" (inner) address. And these addresses are used as > > selectors > > in the SPD. > > > >> Both pre-PANA and post-PANA addresses are used by the PaC at the same > > time, > >> though post-PANA addresses only appear inside the tunnel. A post-PANA > >> address has no significance for the PANA session or access control. > >> > > For tunnel mode SA, the outer addresses are not significant for access > > control. > > The inner addresses are used for access control. SPD selectors are inner > > addresses. > > Apparently I was still thinking in terms of IP-IP transport mode (the older > version of the draft). > Yes. The older version of the draft used just the link-local address as selectors. So, it is possible to do IPsec as soon as you are done with PANA. > Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's phase > 2 identity, so that the inner IP addresses can be anything. And run address > autoconfiguration or DHCP inside the tunnel. > I am not sure whether the EP would accept the range. EP may just accept only one address as it lets any authenticated nodes spoof each other very easily. I have only seen ranges used by VPN gateways and not sure whether any host uses it or not. Again, if we can fix this in other ways e.g. using IP-IP transport mode, we should do that. > > > > >> If pre-PANA and post-PANA addresses are the same, they will be used both > >> inside and outside the tunnel (any issues with IPsec processing?). This > > can > > > > Some implementations have problem with this when the packets are destined to > > the tunnel end point address itself. > > Does this have anyting to do with the specification, or the intended use of > it? Or, is this simple a shortcoming or a bug in some implementations? > It is just an implementation artefact. I send packets to "DEST", route lookup returns a tunnel interface, which in turn encapsulated with outer header "DEST" , re-enters IP and loops again. This comes as a side effect of implementing IPsec tunnel mode SA as an "interface". This is not a real issue here as we can always bypass IPsec for messages sent to EP. -mohan > > Here, these will be PANA messages > > which will anway be bypassed (mentioned in the draft) i.e no IPsec for PANA > > messages flowing between PaC and PAA/EP. > > > > Alper > > > > > >> be the case when the client has a static IP address, or the DHCP address > >> assignment does not depend on the client identity. > >> > >> Comments? > >> > >> Alper > >> > > mohan > > > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 21 21:24:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16357 for ; Fri, 21 Nov 2003 21:24:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANNRI-0000b7-TZ; Fri, 21 Nov 2003 21:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANNQy-0000Vw-C7 for pana@optimus.ietf.org; Fri, 21 Nov 2003 21:23:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16331 for ; Fri, 21 Nov 2003 21:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANNQq-0005w1-00 for pana@ietf.org; Fri, 21 Nov 2003 21:23:32 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ANNQq-0005vy-00 for pana@ietf.org; Fri, 21 Nov 2003 21:23:32 -0500 Date: Fri, 21 Nov 2003 18:24:32 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] Draft meeting minutes Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit See below for the draft meeting minutes from IETF 58 PANA meeting. Please let us know if there is a need to correct/add anything. Alper Protocol for Carrying Authentication for Network Access WG (pana) Tuesday, November 11 at 0900-1130 ================================== CHAIRS: Basavaraj Patil Alper Yegin Note Takers: Dan Forsberg, Mohan Parthasarathy AGENDA: 1. Preliminaries (bluesheets, minute takers, agenda bashing): 5 min Chairs -------------------------------------------------------------------- Dan will take minutes. Mohan will take minutes. Raj went through the agenda and document statuses. STATUS of WG I-Ds: - draft-ietf-pana-usage-scenarios-06.txt WG last call completed on 3/11/03. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-requirements-07.txt WG last call completed on 6/12/03. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-threats-eval-04.txt WG last call completed on 5/1/03. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-pana-02.txt Work in progress. I-D will be discussed at IETF 58. - draft-ietf-pana-ipsec-00.txt Work in progress. I-D will be discussed at IETF 58. 2. PANA protocol update and open issues: 30 min, Yoshihiro Ohba -------------------------------------------------------------------- draft-ietf-pana-pana-02.txt. See "Change History" section of the draft for the list of issues closed in this revision. Detailed issue descriptions can be found at http://danforsberg.info:8080/pana-issues/ Newly closed issues and currently open issues will be covered in this presentation for confirming/achieving consensus. Dan: change the URL of open issues on the first slide (take away the "www"). Closed issues: Issue22, R-flag is used to distinguish request and answer. Issue23, shared code space with Diameter. Issue17, PANA-Error is defined. Issue24, avp alignment rule is added. Issue18, PANA-Termination-Cause AVP values are defined. Issue19, Result-Code AVP values are defined. Other issues: Issue20. Issue25. Relates to ISP selection. Issue8. Issue31. Issue32. Issue33. Issues21, 26, 30. Issue20. Retransmission timers and counters. Two classes for retransmission values: PANA-PAA-Discover and other messages. Issue25. Service Profile names. Define two new AVPs. NAP-Information and ISP-Information AVPs. Defined a new flag (S). F-flag is not needed anymore. PAA advertises NAPs and ISPs (information AVPs). Open issues: Issue34. NAP and ISP authentications. Proposed solution: use single lifetime (the smallest one). Both NAP and ISP re-authentications happen at the same time. Issue37. Unknown realm propagation. Should unknown realm AAA message routing error be propagated to PaC. Direct interface between PAA and AAA would be needed. Alper: Yoshi, do we know how other EAP lower layers behave in this case? Yoshi: IEEE 802.1x doesn't carry any unknown errors. Raj: Is it required to use EAP layer? Can't we send unknow error message through PANA? You need direct interface between PANA and AAA? Or is it an EAP state machine problem? Yoshi: EAP state machine doesn't allow this. My opinion is that this complicates the implementation. Raj: ok. Mohan: How can PANA error message communicate this problem? Raj: You introduce PANA-Error message, why not use that? Yoshi: We can use PANA-Error message to propagate msg from PAA to PaC. The problem is between AAA and PAA. Raj: Does this mean that we need to do enhancement to the AAA spec? Yoshi: no changes to the spec., but to the API perhaps. Raj: let's take this into further discussions. Issue29: EAP Failure and PANA-Bind-Request. Problematic with NAP and ISP authentication. Single PANA-Termination-Request can't be used. We may want to change the "bind" to "result". "bind" doesn't make sense to carry EAP- Failure. Raj: the consequence of EAP failure is termination of the session. Can we you use Result-Code in the PANA-Terminatin-Request? Yoshi: Could you elaborate. Raj: EAP failure means session termination? Yoshi: EAP failure doesn't always mean termination of the session. Sometimes two EAP authentications may occur (NAP and ISP). The two authentications can be completely independent. Issue36. Re-authentication race condition. Resolution: PAA can always be the winner. Issue35. EP information. Device-Id AVP can have a field to indicate whether the device belongs to PAA or a separate EP. This AVP is carried in PANA-Bind-Request. Yoshi: the format we can discuss on the mailing list. Issue16. Multihoming support. Same or separate session? This is an optimization issue. Proposed resolution: more thorough analysis needed. Until the analysis is done, separation is enough. Alper: I agree with the proposed resolution. How we bind the device id to the pana session. We need a good analysis on this and we should look on the impact on the base design. Mohan: How 802.11 does handle this? Yoshi: separate session if the mac address is different. 802.1x doesn't use the term session. Issue12: authentication in ad-hoc network scenario. Should PANA support ad-hoc network scenario where there can be multiple untrusted nodes in between PaC and PAA. Hannes: we did an experimental of this. This is not a request to do additional requirements, but possibility. Yoshi: How does the PaC find the PAA? Hannes: uses concept from RSVP, router alert option. So it would find the path to the internet and hit Thomas: how is this different to the scenario to the scenario where other nodes can interfere to the communicates? Hannes: different mechanism is the discovery mechanism. This would work only if you would start IPSec. Raj: other requirements say that PaC and PAA must be on the first IP hop. Thomas: are the intermediate nodes ip nodes or l2 nodes? Hannes: ip nodes. We wanted to show the possibilities and results of our experiment. Thomas: if this is out of the scope, why we have this conversation at all. Issue2. Downgrading protection. This is an EAP problem. Use EAP-GSSAPI to negotiate EAP in secure way. Hannes: we should leave this to the EAP, since this is not a PANA issue. Alper: let's send these open issues to the list. Follow up on the discussion on the mailing list. 3. PAA-to-EP protocol considerations: 15 min, Yacine El Mghazli -------------------------------------------------------------------- draft-yacine-pana-paa2ep-prot-eval-00.txt. The objective is to gauge consensus of the WG on the selection of the PAA2EP protocol as proposed in this I-D. Furthermore, solution-oriented discussions will take place based on this proposal (I-D: TBD). Overview. PANA Terminology. EP is in charge to do the access control and enforce packet filters. DI and optionally cryptographic keys may be provided by the PAA to the EP. Discussion objective. Objective today: gauge consensus of the WG on the selection of the PAA_2-EP protocol as proposed in draft-yacine... PAA-2-EP protocol requirements. Secure communication. One-to-many paa-ep relation. Access control information. PAA initiated communication. New pac notification to the paa. PAA-2-EP protocol evaluation summary. The requirements are soft enough. SNMP. COPS-PR. NetConf. Other immature solutions (Diameter, Radius, ForCES). SNMP applicability against the PAA-2-EP Reqs. SNMP applicability re-usable existing MIB objects. SNMP applicability additional PANA-specific MIP specs. Next steps. Selection of the PAA-2-EP protocol. SNMP? Either annex to the PANA protocol draft or into a new wg document. Alper: proposal is to use SNMP. Any feedback? Mohan: we need new MIB variables to the existing? How do we do this? Yacine: some additional objects can be seen as an extension. Yoshi: using snmp is coming from MIDCOM. I'm not sure if this is applicable to PANA. Relates also to accounting. If accouting period is shorter, it is difficult to support this scenario. Yacine: snmp doesn't provide accounting stuff. These mentioned issues are not in the requirements draft. Yoshi: it is ok to mandante snmp, but we should allow other too. Yacine: the wg should just mandate one. Raj: is there any reason to rule out diameter, radius? Provides more functionality and accounting. Yacine: may provide much more functionality in some cases, but my understanding for pana needs are that req are soft enough to allow any protocol. My understanding is that pana needs right now a working solution. Raj: I accept that an AP may not have diameter or cops. Raj: you should also look the work in the nsis wg. We should ask consensus and maybe take to the mailing list. Raj: PAA-2-EP protocol. is snmp sufficient for EP-2-PAA protocol? Alper: how many have read the draft? Around 7. We need more than this for voting. Raj: back to the mailing list. Alper: Yes. 4. PANA-IPsec I-D update: 10 min, Mohan Parthasarathy -------------------------------------------------------------------- draft-ietf-pana-ipsec-00.txt. Objective is to discuss the latest changes (see Revision Log) and confirm consensus. Mohan: this was presented in the last ietf. Open issues. Use of Ipsec tunnel mode instead of transport mode. Pre- shared key derivation for ike. Hannes: the draft is very generic. So this is just fine. Open issues contd. What to do if msk is updated because of re- authentication. Raj: you get the msk of the resulf ot eap. How does the ike take the key? Mohan: pre-shared key into the file. Discussed already on the mailing list. Hannes: several issues. API issue. Key naming, which is confusing. It says that which SA you select. Another is the lifetime. Not only the MSK, but also authorization parameters. You have to make that these are in sync. If new msk is generated some authorizations may have been changed and the ep should know about these. Thomas: some people familiar with ike have raised issues. Security properties. We need to think more about this. Careful analysis required. Talk to Bernard Aboba. Mohan: ike is exactly the same as in 802.11. Thomas: same concerns. Be careful. Alper: we should check keying framework draft. Key naming issue is important for this point. With new msks we get new key names. With option2 we need to differentiate the previous and the new key. We might end up with a key number. Keys are changed inside the one session. Maybe we need an additional attribute to identify the key. 5. PANA state machine considerations: 20 min, Dan Forsberg -------------------------------------------------------------------- The discussions will be based on the state machine diagrams provided at http://danforsberg.info:8080/pana-issues/issue28. Thomas: How many people read the state machine? (7 or so hands). Not many Raj : Has been around for sometime. There has not been feedback on the state machine draft itself. Need feedback. Should it be part of the protocol solution or a separate document ? Not very many folks have read the state machine draft. 6. Unspecified source address discussion: 10min, Chairs -------------------------------------------------------------------- Charter change was requested for the ADs. ADs came back with some concerns about this issue. Some discussions on the mailing list. Current state is to allow the use of unspecified IP address. Thomas: This chart is a bit misleading. Today the clients try the dhcp first. If no dhcp response, allows link-local addresses. Alper: We are not changing that. If deployment wants to do PANA, then the network will not respond to DHCP and start PANA. Thomas: you make an assumption that all clients are updated to use pana. Alper: Obviously. Raj: We didn't change the client behaviour. We are thinking about using link local address. Steve Bellovin: my concern is the concern on the ip stack. This dhcp behaviour is embedded in a lot of code. There are lot of stacks. This is an attempt to reverse the decision that was made before. Thomas: brings to my mind. The existing specs may suggest that the unspecified address is meant to be used only as a source address. Steve: also the case that there are a lot of filters. This behaviour is blocked. I'm concerned about host stacks. Vijay: There is another place where unspecified source address is used. IPv6 duplicate address detection. If this is restricted on link, we should be able to use. Ralph: what will this first bullet mean? Alper: default host behaviour is that the client will use dhcp address configuration. If it fails, host uses link local. Why allow unspecified PaC address. Address depletion attack. Dad attack. James Kempf: Don't use unspecified address. Use the proposed CGA address. You are shifting the dos attack from dhcp to the pac. One can blast the network with packets. Alper: that would be a different type of dos attack. Kempf: I meant paa, I'm sorry. You're sifting the problem around, but not solving it. The fact is that you can't secure the link configuration. Alper: its hard to prevent all dos attacks. Raj: the thread analysis document talks about this. Kempf: if you have address you can more easily do the dos. Alper: no, then the client is already authenticated at that point. How does authentication first giving ip address later help? Attacker identification. Ipsec based access control. Still need secure dad. PANA SA might help SEND. No straight forward benefit of configuring IP after PANA if IPsec-based access control is used. Utility of handling this threat. Does handling this dos threat improve the overall security (how about other dos attacks)? Deployment considerations. In some scenarios, final address assignment depend on the client id. Pre-pana address, post-pana address. Address management with ipsec. Drawbacks. Sending to unspecified ip address. Receiving from unspecified ip address. Fragmentation. Mark Stapp: my question is about existing stacks. Somehow the pana client has to have a configuration in relation to the ipsec. If it is needed or not. If dhcp is in progress. This sounds very complicated (entangled). Pete McCann: in existing deployments today we have good cryptography on existing l2. this is why we need pana. Hardware hackers. There are fixes to fix ip layer to the mac layer. Its always good to check the mac address. This doesn't fix the problem. I still want to see the mac address. Thomas: 2 points. 1. I disagree with your summary. It is biased. Couple of examples. Fragmentation is not that black and white. Yes, you can disable the IP level fragmentation. Eap methods doing the fragmentation has a cost. This leads to a lot of round trips and delays. The performance is not acceptable. go back to the send slide. I think this is an open question if this can be solved by SEND in pana context. Whether send can deal with this or not is an open issue. 2nd point. If there is a need for pana to be able to do some exchanges prior to address assignment. You need to select the isp and then this isp gives the address. I understand this but this is really different than the dos attack scope. Alper: there are two issues. Security and deployment and they are orthogonal to each other. Thomas: you need to be careful with the requirements. Alper: yes, there are two different issues here. Kempf: send may be able to solve DAD issue. But not with unspecified address. Using pana for enabling send is speculative at this point. Don't base your design on that. What is the problem with configuring link-local always and disabling dhcp? Thomas: you are changing the default host behaviour. Does not work if there is no PANA. Alper: we can do that only when we have a full control of the network, then we can make such asumptions. Preconfiguration: do pana first. Kempf: What is the problem with link-locals? Alper: security is the issue. Pete: I still have to check the mac address in the receiver and while sending. This doesn't really seem to solve the problem. Alper: you can send to link-layer destination or use the broadcast. Alper: if the client is using unspecified address, whether the packet is sent to link-layer destination or broadcast is implementation specific. Thomas: client needs to choose an id. Alper: session id chosen by the paa and it's unique. Thomas: We have a bootstrapping problem. Alper: we may need to send another id from client to the paa. So that the paa can differentiate the address. Thomas: this is solvable, but do we want to go into this direction at all? Mark Stapp: We can't trust dad, dhcp, we still need to have this mac checking. Ralph: we can't solve the problem with pana. For example: The use of unspec address with dhcp. You mentioned that authenticated dhcp would solve the dos. Alper: the dad must be secured even when dhcp is used, otherwise we are not solving the problem. Ralph: we have technology available today that some platforms combine dhcp with arp processing for arp security. Alper: not familiar, can you send the info please. Ralph: I'm wondering about the deployment scenario for post-pana address case. We do that today. Post-address authentication. How is this mechanism improving this? Alper. Referring to? Allocation of pre-pana and post-pana addresses is doable today. It's the question about the additional cost. Ralph: if 802.1x is the scenario. Can we require this to avoid these problems? Alper: you can do that. Mohan: what is the cost of using link-local ipv4 address? Alper: without this we could just say that use pana. But if we assume that the client has an ip address first, we have to say that you are using link-locals on the client or you have to have a dhcp server on the access network. Thomas: I have problems of understanding this argument. Its too expensive of having dhcp server? Alper: It is an additional, non-zero, cost. Normally a NAP hosts a dhcp relay. Dhcp servers are at the ISP sites. Now the NAP will need to have a dhcp server and an address pool of its own. Raj: If you want to run pana you would need dhcp on the access link. Ralph: an additional dhcp server on the access link. Each of the backend providers are running separate dhcp server. Thomas: we can migrate pools of addresses to the access link. The problem is which addresses belong to which isp. Question to the WG: do we want to keep allowing use of unspecified ip address by pacs? Do we want to assume pac always has an ip address? Mohan: isn't using link-local addresses just fine? Alper: This could be the case. Thomas: the problem is that if the spec allows unspecified addresses, we have to work all the details and put that on the spec. Raj: It implies that the client has to support both. Alper: we can follow what dhcp did. We have session-id to support this. I don't see any difficulties in the protocol design. Steve: Secure link local address. This is previously unresolved problem. Basically the client stack vendors would go all the pain of implementing this. Or the clients do not support it, which in case the operators can't use this. Making this optional is not a choice. How long does it take to have this deployed into the hundred of thousands of machines. This is not possible. Maybe 8 years. Alper: We will talk about implementations. Raj: I agree with you steve. Alper: The question is if we want to have this optional. Steve: I don't know what benefits there are in this unspec address option. Raj: How many think that unspecified address support is useful? Vote. (alper has results). 7 yes, 13 no. Ralph: Are these questions "either-or"? Alper: Exclusive. Whether we support this or not. Alper: Not clear consensus. Thomas: there are real issues here, but we have to figure them out. Raj: If there is a consensus that we don't use this option, maybe in the future we may extend pana. Thomas: You seem to be concerned that giving the address first has issues. But there are many other dos attacks too. Mark: Just moving the dos attack somewhere else. Greg: we can solve this on pana discovery phase. Don't wait pana to do this. Make sure you have the base draft out. Thomas: Isp selection issue. Can pana along solve this? We have to see if this solution is usable in the context. Service selection, traffic identification need to be explored. Thomas: I suggest we go with the current charter. We need to tease out the issue. We might find a middle ground. Raj: Rough consensus. Go forward with assuming that pac has an ip address. 7. Implementation report: 10 min, Victor Fajardo; 10 min, Hannes Tschofenig -------------------------------------------------------------------- Reports from people who have been implementing the PANA specification. The former implementation was recently published at http://www.opendiameter.org/ Victor fajardo. C++, lgpl, os: linux, windows xp. Diameter and eap implementations are also awailable. Functional architecture. Defines pana api. Independent of eap implementation. Abstracted transport model. Dictionary-based message processing. API. Core object instances. Session based pac and paa objects. Victor: PANA state machine is helpful, but additional documentation is needed. Transport model. Ip stack bypass. PAA architecture. Future plans. Hannes: I will post my slides to the mailing list. 8. Next steps: 5 min, Chairs/Ads -------------------------------------------------------------------- pana state machine discussions will take place. We'll have a security review. Paa-to-ep provisioning protocol details will be worked out. Alper. Thanks, see you in korea. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 21 21:24:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16372 for ; Fri, 21 Nov 2003 21:24:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANNRN-0000bq-DH for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 21:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM2O52j002336 for pana-archive@odin.ietf.org; Fri, 21 Nov 2003 21:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANNRN-0000bb-7g for pana-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 21:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16343 for ; Fri, 21 Nov 2003 21:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANNRK-0005wQ-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 21:24:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANNRK-0005wN-00 for pana-web-archive@ietf.org; Fri, 21 Nov 2003 21:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANNRI-0000b7-TZ; Fri, 21 Nov 2003 21:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANNQy-0000Vw-C7 for pana@optimus.ietf.org; Fri, 21 Nov 2003 21:23:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16331 for ; Fri, 21 Nov 2003 21:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANNQq-0005w1-00 for pana@ietf.org; Fri, 21 Nov 2003 21:23:32 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ANNQq-0005vy-00 for pana@ietf.org; Fri, 21 Nov 2003 21:23:32 -0500 Date: Fri, 21 Nov 2003 18:24:32 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] Draft meeting minutes Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit See below for the draft meeting minutes from IETF 58 PANA meeting. Please let us know if there is a need to correct/add anything. Alper Protocol for Carrying Authentication for Network Access WG (pana) Tuesday, November 11 at 0900-1130 ================================== CHAIRS: Basavaraj Patil Alper Yegin Note Takers: Dan Forsberg, Mohan Parthasarathy AGENDA: 1. Preliminaries (bluesheets, minute takers, agenda bashing): 5 min Chairs -------------------------------------------------------------------- Dan will take minutes. Mohan will take minutes. Raj went through the agenda and document statuses. STATUS of WG I-Ds: - draft-ietf-pana-usage-scenarios-06.txt WG last call completed on 3/11/03. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-requirements-07.txt WG last call completed on 6/12/03. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-threats-eval-04.txt WG last call completed on 5/1/03. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-pana-02.txt Work in progress. I-D will be discussed at IETF 58. - draft-ietf-pana-ipsec-00.txt Work in progress. I-D will be discussed at IETF 58. 2. PANA protocol update and open issues: 30 min, Yoshihiro Ohba -------------------------------------------------------------------- draft-ietf-pana-pana-02.txt. See "Change History" section of the draft for the list of issues closed in this revision. Detailed issue descriptions can be found at http://danforsberg.info:8080/pana-issues/ Newly closed issues and currently open issues will be covered in this presentation for confirming/achieving consensus. Dan: change the URL of open issues on the first slide (take away the "www"). Closed issues: Issue22, R-flag is used to distinguish request and answer. Issue23, shared code space with Diameter. Issue17, PANA-Error is defined. Issue24, avp alignment rule is added. Issue18, PANA-Termination-Cause AVP values are defined. Issue19, Result-Code AVP values are defined. Other issues: Issue20. Issue25. Relates to ISP selection. Issue8. Issue31. Issue32. Issue33. Issues21, 26, 30. Issue20. Retransmission timers and counters. Two classes for retransmission values: PANA-PAA-Discover and other messages. Issue25. Service Profile names. Define two new AVPs. NAP-Information and ISP-Information AVPs. Defined a new flag (S). F-flag is not needed anymore. PAA advertises NAPs and ISPs (information AVPs). Open issues: Issue34. NAP and ISP authentications. Proposed solution: use single lifetime (the smallest one). Both NAP and ISP re-authentications happen at the same time. Issue37. Unknown realm propagation. Should unknown realm AAA message routing error be propagated to PaC. Direct interface between PAA and AAA would be needed. Alper: Yoshi, do we know how other EAP lower layers behave in this case? Yoshi: IEEE 802.1x doesn't carry any unknown errors. Raj: Is it required to use EAP layer? Can't we send unknow error message through PANA? You need direct interface between PANA and AAA? Or is it an EAP state machine problem? Yoshi: EAP state machine doesn't allow this. My opinion is that this complicates the implementation. Raj: ok. Mohan: How can PANA error message communicate this problem? Raj: You introduce PANA-Error message, why not use that? Yoshi: We can use PANA-Error message to propagate msg from PAA to PaC. The problem is between AAA and PAA. Raj: Does this mean that we need to do enhancement to the AAA spec? Yoshi: no changes to the spec., but to the API perhaps. Raj: let's take this into further discussions. Issue29: EAP Failure and PANA-Bind-Request. Problematic with NAP and ISP authentication. Single PANA-Termination-Request can't be used. We may want to change the "bind" to "result". "bind" doesn't make sense to carry EAP- Failure. Raj: the consequence of EAP failure is termination of the session. Can we you use Result-Code in the PANA-Terminatin-Request? Yoshi: Could you elaborate. Raj: EAP failure means session termination? Yoshi: EAP failure doesn't always mean termination of the session. Sometimes two EAP authentications may occur (NAP and ISP). The two authentications can be completely independent. Issue36. Re-authentication race condition. Resolution: PAA can always be the winner. Issue35. EP information. Device-Id AVP can have a field to indicate whether the device belongs to PAA or a separate EP. This AVP is carried in PANA-Bind-Request. Yoshi: the format we can discuss on the mailing list. Issue16. Multihoming support. Same or separate session? This is an optimization issue. Proposed resolution: more thorough analysis needed. Until the analysis is done, separation is enough. Alper: I agree with the proposed resolution. How we bind the device id to the pana session. We need a good analysis on this and we should look on the impact on the base design. Mohan: How 802.11 does handle this? Yoshi: separate session if the mac address is different. 802.1x doesn't use the term session. Issue12: authentication in ad-hoc network scenario. Should PANA support ad-hoc network scenario where there can be multiple untrusted nodes in between PaC and PAA. Hannes: we did an experimental of this. This is not a request to do additional requirements, but possibility. Yoshi: How does the PaC find the PAA? Hannes: uses concept from RSVP, router alert option. So it would find the path to the internet and hit Thomas: how is this different to the scenario to the scenario where other nodes can interfere to the communicates? Hannes: different mechanism is the discovery mechanism. This would work only if you would start IPSec. Raj: other requirements say that PaC and PAA must be on the first IP hop. Thomas: are the intermediate nodes ip nodes or l2 nodes? Hannes: ip nodes. We wanted to show the possibilities and results of our experiment. Thomas: if this is out of the scope, why we have this conversation at all. Issue2. Downgrading protection. This is an EAP problem. Use EAP-GSSAPI to negotiate EAP in secure way. Hannes: we should leave this to the EAP, since this is not a PANA issue. Alper: let's send these open issues to the list. Follow up on the discussion on the mailing list. 3. PAA-to-EP protocol considerations: 15 min, Yacine El Mghazli -------------------------------------------------------------------- draft-yacine-pana-paa2ep-prot-eval-00.txt. The objective is to gauge consensus of the WG on the selection of the PAA2EP protocol as proposed in this I-D. Furthermore, solution-oriented discussions will take place based on this proposal (I-D: TBD). Overview. PANA Terminology. EP is in charge to do the access control and enforce packet filters. DI and optionally cryptographic keys may be provided by the PAA to the EP. Discussion objective. Objective today: gauge consensus of the WG on the selection of the PAA_2-EP protocol as proposed in draft-yacine... PAA-2-EP protocol requirements. Secure communication. One-to-many paa-ep relation. Access control information. PAA initiated communication. New pac notification to the paa. PAA-2-EP protocol evaluation summary. The requirements are soft enough. SNMP. COPS-PR. NetConf. Other immature solutions (Diameter, Radius, ForCES). SNMP applicability against the PAA-2-EP Reqs. SNMP applicability re-usable existing MIB objects. SNMP applicability additional PANA-specific MIP specs. Next steps. Selection of the PAA-2-EP protocol. SNMP? Either annex to the PANA protocol draft or into a new wg document. Alper: proposal is to use SNMP. Any feedback? Mohan: we need new MIB variables to the existing? How do we do this? Yacine: some additional objects can be seen as an extension. Yoshi: using snmp is coming from MIDCOM. I'm not sure if this is applicable to PANA. Relates also to accounting. If accouting period is shorter, it is difficult to support this scenario. Yacine: snmp doesn't provide accounting stuff. These mentioned issues are not in the requirements draft. Yoshi: it is ok to mandante snmp, but we should allow other too. Yacine: the wg should just mandate one. Raj: is there any reason to rule out diameter, radius? Provides more functionality and accounting. Yacine: may provide much more functionality in some cases, but my understanding for pana needs are that req are soft enough to allow any protocol. My understanding is that pana needs right now a working solution. Raj: I accept that an AP may not have diameter or cops. Raj: you should also look the work in the nsis wg. We should ask consensus and maybe take to the mailing list. Raj: PAA-2-EP protocol. is snmp sufficient for EP-2-PAA protocol? Alper: how many have read the draft? Around 7. We need more than this for voting. Raj: back to the mailing list. Alper: Yes. 4. PANA-IPsec I-D update: 10 min, Mohan Parthasarathy -------------------------------------------------------------------- draft-ietf-pana-ipsec-00.txt. Objective is to discuss the latest changes (see Revision Log) and confirm consensus. Mohan: this was presented in the last ietf. Open issues. Use of Ipsec tunnel mode instead of transport mode. Pre- shared key derivation for ike. Hannes: the draft is very generic. So this is just fine. Open issues contd. What to do if msk is updated because of re- authentication. Raj: you get the msk of the resulf ot eap. How does the ike take the key? Mohan: pre-shared key into the file. Discussed already on the mailing list. Hannes: several issues. API issue. Key naming, which is confusing. It says that which SA you select. Another is the lifetime. Not only the MSK, but also authorization parameters. You have to make that these are in sync. If new msk is generated some authorizations may have been changed and the ep should know about these. Thomas: some people familiar with ike have raised issues. Security properties. We need to think more about this. Careful analysis required. Talk to Bernard Aboba. Mohan: ike is exactly the same as in 802.11. Thomas: same concerns. Be careful. Alper: we should check keying framework draft. Key naming issue is important for this point. With new msks we get new key names. With option2 we need to differentiate the previous and the new key. We might end up with a key number. Keys are changed inside the one session. Maybe we need an additional attribute to identify the key. 5. PANA state machine considerations: 20 min, Dan Forsberg -------------------------------------------------------------------- The discussions will be based on the state machine diagrams provided at http://danforsberg.info:8080/pana-issues/issue28. Thomas: How many people read the state machine? (7 or so hands). Not many Raj : Has been around for sometime. There has not been feedback on the state machine draft itself. Need feedback. Should it be part of the protocol solution or a separate document ? Not very many folks have read the state machine draft. 6. Unspecified source address discussion: 10min, Chairs -------------------------------------------------------------------- Charter change was requested for the ADs. ADs came back with some concerns about this issue. Some discussions on the mailing list. Current state is to allow the use of unspecified IP address. Thomas: This chart is a bit misleading. Today the clients try the dhcp first. If no dhcp response, allows link-local addresses. Alper: We are not changing that. If deployment wants to do PANA, then the network will not respond to DHCP and start PANA. Thomas: you make an assumption that all clients are updated to use pana. Alper: Obviously. Raj: We didn't change the client behaviour. We are thinking about using link local address. Steve Bellovin: my concern is the concern on the ip stack. This dhcp behaviour is embedded in a lot of code. There are lot of stacks. This is an attempt to reverse the decision that was made before. Thomas: brings to my mind. The existing specs may suggest that the unspecified address is meant to be used only as a source address. Steve: also the case that there are a lot of filters. This behaviour is blocked. I'm concerned about host stacks. Vijay: There is another place where unspecified source address is used. IPv6 duplicate address detection. If this is restricted on link, we should be able to use. Ralph: what will this first bullet mean? Alper: default host behaviour is that the client will use dhcp address configuration. If it fails, host uses link local. Why allow unspecified PaC address. Address depletion attack. Dad attack. James Kempf: Don't use unspecified address. Use the proposed CGA address. You are shifting the dos attack from dhcp to the pac. One can blast the network with packets. Alper: that would be a different type of dos attack. Kempf: I meant paa, I'm sorry. You're sifting the problem around, but not solving it. The fact is that you can't secure the link configuration. Alper: its hard to prevent all dos attacks. Raj: the thread analysis document talks about this. Kempf: if you have address you can more easily do the dos. Alper: no, then the client is already authenticated at that point. How does authentication first giving ip address later help? Attacker identification. Ipsec based access control. Still need secure dad. PANA SA might help SEND. No straight forward benefit of configuring IP after PANA if IPsec-based access control is used. Utility of handling this threat. Does handling this dos threat improve the overall security (how about other dos attacks)? Deployment considerations. In some scenarios, final address assignment depend on the client id. Pre-pana address, post-pana address. Address management with ipsec. Drawbacks. Sending to unspecified ip address. Receiving from unspecified ip address. Fragmentation. Mark Stapp: my question is about existing stacks. Somehow the pana client has to have a configuration in relation to the ipsec. If it is needed or not. If dhcp is in progress. This sounds very complicated (entangled). Pete McCann: in existing deployments today we have good cryptography on existing l2. this is why we need pana. Hardware hackers. There are fixes to fix ip layer to the mac layer. Its always good to check the mac address. This doesn't fix the problem. I still want to see the mac address. Thomas: 2 points. 1. I disagree with your summary. It is biased. Couple of examples. Fragmentation is not that black and white. Yes, you can disable the IP level fragmentation. Eap methods doing the fragmentation has a cost. This leads to a lot of round trips and delays. The performance is not acceptable. go back to the send slide. I think this is an open question if this can be solved by SEND in pana context. Whether send can deal with this or not is an open issue. 2nd point. If there is a need for pana to be able to do some exchanges prior to address assignment. You need to select the isp and then this isp gives the address. I understand this but this is really different than the dos attack scope. Alper: there are two issues. Security and deployment and they are orthogonal to each other. Thomas: you need to be careful with the requirements. Alper: yes, there are two different issues here. Kempf: send may be able to solve DAD issue. But not with unspecified address. Using pana for enabling send is speculative at this point. Don't base your design on that. What is the problem with configuring link-local always and disabling dhcp? Thomas: you are changing the default host behaviour. Does not work if there is no PANA. Alper: we can do that only when we have a full control of the network, then we can make such asumptions. Preconfiguration: do pana first. Kempf: What is the problem with link-locals? Alper: security is the issue. Pete: I still have to check the mac address in the receiver and while sending. This doesn't really seem to solve the problem. Alper: you can send to link-layer destination or use the broadcast. Alper: if the client is using unspecified address, whether the packet is sent to link-layer destination or broadcast is implementation specific. Thomas: client needs to choose an id. Alper: session id chosen by the paa and it's unique. Thomas: We have a bootstrapping problem. Alper: we may need to send another id from client to the paa. So that the paa can differentiate the address. Thomas: this is solvable, but do we want to go into this direction at all? Mark Stapp: We can't trust dad, dhcp, we still need to have this mac checking. Ralph: we can't solve the problem with pana. For example: The use of unspec address with dhcp. You mentioned that authenticated dhcp would solve the dos. Alper: the dad must be secured even when dhcp is used, otherwise we are not solving the problem. Ralph: we have technology available today that some platforms combine dhcp with arp processing for arp security. Alper: not familiar, can you send the info please. Ralph: I'm wondering about the deployment scenario for post-pana address case. We do that today. Post-address authentication. How is this mechanism improving this? Alper. Referring to? Allocation of pre-pana and post-pana addresses is doable today. It's the question about the additional cost. Ralph: if 802.1x is the scenario. Can we require this to avoid these problems? Alper: you can do that. Mohan: what is the cost of using link-local ipv4 address? Alper: without this we could just say that use pana. But if we assume that the client has an ip address first, we have to say that you are using link-locals on the client or you have to have a dhcp server on the access network. Thomas: I have problems of understanding this argument. Its too expensive of having dhcp server? Alper: It is an additional, non-zero, cost. Normally a NAP hosts a dhcp relay. Dhcp servers are at the ISP sites. Now the NAP will need to have a dhcp server and an address pool of its own. Raj: If you want to run pana you would need dhcp on the access link. Ralph: an additional dhcp server on the access link. Each of the backend providers are running separate dhcp server. Thomas: we can migrate pools of addresses to the access link. The problem is which addresses belong to which isp. Question to the WG: do we want to keep allowing use of unspecified ip address by pacs? Do we want to assume pac always has an ip address? Mohan: isn't using link-local addresses just fine? Alper: This could be the case. Thomas: the problem is that if the spec allows unspecified addresses, we have to work all the details and put that on the spec. Raj: It implies that the client has to support both. Alper: we can follow what dhcp did. We have session-id to support this. I don't see any difficulties in the protocol design. Steve: Secure link local address. This is previously unresolved problem. Basically the client stack vendors would go all the pain of implementing this. Or the clients do not support it, which in case the operators can't use this. Making this optional is not a choice. How long does it take to have this deployed into the hundred of thousands of machines. This is not possible. Maybe 8 years. Alper: We will talk about implementations. Raj: I agree with you steve. Alper: The question is if we want to have this optional. Steve: I don't know what benefits there are in this unspec address option. Raj: How many think that unspecified address support is useful? Vote. (alper has results). 7 yes, 13 no. Ralph: Are these questions "either-or"? Alper: Exclusive. Whether we support this or not. Alper: Not clear consensus. Thomas: there are real issues here, but we have to figure them out. Raj: If there is a consensus that we don't use this option, maybe in the future we may extend pana. Thomas: You seem to be concerned that giving the address first has issues. But there are many other dos attacks too. Mark: Just moving the dos attack somewhere else. Greg: we can solve this on pana discovery phase. Don't wait pana to do this. Make sure you have the base draft out. Thomas: Isp selection issue. Can pana along solve this? We have to see if this solution is usable in the context. Service selection, traffic identification need to be explored. Thomas: I suggest we go with the current charter. We need to tease out the issue. We might find a middle ground. Raj: Rough consensus. Go forward with assuming that pac has an ip address. 7. Implementation report: 10 min, Victor Fajardo; 10 min, Hannes Tschofenig -------------------------------------------------------------------- Reports from people who have been implementing the PANA specification. The former implementation was recently published at http://www.opendiameter.org/ Victor fajardo. C++, lgpl, os: linux, windows xp. Diameter and eap implementations are also awailable. Functional architecture. Defines pana api. Independent of eap implementation. Abstracted transport model. Dictionary-based message processing. API. Core object instances. Session based pac and paa objects. Victor: PANA state machine is helpful, but additional documentation is needed. Transport model. Ip stack bypass. PAA architecture. Future plans. Hannes: I will post my slides to the mailing list. 8. Next steps: 5 min, Chairs/Ads -------------------------------------------------------------------- pana state machine discussions will take place. We'll have a security review. Paa-to-ep provisioning protocol details will be worked out. Alper. Thanks, see you in korea. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 24 03:24:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29464 for ; Mon, 24 Nov 2003 03:24:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOC0m-0000HH-Qw; Mon, 24 Nov 2003 03:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANNsm-000243-1s for pana@optimus.ietf.org; Fri, 21 Nov 2003 21:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16959 for ; Fri, 21 Nov 2003 21:52:10 -0500 (EST) From: Yoshihiro.Ohba@tais.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANNsj-0006Gp-00 for pana@ietf.org; Fri, 21 Nov 2003 21:52:21 -0500 Received: from zmsvr04.tais.net ([12.106.80.12]) by ietf-mx with esmtp (Exim 4.12) id 1ANNsi-0006Gk-00 for pana@ietf.org; Fri, 21 Nov 2003 21:52:20 -0500 Subject: Re: [Pana] IP address configuration To: mohanp@sbcglobal.net Cc: "Bernard Aboba" , "Alper Yegin" , "Jari Arkko" , "James Kempf" , pana@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 21 Nov 2003 18:51:44 -0800 X-MIMETrack: Serialize by Router on zmsvr04/tais_external(Release 5.0.9a |January 7, 2002) at 11/21/2003 06:52:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , With regard to the inner address assignment through IKE or IKEv2, just use the method(s) available for tunnel mode SA. I don't think we have to support IP-in-IP transport mode SA just because a particular address configuration method may not be supported by tunnel mode SA. Yoshihiro Ohba "Mohan Parthasarathy" To: "Alper Yegin" , , "Bernard Aboba" l.net> , "James Kempf" Sent by: Subject: Re: [Pana] IP address configuration pana-admin@ietf. org 2003/11/21 17:38 > > > > >> the PANA-Bind-Request message. PaC should attempt this configuration > > inside > >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address > >> autoconfiguration or DHCP can be used. > >> > > As i clarified in my other email, you don't setup the IPsec selectors until > > you have > > acquired the "routeable" (inner) address. And these addresses are used as > > selectors > > in the SPD. > > > >> Both pre-PANA and post-PANA addresses are used by the PaC at the same > > time, > >> though post-PANA addresses only appear inside the tunnel. A post-PANA > >> address has no significance for the PANA session or access control. > >> > > For tunnel mode SA, the outer addresses are not significant for access > > control. > > The inner addresses are used for access control. SPD selectors are inner > > addresses. > > Apparently I was still thinking in terms of IP-IP transport mode (the older > version of the draft). > Yes. The older version of the draft used just the link-local address as selectors. So, it is possible to do IPsec as soon as you are done with PANA. > Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's phase > 2 identity, so that the inner IP addresses can be anything. And run address > autoconfiguration or DHCP inside the tunnel. > I am not sure whether the EP would accept the range. EP may just accept only one address as it lets any authenticated nodes spoof each other very easily. I have only seen ranges used by VPN gateways and not sure whether any host uses it or not. Again, if we can fix this in other ways e.g. using IP-IP transport mode, we should do that. > > > > >> If pre-PANA and post-PANA addresses are the same, they will be used both > >> inside and outside the tunnel (any issues with IPsec processing?). This > > can > > > > Some implementations have problem with this when the packets are destined to > > the tunnel end point address itself. > > Does this have anyting to do with the specification, or the intended use of > it? Or, is this simple a shortcoming or a bug in some implementations? > It is just an implementation artefact. I send packets to "DEST", route lookup returns a tunnel interface, which in turn encapsulated with outer header "DEST" , re-enters IP and loops again. This comes as a side effect of implementing IPsec tunnel mode SA as an "interface". This is not a real issue here as we can always bypass IPsec for messages sent to EP. -mohan > > Here, these will be PANA messages > > which will anway be bypassed (mentioned in the draft) i.e no IPsec for PANA > > messages flowing between PaC and PAA/EP. > > > > Alper > > > > > >> be the case when the client has a static IP address, or the DHCP address > >> assignment does not depend on the client identity. > >> > >> Comments? > >> > >> Alper > >> > > mohan > > > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 24 03:24:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29479 for ; Mon, 24 Nov 2003 03:24:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOC0r-0000Hx-LM for pana-archive@odin.ietf.org; Mon, 24 Nov 2003 03:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO8O5C4001108 for pana-archive@odin.ietf.org; Mon, 24 Nov 2003 03:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOC0q-0000Hn-HO for pana-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 03:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29457 for ; Mon, 24 Nov 2003 03:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOC0o-0000LD-00 for pana-web-archive@ietf.org; Mon, 24 Nov 2003 03:24:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOC0n-0000L9-00 for pana-web-archive@ietf.org; Mon, 24 Nov 2003 03:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOC0m-0000HH-Qw; Mon, 24 Nov 2003 03:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANNsm-000243-1s for pana@optimus.ietf.org; Fri, 21 Nov 2003 21:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16959 for ; Fri, 21 Nov 2003 21:52:10 -0500 (EST) From: Yoshihiro.Ohba@tais.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANNsj-0006Gp-00 for pana@ietf.org; Fri, 21 Nov 2003 21:52:21 -0500 Received: from zmsvr04.tais.net ([12.106.80.12]) by ietf-mx with esmtp (Exim 4.12) id 1ANNsi-0006Gk-00 for pana@ietf.org; Fri, 21 Nov 2003 21:52:20 -0500 Subject: Re: [Pana] IP address configuration To: mohanp@sbcglobal.net Cc: "Bernard Aboba" , "Alper Yegin" , "Jari Arkko" , "James Kempf" , pana@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 21 Nov 2003 18:51:44 -0800 X-MIMETrack: Serialize by Router on zmsvr04/tais_external(Release 5.0.9a |January 7, 2002) at 11/21/2003 06:52:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , With regard to the inner address assignment through IKE or IKEv2, just use the method(s) available for tunnel mode SA. I don't think we have to support IP-in-IP transport mode SA just because a particular address configuration method may not be supported by tunnel mode SA. Yoshihiro Ohba "Mohan Parthasarathy" To: "Alper Yegin" , , "Bernard Aboba" l.net> , "James Kempf" Sent by: Subject: Re: [Pana] IP address configuration pana-admin@ietf. org 2003/11/21 17:38 > > > > >> the PANA-Bind-Request message. PaC should attempt this configuration > > inside > >> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address > >> autoconfiguration or DHCP can be used. > >> > > As i clarified in my other email, you don't setup the IPsec selectors until > > you have > > acquired the "routeable" (inner) address. And these addresses are used as > > selectors > > in the SPD. > > > >> Both pre-PANA and post-PANA addresses are used by the PaC at the same > > time, > >> though post-PANA addresses only appear inside the tunnel. A post-PANA > >> address has no significance for the PANA session or access control. > >> > > For tunnel mode SA, the outer addresses are not significant for access > > control. > > The inner addresses are used for access control. SPD selectors are inner > > addresses. > > Apparently I was still thinking in terms of IP-IP transport mode (the older > version of the draft). > Yes. The older version of the draft used just the link-local address as selectors. So, it is possible to do IPsec as soon as you are done with PANA. > Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's phase > 2 identity, so that the inner IP addresses can be anything. And run address > autoconfiguration or DHCP inside the tunnel. > I am not sure whether the EP would accept the range. EP may just accept only one address as it lets any authenticated nodes spoof each other very easily. I have only seen ranges used by VPN gateways and not sure whether any host uses it or not. Again, if we can fix this in other ways e.g. using IP-IP transport mode, we should do that. > > > > >> If pre-PANA and post-PANA addresses are the same, they will be used both > >> inside and outside the tunnel (any issues with IPsec processing?). This > > can > > > > Some implementations have problem with this when the packets are destined to > > the tunnel end point address itself. > > Does this have anyting to do with the specification, or the intended use of > it? Or, is this simple a shortcoming or a bug in some implementations? > It is just an implementation artefact. I send packets to "DEST", route lookup returns a tunnel interface, which in turn encapsulated with outer header "DEST" , re-enters IP and loops again. This comes as a side effect of implementing IPsec tunnel mode SA as an "interface". This is not a real issue here as we can always bypass IPsec for messages sent to EP. -mohan > > Here, these will be PANA messages > > which will anway be bypassed (mentioned in the draft) i.e no IPsec for PANA > > messages flowing between PaC and PAA/EP. > > > > Alper > > > > > >> be the case when the client has a static IP address, or the DHCP address > >> assignment does not depend on the client identity. > >> > >> Comments? > >> > >> Alper > >> > > mohan > > > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 24 08:24:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06987 for ; Mon, 24 Nov 2003 08:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhM-0007XY-M4; Mon, 24 Nov 2003 08:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGf9-0007EL-WB for pana@optimus.ietf.org; Mon, 24 Nov 2003 08:22:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06789 for ; Mon, 24 Nov 2003 08:21:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGf8-0004YQ-00 for pana@ietf.org; Mon, 24 Nov 2003 08:21:58 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AOGf6-0004Xr-00 for pana@ietf.org; Mon, 24 Nov 2003 08:21:58 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id hAODLC9s006005; Mon, 24 Nov 2003 14:21:13 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003112414211048:3994 ; Mon, 24 Nov 2003 14:21:10 +0100 Message-ID: <3FC205C6.3020902@alcatel.fr> Date: Mon, 24 Nov 2003 14:21:10 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: pana@ietf.org Cc: MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba , Julien Bournelle X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/24/2003 14:21:10, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/24/2003 14:21:12, Serialize complete at 11/24/2003 14:21:12 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: 7bit Subject: [Pana] PAA-2-EP protocol requirements Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit At IETF58 Minneapolis, several comments were made asking for the PAA-2-EP protocol to support additional characteristics (accounting, heartbeat, etc.). these features were discussed earlier in the PAA-2-EP design process, but it was finaly decided that they are NOT REQUIRED. in order to move forward on this charter item (protocol choice, extensions, etc.) and based on the reactions at the last IETF meeting, I think the working group should clarify the PANA needs here and reach consensus on the PAA-2-EP protocol requirements. so far the official requirements for this interface, as stated in the lattest PANA requirements doc, are the following: 1) EP Configuration information: The PAA-2-EP protocol must carry DI-based filters and keying material. 2) One-to-many PAA-EP relation: This means that there might be multiple EPs per PAA. 3) Secure Communication: The PAA-EP protocol must provide for message authentication, confidentiality, and integrity. 4) New PaC Notification: The PAA-2-EP protocol may allow the EP to notify a new PaC to the PAA. below are some other PAA-2-EP functionnalities (open list). should we consider them as also required ? not required at all ? supported elsewhere ? any alternative ? a) Inactive peer detection: The protocol used between PAA and EP should be able to detect inactive peer within an appropriate time period. This can be achieved by having both the EP and remote PAA constantly verify their connection to each other via keep-alive messages: a heartbeat in fact. b) Stateful approach: The protocol must allow to maintain some states in the PAA in order for an EP that went down and came back up, or an EP that is being introduced in the network to (re-)synchronize with the PAA. In general terms, the PAA-EP protocol needs to support the stateful model between the PAA and the EP(s) and some other mechanism for the EP to learn the policies currently in effect on that access network. c) Accounting/Feedback from the EPs: The PAA must have an efficient way to to get the accounting information of PaC from EP since the PAA may be a client of the AAA backend infrastructure. d) ???? thanks, Yacine El Mghazli _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 24 08:24:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07056 for ; Mon, 24 Nov 2003 08:24:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhX-0007da-M7 for pana-archive@odin.ietf.org; Mon, 24 Nov 2003 08:24:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODOR3I029352 for pana-archive@odin.ietf.org; Mon, 24 Nov 2003 08:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhW-0007bh-0m for pana-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 08:24:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06919 for ; Mon, 24 Nov 2003 08:24:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGhU-0004dz-00 for pana-web-archive@ietf.org; Mon, 24 Nov 2003 08:24:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOGhU-0004df-00 for pana-web-archive@ietf.org; Mon, 24 Nov 2003 08:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhM-0007XY-M4; Mon, 24 Nov 2003 08:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGf9-0007EL-WB for pana@optimus.ietf.org; Mon, 24 Nov 2003 08:22:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06789 for ; Mon, 24 Nov 2003 08:21:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGf8-0004YQ-00 for pana@ietf.org; Mon, 24 Nov 2003 08:21:58 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AOGf6-0004Xr-00 for pana@ietf.org; Mon, 24 Nov 2003 08:21:58 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id hAODLC9s006005; Mon, 24 Nov 2003 14:21:13 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003112414211048:3994 ; Mon, 24 Nov 2003 14:21:10 +0100 Message-ID: <3FC205C6.3020902@alcatel.fr> Date: Mon, 24 Nov 2003 14:21:10 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: pana@ietf.org Cc: MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba , Julien Bournelle X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/24/2003 14:21:10, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/24/2003 14:21:12, Serialize complete at 11/24/2003 14:21:12 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: 7bit Subject: [Pana] PAA-2-EP protocol requirements Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit At IETF58 Minneapolis, several comments were made asking for the PAA-2-EP protocol to support additional characteristics (accounting, heartbeat, etc.). these features were discussed earlier in the PAA-2-EP design process, but it was finaly decided that they are NOT REQUIRED. in order to move forward on this charter item (protocol choice, extensions, etc.) and based on the reactions at the last IETF meeting, I think the working group should clarify the PANA needs here and reach consensus on the PAA-2-EP protocol requirements. so far the official requirements for this interface, as stated in the lattest PANA requirements doc, are the following: 1) EP Configuration information: The PAA-2-EP protocol must carry DI-based filters and keying material. 2) One-to-many PAA-EP relation: This means that there might be multiple EPs per PAA. 3) Secure Communication: The PAA-EP protocol must provide for message authentication, confidentiality, and integrity. 4) New PaC Notification: The PAA-2-EP protocol may allow the EP to notify a new PaC to the PAA. below are some other PAA-2-EP functionnalities (open list). should we consider them as also required ? not required at all ? supported elsewhere ? any alternative ? a) Inactive peer detection: The protocol used between PAA and EP should be able to detect inactive peer within an appropriate time period. This can be achieved by having both the EP and remote PAA constantly verify their connection to each other via keep-alive messages: a heartbeat in fact. b) Stateful approach: The protocol must allow to maintain some states in the PAA in order for an EP that went down and came back up, or an EP that is being introduced in the network to (re-)synchronize with the PAA. In general terms, the PAA-EP protocol needs to support the stateful model between the PAA and the EP(s) and some other mechanism for the EP to learn the policies currently in effect on that access network. c) Accounting/Feedback from the EPs: The PAA must have an efficient way to to get the accounting information of PaC from EP since the PAA may be a client of the AAA backend infrastructure. d) ???? thanks, Yacine El Mghazli _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 24 15:59:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29366 for ; Mon, 24 Nov 2003 15:59:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONnQ-0000w3-Je; Mon, 24 Nov 2003 15:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONnE-0000ve-7S for pana@optimus.ietf.org; Mon, 24 Nov 2003 15:58:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29287 for ; Mon, 24 Nov 2003 15:58:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONnC-0004X2-00 for pana@ietf.org; Mon, 24 Nov 2003 15:58:46 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AONnB-0004Wz-00 for pana@ietf.org; Mon, 24 Nov 2003 15:58:45 -0500 Date: Mon, 24 Nov 2003 12:59:45 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: , CC: Bernard Aboba , Jari Arkko , James Kempf , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm trying to figure out how we can: - just maintain one DI for the PaC, and that is used as the local end-point of the IPsec tunnel (when IPsec-based access control is used) - any other IP address can be configured inside this tunnel. Router discovery, ND, and DHCP can be run inside the tunnel. These IP addresses should not be used as PANA DI. I think supporting DHCP-based or autoconf based address configuration is required. Additional methods, like IKE-based address config, is nice to have. This is so that the impact of PANA on the access network architecture is minimal. It sounds like both IP-in-IP transport mode SA and tunnel mode SA with wildcard phase 2 identities support these... Alper > With regard to the inner address assignment through IKE or IKEv2, > just use the method(s) available for tunnel mode SA. > > I don't think we have to support IP-in-IP transport mode SA just because a > particular address configuration > method may not be supported by tunnel mode SA. > > Yoshihiro Ohba > > > > > > > "Mohan > Parthasarathy" To: "Alper Yegin" > , > , "Bernard Aboba" > l.net> , "James > Kempf" > Sent by: Subject: Re: [Pana] IP address > configuration > pana-admin@ietf. > org > > > 2003/11/21 17:38 > > > > > > > > >> >>> >>>> the PANA-Bind-Request message. PaC should attempt this configuration >>> inside >>>> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless > address >>>> autoconfiguration or DHCP can be used. >>>> >>> As i clarified in my other email, you don't setup the IPsec selectors > until >>> you have >>> acquired the "routeable" (inner) address. And these addresses are used > as >>> selectors >>> in the SPD. >>> >>>> Both pre-PANA and post-PANA addresses are used by the PaC at the same >>> time, >>>> though post-PANA addresses only appear inside the tunnel. A post-PANA >>>> address has no significance for the PANA session or access control. >>>> >>> For tunnel mode SA, the outer addresses are not significant for access >>> control. >>> The inner addresses are used for access control. SPD selectors are > inner >>> addresses. >> >> Apparently I was still thinking in terms of IP-IP transport mode (the > older >> version of the draft). >> > Yes. The older version of the draft used just the link-local address as > selectors. > So, it is possible to do IPsec as soon as you are done with PANA. > >> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's > phase >> 2 identity, so that the inner IP addresses can be anything. And run > address >> autoconfiguration or DHCP inside the tunnel. >> > I am not sure whether the EP would accept the range. EP may just accept > only > one address as it lets any authenticated nodes spoof each other very > easily. > I have only seen ranges used by VPN gateways and not sure whether any > host uses it or not. Again, if we can fix this in other ways e.g. using > IP-IP transport mode, we should do that. > >> >>> >>>> If pre-PANA and post-PANA addresses are the same, they will be used > both >>>> inside and outside the tunnel (any issues with IPsec processing?). > This >>> can >>> >>> Some implementations have problem with this when the packets are > destined to >>> the tunnel end point address itself. >> >> Does this have anyting to do with the specification, or the intended use > of >> it? Or, is this simple a shortcoming or a bug in some implementations? >> > It is just an implementation artefact. I send packets to "DEST", route > lookup > returns a tunnel interface, which in turn encapsulated with outer header > "DEST" , re-enters IP and loops again. This comes as a side effect of > implementing IPsec tunnel mode SA as an "interface". This is not > a real issue here as we can always bypass IPsec for messages sent > to EP. > > -mohan > >>> Here, these will be PANA messages >>> which will anway be bypassed (mentioned in the draft) i.e no IPsec for > PANA >>> messages flowing between PaC and PAA/EP. >> >> >> >> Alper >> >> >>> >>>> be the case when the client has a static IP address, or the DHCP > address >>>> assignment does not depend on the client identity. >>>> >>>> Comments? >>>> >>>> Alper >>>> >>> mohan >>> >>>> >>>> >>>> _______________________________________________ >>>> Pana mailing list >>>> Pana@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pana >>> >>> >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pana >>> >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 24 15:59:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29381 for ; Mon, 24 Nov 2003 15:59:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONnX-0000wr-3k for pana-archive@odin.ietf.org; Mon, 24 Nov 2003 15:59:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKx7ip003639 for pana-archive@odin.ietf.org; Mon, 24 Nov 2003 15:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONnW-0000wc-Uo for pana-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:59:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29328 for ; Mon, 24 Nov 2003 15:58:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONnS-0004XD-00 for pana-web-archive@ietf.org; Mon, 24 Nov 2003 15:59:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONnS-0004XA-00 for pana-web-archive@ietf.org; Mon, 24 Nov 2003 15:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONnQ-0000w3-Je; Mon, 24 Nov 2003 15:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONnE-0000ve-7S for pana@optimus.ietf.org; Mon, 24 Nov 2003 15:58:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29287 for ; Mon, 24 Nov 2003 15:58:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONnC-0004X2-00 for pana@ietf.org; Mon, 24 Nov 2003 15:58:46 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AONnB-0004Wz-00 for pana@ietf.org; Mon, 24 Nov 2003 15:58:45 -0500 Date: Mon, 24 Nov 2003 12:59:45 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: , CC: Bernard Aboba , Jari Arkko , James Kempf , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm trying to figure out how we can: - just maintain one DI for the PaC, and that is used as the local end-point of the IPsec tunnel (when IPsec-based access control is used) - any other IP address can be configured inside this tunnel. Router discovery, ND, and DHCP can be run inside the tunnel. These IP addresses should not be used as PANA DI. I think supporting DHCP-based or autoconf based address configuration is required. Additional methods, like IKE-based address config, is nice to have. This is so that the impact of PANA on the access network architecture is minimal. It sounds like both IP-in-IP transport mode SA and tunnel mode SA with wildcard phase 2 identities support these... Alper > With regard to the inner address assignment through IKE or IKEv2, > just use the method(s) available for tunnel mode SA. > > I don't think we have to support IP-in-IP transport mode SA just because a > particular address configuration > method may not be supported by tunnel mode SA. > > Yoshihiro Ohba > > > > > > > "Mohan > Parthasarathy" To: "Alper Yegin" > , > , "Bernard Aboba" > l.net> , "James > Kempf" > Sent by: Subject: Re: [Pana] IP address > configuration > pana-admin@ietf. > org > > > 2003/11/21 17:38 > > > > > > > > >> >>> >>>> the PANA-Bind-Request message. PaC should attempt this configuration >>> inside >>>> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless > address >>>> autoconfiguration or DHCP can be used. >>>> >>> As i clarified in my other email, you don't setup the IPsec selectors > until >>> you have >>> acquired the "routeable" (inner) address. And these addresses are used > as >>> selectors >>> in the SPD. >>> >>>> Both pre-PANA and post-PANA addresses are used by the PaC at the same >>> time, >>>> though post-PANA addresses only appear inside the tunnel. A post-PANA >>>> address has no significance for the PANA session or access control. >>>> >>> For tunnel mode SA, the outer addresses are not significant for access >>> control. >>> The inner addresses are used for access control. SPD selectors are > inner >>> addresses. >> >> Apparently I was still thinking in terms of IP-IP transport mode (the > older >> version of the draft). >> > Yes. The older version of the draft used just the link-local address as > selectors. > So, it is possible to do IPsec as soon as you are done with PANA. > >> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's > phase >> 2 identity, so that the inner IP addresses can be anything. And run > address >> autoconfiguration or DHCP inside the tunnel. >> > I am not sure whether the EP would accept the range. EP may just accept > only > one address as it lets any authenticated nodes spoof each other very > easily. > I have only seen ranges used by VPN gateways and not sure whether any > host uses it or not. Again, if we can fix this in other ways e.g. using > IP-IP transport mode, we should do that. > >> >>> >>>> If pre-PANA and post-PANA addresses are the same, they will be used > both >>>> inside and outside the tunnel (any issues with IPsec processing?). > This >>> can >>> >>> Some implementations have problem with this when the packets are > destined to >>> the tunnel end point address itself. >> >> Does this have anyting to do with the specification, or the intended use > of >> it? Or, is this simple a shortcoming or a bug in some implementations? >> > It is just an implementation artefact. I send packets to "DEST", route > lookup > returns a tunnel interface, which in turn encapsulated with outer header > "DEST" , re-enters IP and loops again. This comes as a side effect of > implementing IPsec tunnel mode SA as an "interface". This is not > a real issue here as we can always bypass IPsec for messages sent > to EP. > > -mohan > >>> Here, these will be PANA messages >>> which will anway be bypassed (mentioned in the draft) i.e no IPsec for > PANA >>> messages flowing between PaC and PAA/EP. >> >> >> >> Alper >> >> >>> >>>> be the case when the client has a static IP address, or the DHCP > address >>>> assignment does not depend on the client identity. >>>> >>>> Comments? >>>> >>>> Alper >>>> >>> mohan >>> >>>> >>>> >>>> _______________________________________________ >>>> Pana mailing list >>>> Pana@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pana >>> >>> >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pana >>> >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Nov 24 20:54:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16096 for ; Mon, 24 Nov 2003 20:54:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSOu-000273-U1; Mon, 24 Nov 2003 20:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSO8-00026U-Ea for pana@optimus.ietf.org; Mon, 24 Nov 2003 20:53:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16071 for ; Mon, 24 Nov 2003 20:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOSO5-0002uA-00 for pana@ietf.org; Mon, 24 Nov 2003 20:53:09 -0500 Received: from smtp801.mail.ukl.yahoo.com ([217.12.12.138]) by ietf-mx with smtp (Exim 4.12) id 1AOSO5-0002ty-00 for pana@ietf.org; Mon, 24 Nov 2003 20:53:09 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 25 Nov 2003 01:52:38 -0000 Message-ID: <011d01c3b2f6$ce559500$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , Cc: "Bernard Aboba" , "Jari Arkko" , "James Kempf" , References: Subject: Re: [Pana] IP address configuration Date: Mon, 24 Nov 2003 17:52:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper, Comments below.. > > I'm trying to figure out how we can: > - just maintain one DI for the PaC, and that is used as the local end-point > of the IPsec tunnel (when IPsec-based access control is used) > - any other IP address can be configured inside this tunnel. Router > discovery, ND, and DHCP can be run inside the tunnel. These IP addresses > should not be used as PANA DI. > If you are using IPsec based access control, the functionality of EP is different on how it is configured. If EP and the access router are different boxes, then EP acts as a layer 3 router forwarding packets from the access router to the clients. This implies decrementing ttl for all packets which won't work with ND/RD messages that are sent from the access router to the PaCs. If EP and access router are the same box, then the ttl is not decremented for locally sourced packets e.g. ND/RD, as the packets are not forwarded anymore, just locally sourced. The picture in draft-ietf-pana-ipsec-00.txt assumes AR and EP are separated and hence bypasses all ND/RD. > I think supporting DHCP-based or autoconf based address configuration is > required. Additional methods, like IKE-based address config, is nice to > have. This is so that the impact of PANA on the access network architecture > is minimal. > > It sounds like both IP-in-IP transport mode SA and tunnel mode SA with > wildcard phase 2 identities support these... > See above. -mohan > Alper > > > > > > > With regard to the inner address assignment through IKE or IKEv2, > > just use the method(s) available for tunnel mode SA. > > > > I don't think we have to support IP-in-IP transport mode SA just because a > > particular address configuration > > method may not be supported by tunnel mode SA. > > > > Yoshihiro Ohba > > > > > > > > > > > > > > "Mohan > > Parthasarathy" To: "Alper Yegin" > > , > > > , "Bernard Aboba" > > l.net> , "James > > Kempf" > > Sent by: Subject: Re: [Pana] IP address > > configuration > > pana-admin@ietf. > > org > > > > > > 2003/11/21 17:38 > > > > > > > > > > > > > > > > > >> > >>> > >>>> the PANA-Bind-Request message. PaC should attempt this configuration > >>> inside > >>>> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless > > address > >>>> autoconfiguration or DHCP can be used. > >>>> > >>> As i clarified in my other email, you don't setup the IPsec selectors > > until > >>> you have > >>> acquired the "routeable" (inner) address. And these addresses are used > > as > >>> selectors > >>> in the SPD. > >>> > >>>> Both pre-PANA and post-PANA addresses are used by the PaC at the same > >>> time, > >>>> though post-PANA addresses only appear inside the tunnel. A post-PANA > >>>> address has no significance for the PANA session or access control. > >>>> > >>> For tunnel mode SA, the outer addresses are not significant for access > >>> control. > >>> The inner addresses are used for access control. SPD selectors are > > inner > >>> addresses. > >> > >> Apparently I was still thinking in terms of IP-IP transport mode (the > > older > >> version of the draft). > >> > > Yes. The older version of the draft used just the link-local address as > > selectors. > > So, it is possible to do IPsec as soon as you are done with PANA. > > > >> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's > > phase > >> 2 identity, so that the inner IP addresses can be anything. And run > > address > >> autoconfiguration or DHCP inside the tunnel. > >> > > I am not sure whether the EP would accept the range. EP may just accept > > only > > one address as it lets any authenticated nodes spoof each other very > > easily. > > I have only seen ranges used by VPN gateways and not sure whether any > > host uses it or not. Again, if we can fix this in other ways e.g. using > > IP-IP transport mode, we should do that. > > > >> > >>> > >>>> If pre-PANA and post-PANA addresses are the same, they will be used > > both > >>>> inside and outside the tunnel (any issues with IPsec processing?). > > This > >>> can > >>> > >>> Some implementations have problem with this when the packets are > > destined to > >>> the tunnel end point address itself. > >> > >> Does this have anyting to do with the specification, or the intended use > > of > >> it? Or, is this simple a shortcoming or a bug in some implementations? > >> > > It is just an implementation artefact. I send packets to "DEST", route > > lookup > > returns a tunnel interface, which in turn encapsulated with outer header > > "DEST" , re-enters IP and loops again. This comes as a side effect of > > implementing IPsec tunnel mode SA as an "interface". This is not > > a real issue here as we can always bypass IPsec for messages sent > > to EP. > > > > -mohan > > > >>> Here, these will be PANA messages > >>> which will anway be bypassed (mentioned in the draft) i.e no IPsec for > > PANA > >>> messages flowing between PaC and PAA/EP. > >> > >> > >> > >> Alper > >> > >> > >>> > >>>> be the case when the client has a static IP address, or the DHCP > > address > >>>> assignment does not depend on the client identity. > >>>> > >>>> Comments? > >>>> > >>>> Alper > >>>> > >>> mohan > >>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pana mailing list > >>>> Pana@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >>> > >>> _______________________________________________ > >>> Pana mailing list > >>> Pana@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Nov 24 20:54:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16111 for ; Mon, 24 Nov 2003 20:54:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSOz-00027l-BI for pana-archive@odin.ietf.org; Mon, 24 Nov 2003 20:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP1s5QW008159 for pana-archive@odin.ietf.org; Mon, 24 Nov 2003 20:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSOz-00027W-39 for pana-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 20:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16076 for ; Mon, 24 Nov 2003 20:53:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOSOw-0002ue-00 for pana-web-archive@ietf.org; Mon, 24 Nov 2003 20:54:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOSOw-0002ub-00 for pana-web-archive@ietf.org; Mon, 24 Nov 2003 20:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSOu-000273-U1; Mon, 24 Nov 2003 20:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSO8-00026U-Ea for pana@optimus.ietf.org; Mon, 24 Nov 2003 20:53:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16071 for ; Mon, 24 Nov 2003 20:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOSO5-0002uA-00 for pana@ietf.org; Mon, 24 Nov 2003 20:53:09 -0500 Received: from smtp801.mail.ukl.yahoo.com ([217.12.12.138]) by ietf-mx with smtp (Exim 4.12) id 1AOSO5-0002ty-00 for pana@ietf.org; Mon, 24 Nov 2003 20:53:09 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 25 Nov 2003 01:52:38 -0000 Message-ID: <011d01c3b2f6$ce559500$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , Cc: "Bernard Aboba" , "Jari Arkko" , "James Kempf" , References: Subject: Re: [Pana] IP address configuration Date: Mon, 24 Nov 2003 17:52:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper, Comments below.. > > I'm trying to figure out how we can: > - just maintain one DI for the PaC, and that is used as the local end-point > of the IPsec tunnel (when IPsec-based access control is used) > - any other IP address can be configured inside this tunnel. Router > discovery, ND, and DHCP can be run inside the tunnel. These IP addresses > should not be used as PANA DI. > If you are using IPsec based access control, the functionality of EP is different on how it is configured. If EP and the access router are different boxes, then EP acts as a layer 3 router forwarding packets from the access router to the clients. This implies decrementing ttl for all packets which won't work with ND/RD messages that are sent from the access router to the PaCs. If EP and access router are the same box, then the ttl is not decremented for locally sourced packets e.g. ND/RD, as the packets are not forwarded anymore, just locally sourced. The picture in draft-ietf-pana-ipsec-00.txt assumes AR and EP are separated and hence bypasses all ND/RD. > I think supporting DHCP-based or autoconf based address configuration is > required. Additional methods, like IKE-based address config, is nice to > have. This is so that the impact of PANA on the access network architecture > is minimal. > > It sounds like both IP-in-IP transport mode SA and tunnel mode SA with > wildcard phase 2 identities support these... > See above. -mohan > Alper > > > > > > > With regard to the inner address assignment through IKE or IKEv2, > > just use the method(s) available for tunnel mode SA. > > > > I don't think we have to support IP-in-IP transport mode SA just because a > > particular address configuration > > method may not be supported by tunnel mode SA. > > > > Yoshihiro Ohba > > > > > > > > > > > > > > "Mohan > > Parthasarathy" To: "Alper Yegin" > > , > > > , "Bernard Aboba" > > l.net> , "James > > Kempf" > > Sent by: Subject: Re: [Pana] IP address > > configuration > > pana-admin@ietf. > > org > > > > > > 2003/11/21 17:38 > > > > > > > > > > > > > > > > > >> > >>> > >>>> the PANA-Bind-Request message. PaC should attempt this configuration > >>> inside > >>>> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless > > address > >>>> autoconfiguration or DHCP can be used. > >>>> > >>> As i clarified in my other email, you don't setup the IPsec selectors > > until > >>> you have > >>> acquired the "routeable" (inner) address. And these addresses are used > > as > >>> selectors > >>> in the SPD. > >>> > >>>> Both pre-PANA and post-PANA addresses are used by the PaC at the same > >>> time, > >>>> though post-PANA addresses only appear inside the tunnel. A post-PANA > >>>> address has no significance for the PANA session or access control. > >>>> > >>> For tunnel mode SA, the outer addresses are not significant for access > >>> control. > >>> The inner addresses are used for access control. SPD selectors are > > inner > >>> addresses. > >> > >> Apparently I was still thinking in terms of IP-IP transport mode (the > > older > >> version of the draft). > >> > > Yes. The older version of the draft used just the link-local address as > > selectors. > > So, it is possible to do IPsec as soon as you are done with PANA. > > > >> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's > > phase > >> 2 identity, so that the inner IP addresses can be anything. And run > > address > >> autoconfiguration or DHCP inside the tunnel. > >> > > I am not sure whether the EP would accept the range. EP may just accept > > only > > one address as it lets any authenticated nodes spoof each other very > > easily. > > I have only seen ranges used by VPN gateways and not sure whether any > > host uses it or not. Again, if we can fix this in other ways e.g. using > > IP-IP transport mode, we should do that. > > > >> > >>> > >>>> If pre-PANA and post-PANA addresses are the same, they will be used > > both > >>>> inside and outside the tunnel (any issues with IPsec processing?). > > This > >>> can > >>> > >>> Some implementations have problem with this when the packets are > > destined to > >>> the tunnel end point address itself. > >> > >> Does this have anyting to do with the specification, or the intended use > > of > >> it? Or, is this simple a shortcoming or a bug in some implementations? > >> > > It is just an implementation artefact. I send packets to "DEST", route > > lookup > > returns a tunnel interface, which in turn encapsulated with outer header > > "DEST" , re-enters IP and loops again. This comes as a side effect of > > implementing IPsec tunnel mode SA as an "interface". This is not > > a real issue here as we can always bypass IPsec for messages sent > > to EP. > > > > -mohan > > > >>> Here, these will be PANA messages > >>> which will anway be bypassed (mentioned in the draft) i.e no IPsec for > > PANA > >>> messages flowing between PaC and PAA/EP. > >> > >> > >> > >> Alper > >> > >> > >>> > >>>> be the case when the client has a static IP address, or the DHCP > > address > >>>> assignment does not depend on the client identity. > >>>> > >>>> Comments? > >>>> > >>>> Alper > >>>> > >>> mohan > >>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pana mailing list > >>>> Pana@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >>> > >>> _______________________________________________ > >>> Pana mailing list > >>> Pana@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 25 03:08:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07761 for ; Tue, 25 Nov 2003 03:08:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYEt-0002lh-1a; Tue, 25 Nov 2003 03:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORbz-0000HA-7j for pana@optimus.ietf.org; Mon, 24 Nov 2003 20:03:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14718 for ; Mon, 24 Nov 2003 20:03:13 -0500 (EST) From: Yoshihiro.Ohba@tais.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORbx-0002IN-00 for pana@ietf.org; Mon, 24 Nov 2003 20:03:25 -0500 Received: from zmsvr04.tais.net ([12.106.80.12]) by ietf-mx with esmtp (Exim 4.12) id 1AORbw-0002Hw-00 for pana@ietf.org; Mon, 24 Nov 2003 20:03:24 -0500 Subject: Re: [Pana] IP address configuration To: alper@docomolabs-usa.com Cc: Bernard Aboba , Jari Arkko , James Kempf , mohanp@sbcglobal.net, pana@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 Nov 2003 17:02:50 -0800 X-MIMETrack: Serialize by Router on zmsvr04/tais_external(Release 5.0.9a |January 7, 2002) at 11/24/2003 05:03:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I'm trying to figure out how we can: - just maintain one DI for the PaC, and that is used as the local end-point of the IPsec tunnel (when IPsec-based access control is used) OK. - any other IP address can be configured inside this tunnel. Router discovery, ND, and DHCP can be run inside the tunnel. These IP addresses should not be used as PANA DI. I agree tht these addresses should not be uesd as PANA DI when IPsec when IPsec-based access control is used. But it is possible to configure any these addresses outside of IKE or IKEv2 and then register it as the IPsec tunnel inner address within IKE or IKEv2 signaling (by using the address as IKE Phase 2 SA or IKEv2 CHILD_SA identification, with still using link-local address as PANA DI (thus the inner address can be transparent to PAA). So I don't understand why configuring every inner address through IKE or IKEv2 is preferred. What is preferred is allowing flexibility in inner IP address acquisition procedures (which can be performed inside or outside of IKE or IKEv2). I think supporting DHCP-based or autoconf based address configuration is required. Additional methods, like IKE-based address config, is nice to have. This is so that the impact of PANA on the access network architecture is minimal. It sounds like both IP-in-IP transport mode SA and tunnel mode SA with wildcard phase 2 identities support these... It seems that we are thining about the same goal in a slightly different way. I think what is required for PANA is to be able to become transparent to any inner address configuration methods. If both IP-in-IP transport mode SA and tunnel mode SA negotiations support DHCP and autoconf inside IKE/IKEv2, that is fine (but I think using tunnel mode SA is enough). On the other hand, if particular type of IPsec SA negotiation can support only limited type of configuration method inside IKE/IKEv2, that is also fine, because that is an IKE/IKEv2 design and/or implementation issue, and not a PANA issue. Yoshihiro Ohba Alper > With regard to the inner address assignment through IKE or IKEv2, > just use the method(s) available for tunnel mode SA. > > I don't think we have to support IP-in-IP transport mode SA just because a > particular address configuration > method may not be supported by tunnel mode SA. > > Yoshihiro Ohba > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 25 03:08:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07779 for ; Tue, 25 Nov 2003 03:08:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYF3-0002nC-QF for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 03:08:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP88DDP010735 for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 03:08:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYEz-0002mq-Dj for pana-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 03:08:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07755 for ; Tue, 25 Nov 2003 03:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYEv-0007dr-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 03:08:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOYEu-0007do-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 03:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYEt-0002lh-1a; Tue, 25 Nov 2003 03:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORbz-0000HA-7j for pana@optimus.ietf.org; Mon, 24 Nov 2003 20:03:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14718 for ; Mon, 24 Nov 2003 20:03:13 -0500 (EST) From: Yoshihiro.Ohba@tais.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORbx-0002IN-00 for pana@ietf.org; Mon, 24 Nov 2003 20:03:25 -0500 Received: from zmsvr04.tais.net ([12.106.80.12]) by ietf-mx with esmtp (Exim 4.12) id 1AORbw-0002Hw-00 for pana@ietf.org; Mon, 24 Nov 2003 20:03:24 -0500 Subject: Re: [Pana] IP address configuration To: alper@docomolabs-usa.com Cc: Bernard Aboba , Jari Arkko , James Kempf , mohanp@sbcglobal.net, pana@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 Nov 2003 17:02:50 -0800 X-MIMETrack: Serialize by Router on zmsvr04/tais_external(Release 5.0.9a |January 7, 2002) at 11/24/2003 05:03:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I'm trying to figure out how we can: - just maintain one DI for the PaC, and that is used as the local end-point of the IPsec tunnel (when IPsec-based access control is used) OK. - any other IP address can be configured inside this tunnel. Router discovery, ND, and DHCP can be run inside the tunnel. These IP addresses should not be used as PANA DI. I agree tht these addresses should not be uesd as PANA DI when IPsec when IPsec-based access control is used. But it is possible to configure any these addresses outside of IKE or IKEv2 and then register it as the IPsec tunnel inner address within IKE or IKEv2 signaling (by using the address as IKE Phase 2 SA or IKEv2 CHILD_SA identification, with still using link-local address as PANA DI (thus the inner address can be transparent to PAA). So I don't understand why configuring every inner address through IKE or IKEv2 is preferred. What is preferred is allowing flexibility in inner IP address acquisition procedures (which can be performed inside or outside of IKE or IKEv2). I think supporting DHCP-based or autoconf based address configuration is required. Additional methods, like IKE-based address config, is nice to have. This is so that the impact of PANA on the access network architecture is minimal. It sounds like both IP-in-IP transport mode SA and tunnel mode SA with wildcard phase 2 identities support these... It seems that we are thining about the same goal in a slightly different way. I think what is required for PANA is to be able to become transparent to any inner address configuration methods. If both IP-in-IP transport mode SA and tunnel mode SA negotiations support DHCP and autoconf inside IKE/IKEv2, that is fine (but I think using tunnel mode SA is enough). On the other hand, if particular type of IPsec SA negotiation can support only limited type of configuration method inside IKE/IKEv2, that is also fine, because that is an IKE/IKEv2 design and/or implementation issue, and not a PANA issue. Yoshihiro Ohba Alper > With regard to the inner address assignment through IKE or IKEv2, > just use the method(s) available for tunnel mode SA. > > I don't think we have to support IP-in-IP transport mode SA just because a > particular address configuration > method may not be supported by tunnel mode SA. > > Yoshihiro Ohba > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 25 03:37:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08507 for ; Tue, 25 Nov 2003 03:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYgx-0003sj-NW; Tue, 25 Nov 2003 03:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYgd-0003rW-3l for pana@optimus.ietf.org; Tue, 25 Nov 2003 03:36:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08477 for ; Tue, 25 Nov 2003 03:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYga-0000Ba-00 for pana@ietf.org; Tue, 25 Nov 2003 03:36:40 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AOYgZ-0000BX-00 for pana@ietf.org; Tue, 25 Nov 2003 03:36:40 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hAP8ae615101 for ; Tue, 25 Nov 2003 09:36:40 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAP8adm19132 for ; Tue, 25 Nov 2003 09:36:39 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 09:36:22 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC046A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: pana@ietf.org Date: Tue, 25 Nov 2003 09:36:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Pana] pana implementatoin report Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hi all, as mentioned the pana wg meeting i will post my slides to the list: http://www.tschofenig.com/pana/IETF58/pana_impl_report_ietf58.ppt ciao hannes _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 25 03:37:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08527 for ; Tue, 25 Nov 2003 03:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYhW-00042C-MF for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 03:37:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP8bctQ015472 for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 03:37:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYhV-00041H-0h for pana-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 03:37:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08500 for ; Tue, 25 Nov 2003 03:37:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYhR-0000C9-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 03:37:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOYhR-0000Bl-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 03:37:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYgx-0003sj-NW; Tue, 25 Nov 2003 03:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYgd-0003rW-3l for pana@optimus.ietf.org; Tue, 25 Nov 2003 03:36:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08477 for ; Tue, 25 Nov 2003 03:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYga-0000Ba-00 for pana@ietf.org; Tue, 25 Nov 2003 03:36:40 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AOYgZ-0000BX-00 for pana@ietf.org; Tue, 25 Nov 2003 03:36:40 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hAP8ae615101 for ; Tue, 25 Nov 2003 09:36:40 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAP8adm19132 for ; Tue, 25 Nov 2003 09:36:39 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 09:36:22 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC046A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: pana@ietf.org Date: Tue, 25 Nov 2003 09:36:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Pana] pana implementatoin report Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hi all, as mentioned the pana wg meeting i will post my slides to the list: http://www.tschofenig.com/pana/IETF58/pana_impl_report_ietf58.ppt ciao hannes _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 25 14:55:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05191 for ; Tue, 25 Nov 2003 14:55:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjH4-0003aG-2e; Tue, 25 Nov 2003 14:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjGr-0003Zl-8w for pana@optimus.ietf.org; Tue, 25 Nov 2003 14:54:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05169 for ; Tue, 25 Nov 2003 14:54:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjGo-0004An-00 for pana@ietf.org; Tue, 25 Nov 2003 14:54:46 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOjGn-0004Ai-00 for pana@ietf.org; Tue, 25 Nov 2003 14:54:45 -0500 Date: Tue, 25 Nov 2003 11:55:48 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: CC: Bernard Aboba , Jari Arkko , James Kempf , , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I agree tht these addresses should not be uesd as PANA DI when IPsec when > IPsec-based access control is used. But it is possible to configure any > these addresses > outside of IKE or IKEv2 and then register it as the IPsec tunnel inner > address > within IKE or IKEv2 signaling (by using the address as IKE Phase 2 SA or > IKEv2 CHILD_SA > identification, with still using link-local address as PANA DI (thus > the inner address can be transparent to PAA). If you are saying that we can let PaC configure inner addresses in any way they like (statically, via DHCP, via autoconf), and let PaC "register" them through IKE/IKEv2 in a transparent way to PANA, then that's fine. Only the outer address will have significance for the PANA "network access authorization." The inner addresses would have significance for "IP address authorization" which PANA does not care. Does IKE/IKEv2 allow updating the inner addresses at any time? > So I don't understand why > configuring > every inner address through IKE or IKEv2 is preferred. No, I didn't mean that. I said configuring post-PANA addresses inside the IPsec tunnel is preferred. > What is preferred is > allowing > flexibility in inner IP address acquisition procedures (which can be > performed > inside or outside of IKE or IKEv2). > > I think supporting DHCP-based or autoconf based address configuration is > required. Additional methods, like IKE-based address config, is nice to > have. This is so that the impact of PANA on the access network > architecture > is minimal. It sounds like both IP-in-IP transport mode SA and tunnel > mode SA with > wildcard phase 2 identities support these... > > > It seems that we are thining about the same goal in a slightly different > way. I think > what is required for PANA is to be able to become transparent to any inner > address configuration > methods. If both IP-in-IP transport mode SA and tunnel mode SA > negotiations support > DHCP and autoconf inside IKE/IKEv2, that is fine (but I think using tunnel What do you mean by "inside IKE/IKEv2"? Do you mean inside the IPsec tunnel? > mode SA is enough). > On the other hand, if particular type of IPsec SA negotiation can support > only limited type of configuration method inside IKE/IKEv2, that is also > fine, because that is an IKE/IKEv2 design > and/or implementation issue, and not a PANA issue. We need to make sure the networks are still capable of configuring IP addresses for their clients the same way they have been doing before (whether it is done statically, via DHCP, or via autoconf). If we don't, then that'd be a limitation of this design. Alper > > > Yoshihiro Ohba > > > > Alper > > > > > >> With regard to the inner address assignment through IKE or IKEv2, >> just use the method(s) available for tunnel mode SA. >> >> I don't think we have to support IP-in-IP transport mode SA just > because a >> particular address configuration >> method may not be supported by tunnel mode SA. >> >> Yoshihiro Ohba >> > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 25 14:55:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05210 for ; Tue, 25 Nov 2003 14:55:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjHC-0003b1-Mo for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 14:55:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJtAU5013824 for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 14:55:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjHC-0003at-7o for pana-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 14:55:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05176 for ; Tue, 25 Nov 2003 14:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjH9-0004B8-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 14:55:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjH8-0004B5-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 14:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjH4-0003aG-2e; Tue, 25 Nov 2003 14:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjGr-0003Zl-8w for pana@optimus.ietf.org; Tue, 25 Nov 2003 14:54:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05169 for ; Tue, 25 Nov 2003 14:54:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjGo-0004An-00 for pana@ietf.org; Tue, 25 Nov 2003 14:54:46 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOjGn-0004Ai-00 for pana@ietf.org; Tue, 25 Nov 2003 14:54:45 -0500 Date: Tue, 25 Nov 2003 11:55:48 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: CC: Bernard Aboba , Jari Arkko , James Kempf , , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I agree tht these addresses should not be uesd as PANA DI when IPsec when > IPsec-based access control is used. But it is possible to configure any > these addresses > outside of IKE or IKEv2 and then register it as the IPsec tunnel inner > address > within IKE or IKEv2 signaling (by using the address as IKE Phase 2 SA or > IKEv2 CHILD_SA > identification, with still using link-local address as PANA DI (thus > the inner address can be transparent to PAA). If you are saying that we can let PaC configure inner addresses in any way they like (statically, via DHCP, via autoconf), and let PaC "register" them through IKE/IKEv2 in a transparent way to PANA, then that's fine. Only the outer address will have significance for the PANA "network access authorization." The inner addresses would have significance for "IP address authorization" which PANA does not care. Does IKE/IKEv2 allow updating the inner addresses at any time? > So I don't understand why > configuring > every inner address through IKE or IKEv2 is preferred. No, I didn't mean that. I said configuring post-PANA addresses inside the IPsec tunnel is preferred. > What is preferred is > allowing > flexibility in inner IP address acquisition procedures (which can be > performed > inside or outside of IKE or IKEv2). > > I think supporting DHCP-based or autoconf based address configuration is > required. Additional methods, like IKE-based address config, is nice to > have. This is so that the impact of PANA on the access network > architecture > is minimal. It sounds like both IP-in-IP transport mode SA and tunnel > mode SA with > wildcard phase 2 identities support these... > > > It seems that we are thining about the same goal in a slightly different > way. I think > what is required for PANA is to be able to become transparent to any inner > address configuration > methods. If both IP-in-IP transport mode SA and tunnel mode SA > negotiations support > DHCP and autoconf inside IKE/IKEv2, that is fine (but I think using tunnel What do you mean by "inside IKE/IKEv2"? Do you mean inside the IPsec tunnel? > mode SA is enough). > On the other hand, if particular type of IPsec SA negotiation can support > only limited type of configuration method inside IKE/IKEv2, that is also > fine, because that is an IKE/IKEv2 design > and/or implementation issue, and not a PANA issue. We need to make sure the networks are still capable of configuring IP addresses for their clients the same way they have been doing before (whether it is done statically, via DHCP, or via autoconf). If we don't, then that'd be a limitation of this design. Alper > > > Yoshihiro Ohba > > > > Alper > > > > > >> With regard to the inner address assignment through IKE or IKEv2, >> just use the method(s) available for tunnel mode SA. >> >> I don't think we have to support IP-in-IP transport mode SA just > because a >> particular address configuration >> method may not be supported by tunnel mode SA. >> >> Yoshihiro Ohba >> > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 25 15:08:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06121 for ; Tue, 25 Nov 2003 15:08:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjTd-0004YZ-6C; Tue, 25 Nov 2003 15:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjSf-0004Lm-SF for pana@optimus.ietf.org; Tue, 25 Nov 2003 15:07:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05945 for ; Tue, 25 Nov 2003 15:06:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjSc-0004Uo-00 for pana@ietf.org; Tue, 25 Nov 2003 15:06:58 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOjSb-0004Uk-00 for pana@ietf.org; Tue, 25 Nov 2003 15:06:58 -0500 Date: Tue, 25 Nov 2003 12:07:58 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: Mohan Parthasarathy , CC: Bernard Aboba , Jari Arkko , James Kempf , Message-ID: In-Reply-To: <011d01c3b2f6$ce559500$681067c0@adithya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 11/24/03 5:52 PM, "Mohan Parthasarathy" wrote: > Alper, > > Comments below.. >> >> I'm trying to figure out how we can: >> - just maintain one DI for the PaC, and that is used as the local > end-point >> of the IPsec tunnel (when IPsec-based access control is used) >> - any other IP address can be configured inside this tunnel. Router >> discovery, ND, and DHCP can be run inside the tunnel. These IP addresses >> should not be used as PANA DI. >> > If you are using IPsec based access control, the functionality of EP is > different > on how it is configured. If EP and the access router are different boxes, > then > EP acts as a layer 3 router forwarding packets from the access router to the > clients. That means, actually the "EP" is the "access router" from IP perspective. Maybe we should treat these as a "colocated EP and AR" case. Relying on AR for DHCP messaging, ND, and router discovery while relying on the EP as the "default gateway" basically splits one link into two (PaC<===>EP, and PaC<-->AR). How does this impact the complexity? Or, what do we lose if we mark the EP as "AR" as well? Alper > This implies decrementing ttl for all packets which won't work with ND/RD > messages > that are sent from the access router to the PaCs. If EP and access router > are the same > box, then the ttl is not decremented for locally sourced packets e.g. > ND/RD, as the > packets are not forwarded anymore, just locally sourced. The picture in > draft-ietf-pana-ipsec-00.txt assumes AR and EP are separated > and hence bypasses all ND/RD. > >> I think supporting DHCP-based or autoconf based address configuration is >> required. Additional methods, like IKE-based address config, is nice to >> have. This is so that the impact of PANA on the access network > architecture >> is minimal. >> >> It sounds like both IP-in-IP transport mode SA and tunnel mode SA with >> wildcard phase 2 identities support these... >> > See above. > > -mohan > >> Alper >> >> >> >> >> >>> With regard to the inner address assignment through IKE or IKEv2, >>> just use the method(s) available for tunnel mode SA. >>> >>> I don't think we have to support IP-in-IP transport mode SA just because > a >>> particular address configuration >>> method may not be supported by tunnel mode SA. >>> >>> Yoshihiro Ohba >>> >>> >>> >>> >>> >>> >>> "Mohan >>> Parthasarathy" To: "Alper Yegin" >>> , >>> >> , "Bernard Aboba" >>> l.net> , > "James >>> Kempf" >>> Sent by: Subject: Re: [Pana] IP > address >>> configuration >>> pana-admin@ietf. >>> org >>> >>> >>> 2003/11/21 17:38 >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>>> >>>>>> the PANA-Bind-Request message. PaC should attempt this configuration >>>>> inside >>>>>> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless >>> address >>>>>> autoconfiguration or DHCP can be used. >>>>>> >>>>> As i clarified in my other email, you don't setup the IPsec selectors >>> until >>>>> you have >>>>> acquired the "routeable" (inner) address. And these addresses are used >>> as >>>>> selectors >>>>> in the SPD. >>>>> >>>>>> Both pre-PANA and post-PANA addresses are used by the PaC at the same >>>>> time, >>>>>> though post-PANA addresses only appear inside the tunnel. A post-PANA >>>>>> address has no significance for the PANA session or access control. >>>>>> >>>>> For tunnel mode SA, the outer addresses are not significant for access >>>>> control. >>>>> The inner addresses are used for access control. SPD selectors are >>> inner >>>>> addresses. >>>> >>>> Apparently I was still thinking in terms of IP-IP transport mode (the >>> older >>>> version of the draft). >>>> >>> Yes. The older version of the draft used just the link-local address as >>> selectors. >>> So, it is possible to do IPsec as soon as you are done with PANA. >>> >>>> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's >>> phase >>>> 2 identity, so that the inner IP addresses can be anything. And run >>> address >>>> autoconfiguration or DHCP inside the tunnel. >>>> >>> I am not sure whether the EP would accept the range. EP may just accept >>> only >>> one address as it lets any authenticated nodes spoof each other very >>> easily. >>> I have only seen ranges used by VPN gateways and not sure whether any >>> host uses it or not. Again, if we can fix this in other ways e.g. using >>> IP-IP transport mode, we should do that. >>> >>>> >>>>> >>>>>> If pre-PANA and post-PANA addresses are the same, they will be used >>> both >>>>>> inside and outside the tunnel (any issues with IPsec processing?). >>> This >>>>> can >>>>> >>>>> Some implementations have problem with this when the packets are >>> destined to >>>>> the tunnel end point address itself. >>>> >>>> Does this have anyting to do with the specification, or the intended > use >>> of >>>> it? Or, is this simple a shortcoming or a bug in some implementations? >>>> >>> It is just an implementation artefact. I send packets to "DEST", route >>> lookup >>> returns a tunnel interface, which in turn encapsulated with outer header >>> "DEST" , re-enters IP and loops again. This comes as a side effect of >>> implementing IPsec tunnel mode SA as an "interface". This is not >>> a real issue here as we can always bypass IPsec for messages sent >>> to EP. >>> >>> -mohan >>> >>>>> Here, these will be PANA messages >>>>> which will anway be bypassed (mentioned in the draft) i.e no IPsec for >>> PANA >>>>> messages flowing between PaC and PAA/EP. >>>> >>>> >>>> >>>> Alper >>>> >>>> >>>>> >>>>>> be the case when the client has a static IP address, or the DHCP >>> address >>>>>> assignment does not depend on the client identity. >>>>>> >>>>>> Comments? >>>>>> >>>>>> Alper >>>>>> >>>>> mohan >>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pana mailing list >>>>>> Pana@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/pana >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pana mailing list >>>>> Pana@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pana >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pana mailing list >>>> Pana@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pana >>> >>> >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pana >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 25 15:08:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06143 for ; Tue, 25 Nov 2003 15:08:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjTg-0004ap-UN for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 15:08:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPK84qA017649 for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 15:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjTg-0004aS-F7 for pana-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06054 for ; Tue, 25 Nov 2003 15:07:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjTd-0004WE-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 15:08:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjTc-0004W8-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 15:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjTd-0004YZ-6C; Tue, 25 Nov 2003 15:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjSf-0004Lm-SF for pana@optimus.ietf.org; Tue, 25 Nov 2003 15:07:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05945 for ; Tue, 25 Nov 2003 15:06:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjSc-0004Uo-00 for pana@ietf.org; Tue, 25 Nov 2003 15:06:58 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOjSb-0004Uk-00 for pana@ietf.org; Tue, 25 Nov 2003 15:06:58 -0500 Date: Tue, 25 Nov 2003 12:07:58 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: Mohan Parthasarathy , CC: Bernard Aboba , Jari Arkko , James Kempf , Message-ID: In-Reply-To: <011d01c3b2f6$ce559500$681067c0@adithya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11/24/03 5:52 PM, "Mohan Parthasarathy" wrote: > Alper, > > Comments below.. >> >> I'm trying to figure out how we can: >> - just maintain one DI for the PaC, and that is used as the local > end-point >> of the IPsec tunnel (when IPsec-based access control is used) >> - any other IP address can be configured inside this tunnel. Router >> discovery, ND, and DHCP can be run inside the tunnel. These IP addresses >> should not be used as PANA DI. >> > If you are using IPsec based access control, the functionality of EP is > different > on how it is configured. If EP and the access router are different boxes, > then > EP acts as a layer 3 router forwarding packets from the access router to the > clients. That means, actually the "EP" is the "access router" from IP perspective. Maybe we should treat these as a "colocated EP and AR" case. Relying on AR for DHCP messaging, ND, and router discovery while relying on the EP as the "default gateway" basically splits one link into two (PaC<===>EP, and PaC<-->AR). How does this impact the complexity? Or, what do we lose if we mark the EP as "AR" as well? Alper > This implies decrementing ttl for all packets which won't work with ND/RD > messages > that are sent from the access router to the PaCs. If EP and access router > are the same > box, then the ttl is not decremented for locally sourced packets e.g. > ND/RD, as the > packets are not forwarded anymore, just locally sourced. The picture in > draft-ietf-pana-ipsec-00.txt assumes AR and EP are separated > and hence bypasses all ND/RD. > >> I think supporting DHCP-based or autoconf based address configuration is >> required. Additional methods, like IKE-based address config, is nice to >> have. This is so that the impact of PANA on the access network > architecture >> is minimal. >> >> It sounds like both IP-in-IP transport mode SA and tunnel mode SA with >> wildcard phase 2 identities support these... >> > See above. > > -mohan > >> Alper >> >> >> >> >> >>> With regard to the inner address assignment through IKE or IKEv2, >>> just use the method(s) available for tunnel mode SA. >>> >>> I don't think we have to support IP-in-IP transport mode SA just because > a >>> particular address configuration >>> method may not be supported by tunnel mode SA. >>> >>> Yoshihiro Ohba >>> >>> >>> >>> >>> >>> >>> "Mohan >>> Parthasarathy" To: "Alper Yegin" >>> , >>> >> , "Bernard Aboba" >>> l.net> , > "James >>> Kempf" >>> Sent by: Subject: Re: [Pana] IP > address >>> configuration >>> pana-admin@ietf. >>> org >>> >>> >>> 2003/11/21 17:38 >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>>> >>>>>> the PANA-Bind-Request message. PaC should attempt this configuration >>>>> inside >>>>>> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless >>> address >>>>>> autoconfiguration or DHCP can be used. >>>>>> >>>>> As i clarified in my other email, you don't setup the IPsec selectors >>> until >>>>> you have >>>>> acquired the "routeable" (inner) address. And these addresses are used >>> as >>>>> selectors >>>>> in the SPD. >>>>> >>>>>> Both pre-PANA and post-PANA addresses are used by the PaC at the same >>>>> time, >>>>>> though post-PANA addresses only appear inside the tunnel. A post-PANA >>>>>> address has no significance for the PANA session or access control. >>>>>> >>>>> For tunnel mode SA, the outer addresses are not significant for access >>>>> control. >>>>> The inner addresses are used for access control. SPD selectors are >>> inner >>>>> addresses. >>>> >>>> Apparently I was still thinking in terms of IP-IP transport mode (the >>> older >>>> version of the draft). >>>> >>> Yes. The older version of the draft used just the link-local address as >>> selectors. >>> So, it is possible to do IPsec as soon as you are done with PANA. >>> >>>> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's >>> phase >>>> 2 identity, so that the inner IP addresses can be anything. And run >>> address >>>> autoconfiguration or DHCP inside the tunnel. >>>> >>> I am not sure whether the EP would accept the range. EP may just accept >>> only >>> one address as it lets any authenticated nodes spoof each other very >>> easily. >>> I have only seen ranges used by VPN gateways and not sure whether any >>> host uses it or not. Again, if we can fix this in other ways e.g. using >>> IP-IP transport mode, we should do that. >>> >>>> >>>>> >>>>>> If pre-PANA and post-PANA addresses are the same, they will be used >>> both >>>>>> inside and outside the tunnel (any issues with IPsec processing?). >>> This >>>>> can >>>>> >>>>> Some implementations have problem with this when the packets are >>> destined to >>>>> the tunnel end point address itself. >>>> >>>> Does this have anyting to do with the specification, or the intended > use >>> of >>>> it? Or, is this simple a shortcoming or a bug in some implementations? >>>> >>> It is just an implementation artefact. I send packets to "DEST", route >>> lookup >>> returns a tunnel interface, which in turn encapsulated with outer header >>> "DEST" , re-enters IP and loops again. This comes as a side effect of >>> implementing IPsec tunnel mode SA as an "interface". This is not >>> a real issue here as we can always bypass IPsec for messages sent >>> to EP. >>> >>> -mohan >>> >>>>> Here, these will be PANA messages >>>>> which will anway be bypassed (mentioned in the draft) i.e no IPsec for >>> PANA >>>>> messages flowing between PaC and PAA/EP. >>>> >>>> >>>> >>>> Alper >>>> >>>> >>>>> >>>>>> be the case when the client has a static IP address, or the DHCP >>> address >>>>>> assignment does not depend on the client identity. >>>>>> >>>>>> Comments? >>>>>> >>>>>> Alper >>>>>> >>>>> mohan >>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pana mailing list >>>>>> Pana@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/pana >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pana mailing list >>>>> Pana@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pana >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pana mailing list >>>> Pana@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pana >>> >>> >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pana >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 25 15:16:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07091 for ; Tue, 25 Nov 2003 15:16:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjbN-0005GM-Q5; Tue, 25 Nov 2003 15:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjbD-0005G4-OL for pana@optimus.ietf.org; Tue, 25 Nov 2003 15:15:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06984 for ; Tue, 25 Nov 2003 15:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjbC-0004h8-00 for pana@ietf.org; Tue, 25 Nov 2003 15:15:50 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOjbB-0004h3-00 for pana@ietf.org; Tue, 25 Nov 2003 15:15:49 -0500 Date: Tue, 25 Nov 2003 12:16:36 -0800 Subject: Re: [Pana] PAA-2-EP protocol requirements From: Alper Yegin To: , CC: MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba , Julien Bournelle Message-ID: In-Reply-To: <3FC205C6.3020902@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > below are some other PAA-2-EP functionnalities (open list). should we > consider them as also required ? not required at all ? supported > elsewhere ? any alternative ? > > a) Inactive peer detection: > The protocol used between PAA and EP should be able to detect inactive > peer within an appropriate time period. This can be achieved by having > both the EP and remote PAA constantly verify their connection to each > other via keep-alive messages: a heartbeat in fact. I'm not sure how much "explicit support" we need for this from the PAA2EP protocol. There can always be ad-hoc solutions to this. For example, running some request-reply messages between the PAA and EP can be used as a keep-alive. I can imagine an implementation resorting to such techniques when the protocol does not have a dedicated facility.... > > b) Stateful approach: > The protocol must allow to maintain some states in the PAA in order for > an EP that went down and came back up, or an EP that is being introduced > in the network to (re-)synchronize with the PAA. We can assume PAA always has the associated state. It'd have a list of authorized PaCs and their attributes... I don't think this is something for PAA2EP protocol to worry about... > In general terms, the PAA-EP protocol needs to support the stateful > model between the PAA and the EP(s) and some other mechanism for the EP > to learn the policies currently in effect on that access network. > > c) Accounting/Feedback from the EPs: > The PAA must have an efficient way to to get the accounting information > of PaC from EP since the PAA may be a client of the AAA backend > infrastructure. Getting statistics from the EP makes sense. For example, in the case of SNMP, if we get the counters from the EP this is good enough. The AAA client sitting on the PAA can turn these into accoutning records. Alper > > d) ???? > > > thanks, > Yacine El Mghazli > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 25 15:16:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07124 for ; Tue, 25 Nov 2003 15:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjbZ-0005JW-Ec for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 15:16:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKGDLK020422 for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 15:16:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjbZ-0005JJ-4S for pana-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:16:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07035 for ; Tue, 25 Nov 2003 15:15:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjbX-0004he-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 15:16:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjbX-0004hN-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 15:16:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjbN-0005GM-Q5; Tue, 25 Nov 2003 15:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjbD-0005G4-OL for pana@optimus.ietf.org; Tue, 25 Nov 2003 15:15:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06984 for ; Tue, 25 Nov 2003 15:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjbC-0004h8-00 for pana@ietf.org; Tue, 25 Nov 2003 15:15:50 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOjbB-0004h3-00 for pana@ietf.org; Tue, 25 Nov 2003 15:15:49 -0500 Date: Tue, 25 Nov 2003 12:16:36 -0800 Subject: Re: [Pana] PAA-2-EP protocol requirements From: Alper Yegin To: , CC: MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba , Julien Bournelle Message-ID: In-Reply-To: <3FC205C6.3020902@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > below are some other PAA-2-EP functionnalities (open list). should we > consider them as also required ? not required at all ? supported > elsewhere ? any alternative ? > > a) Inactive peer detection: > The protocol used between PAA and EP should be able to detect inactive > peer within an appropriate time period. This can be achieved by having > both the EP and remote PAA constantly verify their connection to each > other via keep-alive messages: a heartbeat in fact. I'm not sure how much "explicit support" we need for this from the PAA2EP protocol. There can always be ad-hoc solutions to this. For example, running some request-reply messages between the PAA and EP can be used as a keep-alive. I can imagine an implementation resorting to such techniques when the protocol does not have a dedicated facility.... > > b) Stateful approach: > The protocol must allow to maintain some states in the PAA in order for > an EP that went down and came back up, or an EP that is being introduced > in the network to (re-)synchronize with the PAA. We can assume PAA always has the associated state. It'd have a list of authorized PaCs and their attributes... I don't think this is something for PAA2EP protocol to worry about... > In general terms, the PAA-EP protocol needs to support the stateful > model between the PAA and the EP(s) and some other mechanism for the EP > to learn the policies currently in effect on that access network. > > c) Accounting/Feedback from the EPs: > The PAA must have an efficient way to to get the accounting information > of PaC from EP since the PAA may be a client of the AAA backend > infrastructure. Getting statistics from the EP makes sense. For example, in the case of SNMP, if we get the counters from the EP this is good enough. The AAA client sitting on the PAA can turn these into accoutning records. Alper > > d) ???? > > > thanks, > Yacine El Mghazli > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 25 19:52:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19990 for ; Tue, 25 Nov 2003 19:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOnuT-0006OS-Fk; Tue, 25 Nov 2003 19:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOnuK-0006OF-J1 for pana@optimus.ietf.org; Tue, 25 Nov 2003 19:51:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19979 for ; Tue, 25 Nov 2003 19:51:39 -0500 (EST) From: Yoshihiro.Ohba@tais.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOnuI-0003v6-00 for pana@ietf.org; Tue, 25 Nov 2003 19:51:50 -0500 Received: from zmsvr04.tais.net ([12.106.80.12]) by ietf-mx with esmtp (Exim 4.12) id 1AOnuI-0003uN-00 for pana@ietf.org; Tue, 25 Nov 2003 19:51:50 -0500 Subject: Re: [Pana] IP address configuration To: alper@docomolabs-usa.com Cc: Bernard Aboba , Jari Arkko , James Kempf , mohanp@sbcglobal.net, pana@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 25 Nov 2003 16:51:36 -0800 X-MIMETrack: Serialize by Router on zmsvr04/tais_external(Release 5.0.9a |January 7, 2002) at 11/25/2003 04:51:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > I agree tht these addresses should not be uesd as PANA DI when IPsec when > IPsec-based access control is used. But it is possible to configure any > these addresses > outside of IKE or IKEv2 and then register it as the IPsec tunnel inner > address > within IKE or IKEv2 signaling (by using the address as IKE Phase 2 SA or > IKEv2 CHILD_SA > identification, with still using link-local address as PANA DI (thus > the inner address can be transparent to PAA). If you are saying that we can let PaC configure inner addresses in any way they like (statically, via DHCP, via autoconf), and let PaC "register" them through IKE/IKEv2 in a transparent way to PANA, then that's fine. Yes. Only the outer address will have significance for the PANA "network access authorization." The inner addresses would have significance for "IP address authorization" which PANA does not care. I agree. Does IKE/IKEv2 allow updating the inner addresses at any time? I don't think IKE/IKEv2 allows updating the inner address for an IPsec SA once it has been established, but it is possible to set up another IPsec SA bound to the new inner address and I think this is sufficient. > So I don't understand why > configuring > every inner address through IKE or IKEv2 is preferred. No, I didn't mean that. I said configuring post-PANA addresses inside the IPsec tunnel is preferred. > What is preferred is > allowing > flexibility in inner IP address acquisition procedures (which can be > performed > inside or outside of IKE or IKEv2). > > I think supporting DHCP-based or autoconf based address configuration is > required. Additional methods, like IKE-based address config, is nice to > have. This is so that the impact of PANA on the access network > architecture > is minimal. It sounds like both IP-in-IP transport mode SA and tunnel > mode SA with > wildcard phase 2 identities support these... > > > It seems that we are thining about the same goal in a slightly different > way. I think > what is required for PANA is to be able to become transparent to any inner > address configuration > methods. If both IP-in-IP transport mode SA and tunnel mode SA > negotiations support > DHCP and autoconf inside IKE/IKEv2, that is fine (but I think using tunnel What do you mean by "inside IKE/IKEv2"? Do you mean inside the IPsec tunnel? Sorry, I meant inside IKE/IKEv2 or the IPsec tunnel (I mean post-PANA address configuration by using Configuration Payload exchange inside IKEv2 belongs to this case). > mode SA is enough). > On the other hand, if particular type of IPsec SA negotiation can support > only limited type of configuration method inside IKE/IKEv2, that is also > fine, because that is an IKE/IKEv2 design > and/or implementation issue, and not a PANA issue. We need to make sure the networks are still capable of configuring IP addresses for their clients the same way they have been doing before (whether it is done statically, via DHCP, or via autoconf). If we don't, then that'd be a limitation of this design. OK. The following is my analysis. When configuration of post-PANA address occurs before IKE/IKEv2, it might be difficult to support the ISP selection model over shared media. So supporting this case only would be a limitation. When configuration of post-PANA address occurs inside the IPsec tunnel or inside IKE/IKEv2, it would be able to support the ISP selection model over shared media. At least post-PANA address configuration is supported inside IKEv2 with Configuration Payload exchange. Post-PANA address configuration with DHCPv4 inside IPsec tunnel is supported by IKE + RFC3456. I am not really sure if there is no problem with other schemes for post-PANA address configuration inside IPsec tunnel. I have a concern on allowing a PaC to specify wildcard address range in IPsec SA negotiation for the purpose of running Neighbor Discovery inside the IPsec tunnel, especially when the PaC is also a router, it could totally affect routing behavior. Yoshihiro Ohba Alper > > > Yoshihiro Ohba > > > > Alper > > > > > >> With regard to the inner address assignment through IKE or IKEv2, >> just use the method(s) available for tunnel mode SA. >> >> I don't think we have to support IP-in-IP transport mode SA just > because a >> particular address configuration >> method may not be supported by tunnel mode SA. >> >> Yoshihiro Ohba >> > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 25 19:52:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20005 for ; Tue, 25 Nov 2003 19:52:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOnuY-0006P5-Ul for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 19:52:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ0q63Y024615 for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 19:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOnuY-0006Ow-N4 for pana-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 19:52:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19983 for ; Tue, 25 Nov 2003 19:51:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOnuW-0003vP-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 19:52:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOnuW-0003vM-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 19:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOnuT-0006OS-Fk; Tue, 25 Nov 2003 19:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOnuK-0006OF-J1 for pana@optimus.ietf.org; Tue, 25 Nov 2003 19:51:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19979 for ; Tue, 25 Nov 2003 19:51:39 -0500 (EST) From: Yoshihiro.Ohba@tais.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOnuI-0003v6-00 for pana@ietf.org; Tue, 25 Nov 2003 19:51:50 -0500 Received: from zmsvr04.tais.net ([12.106.80.12]) by ietf-mx with esmtp (Exim 4.12) id 1AOnuI-0003uN-00 for pana@ietf.org; Tue, 25 Nov 2003 19:51:50 -0500 Subject: Re: [Pana] IP address configuration To: alper@docomolabs-usa.com Cc: Bernard Aboba , Jari Arkko , James Kempf , mohanp@sbcglobal.net, pana@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 25 Nov 2003 16:51:36 -0800 X-MIMETrack: Serialize by Router on zmsvr04/tais_external(Release 5.0.9a |January 7, 2002) at 11/25/2003 04:51:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > I agree tht these addresses should not be uesd as PANA DI when IPsec when > IPsec-based access control is used. But it is possible to configure any > these addresses > outside of IKE or IKEv2 and then register it as the IPsec tunnel inner > address > within IKE or IKEv2 signaling (by using the address as IKE Phase 2 SA or > IKEv2 CHILD_SA > identification, with still using link-local address as PANA DI (thus > the inner address can be transparent to PAA). If you are saying that we can let PaC configure inner addresses in any way they like (statically, via DHCP, via autoconf), and let PaC "register" them through IKE/IKEv2 in a transparent way to PANA, then that's fine. Yes. Only the outer address will have significance for the PANA "network access authorization." The inner addresses would have significance for "IP address authorization" which PANA does not care. I agree. Does IKE/IKEv2 allow updating the inner addresses at any time? I don't think IKE/IKEv2 allows updating the inner address for an IPsec SA once it has been established, but it is possible to set up another IPsec SA bound to the new inner address and I think this is sufficient. > So I don't understand why > configuring > every inner address through IKE or IKEv2 is preferred. No, I didn't mean that. I said configuring post-PANA addresses inside the IPsec tunnel is preferred. > What is preferred is > allowing > flexibility in inner IP address acquisition procedures (which can be > performed > inside or outside of IKE or IKEv2). > > I think supporting DHCP-based or autoconf based address configuration is > required. Additional methods, like IKE-based address config, is nice to > have. This is so that the impact of PANA on the access network > architecture > is minimal. It sounds like both IP-in-IP transport mode SA and tunnel > mode SA with > wildcard phase 2 identities support these... > > > It seems that we are thining about the same goal in a slightly different > way. I think > what is required for PANA is to be able to become transparent to any inner > address configuration > methods. If both IP-in-IP transport mode SA and tunnel mode SA > negotiations support > DHCP and autoconf inside IKE/IKEv2, that is fine (but I think using tunnel What do you mean by "inside IKE/IKEv2"? Do you mean inside the IPsec tunnel? Sorry, I meant inside IKE/IKEv2 or the IPsec tunnel (I mean post-PANA address configuration by using Configuration Payload exchange inside IKEv2 belongs to this case). > mode SA is enough). > On the other hand, if particular type of IPsec SA negotiation can support > only limited type of configuration method inside IKE/IKEv2, that is also > fine, because that is an IKE/IKEv2 design > and/or implementation issue, and not a PANA issue. We need to make sure the networks are still capable of configuring IP addresses for their clients the same way they have been doing before (whether it is done statically, via DHCP, or via autoconf). If we don't, then that'd be a limitation of this design. OK. The following is my analysis. When configuration of post-PANA address occurs before IKE/IKEv2, it might be difficult to support the ISP selection model over shared media. So supporting this case only would be a limitation. When configuration of post-PANA address occurs inside the IPsec tunnel or inside IKE/IKEv2, it would be able to support the ISP selection model over shared media. At least post-PANA address configuration is supported inside IKEv2 with Configuration Payload exchange. Post-PANA address configuration with DHCPv4 inside IPsec tunnel is supported by IKE + RFC3456. I am not really sure if there is no problem with other schemes for post-PANA address configuration inside IPsec tunnel. I have a concern on allowing a PaC to specify wildcard address range in IPsec SA negotiation for the purpose of running Neighbor Discovery inside the IPsec tunnel, especially when the PaC is also a router, it could totally affect routing behavior. Yoshihiro Ohba Alper > > > Yoshihiro Ohba > > > > Alper > > > > > >> With regard to the inner address assignment through IKE or IKEv2, >> just use the method(s) available for tunnel mode SA. >> >> I don't think we have to support IP-in-IP transport mode SA just > because a >> particular address configuration >> method may not be supported by tunnel mode SA. >> >> Yoshihiro Ohba >> > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Nov 25 21:06:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21783 for ; Tue, 25 Nov 2003 21:06:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOp44-0000nl-Me; Tue, 25 Nov 2003 21:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOp3w-0000nI-RA for pana@optimus.ietf.org; Tue, 25 Nov 2003 21:05:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21762 for ; Tue, 25 Nov 2003 21:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOp3u-0004qD-00 for pana@ietf.org; Tue, 25 Nov 2003 21:05:50 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AOp3t-0004px-00 for pana@ietf.org; Tue, 25 Nov 2003 21:05:49 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 21:05:20 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04202F@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Yoshihiro.Ohba@tais.com, mohanp@sbcglobal.net Cc: Bernard Aboba , Jari Arkko , James Kempf , pana@ietf.org Subject: RE: [Pana] IP address configuration Date: Tue, 25 Nov 2003 21:05:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Alper, I might be missing something here, but I'm a bit confused by a couple of things below. > I'm trying to figure out how we can: > - just maintain one DI for the PaC, and that is used as the > local end-point > of the IPsec tunnel (when IPsec-based access control is used) > - any other IP address can be configured inside this tunnel. Router > discovery, ND, and DHCP can be run inside the tunnel. These > IP addresses > should not be used as PANA DI. > > I think supporting DHCP-based or autoconf based address > configuration is > required. Additional methods, like IKE-based address config, > is nice to > have. => When you talk about the IPsec tunnel are you always referring to the use of IPsec for access control? I mean you're never referring to a tunnel to a remote VPN in a corporate many hops away, right? If the above is correct I don't know how stateless address autoconfig is expected to work through that tunnel and why it needs to?? A node could use one address only, same in the outer and inner src fields. What am I missing? Hesham _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Nov 25 21:06:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21798 for ; Tue, 25 Nov 2003 21:06:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOp48-0000ol-9y for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 21:06:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ264VJ003137 for pana-archive@odin.ietf.org; Tue, 25 Nov 2003 21:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOp47-0000oW-Vn for pana-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 21:06:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21775 for ; Tue, 25 Nov 2003 21:05:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOp45-0004qc-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 21:06:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOp45-0004qZ-00 for pana-web-archive@ietf.org; Tue, 25 Nov 2003 21:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOp44-0000nl-Me; Tue, 25 Nov 2003 21:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOp3w-0000nI-RA for pana@optimus.ietf.org; Tue, 25 Nov 2003 21:05:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21762 for ; Tue, 25 Nov 2003 21:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOp3u-0004qD-00 for pana@ietf.org; Tue, 25 Nov 2003 21:05:50 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AOp3t-0004px-00 for pana@ietf.org; Tue, 25 Nov 2003 21:05:49 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 21:05:20 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04202F@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Yoshihiro.Ohba@tais.com, mohanp@sbcglobal.net Cc: Bernard Aboba , Jari Arkko , James Kempf , pana@ietf.org Subject: RE: [Pana] IP address configuration Date: Tue, 25 Nov 2003 21:05:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Alper, I might be missing something here, but I'm a bit confused by a couple of things below. > I'm trying to figure out how we can: > - just maintain one DI for the PaC, and that is used as the > local end-point > of the IPsec tunnel (when IPsec-based access control is used) > - any other IP address can be configured inside this tunnel. Router > discovery, ND, and DHCP can be run inside the tunnel. These > IP addresses > should not be used as PANA DI. > > I think supporting DHCP-based or autoconf based address > configuration is > required. Additional methods, like IKE-based address config, > is nice to > have. => When you talk about the IPsec tunnel are you always referring to the use of IPsec for access control? I mean you're never referring to a tunnel to a remote VPN in a corporate many hops away, right? If the above is correct I don't know how stateless address autoconfig is expected to work through that tunnel and why it needs to?? A node could use one address only, same in the outer and inner src fields. What am I missing? Hesham _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Nov 26 11:03:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14345 for ; Wed, 26 Nov 2003 11:03:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP285-0004vW-6L; Wed, 26 Nov 2003 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP26h-0004sg-SC for pana@optimus.ietf.org; Wed, 26 Nov 2003 11:02:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14250 for ; Wed, 26 Nov 2003 11:01:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP26f-0000Eh-00 for pana@ietf.org; Wed, 26 Nov 2003 11:01:33 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AP26e-0000Dr-00 for pana@ietf.org; Wed, 26 Nov 2003 11:01:32 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 94201350F3; Wed, 26 Nov 2003 16:54:03 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 7D58D3F405; Wed, 26 Nov 2003 16:54:03 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003112616540219252 ; Wed, 26 Nov 2003 16:54:03 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 1D29A3F405; Wed, 26 Nov 2003 16:54:03 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AP1yc-0002Uh-SC; Wed, 26 Nov 2003 16:53:14 +0100 Date: Wed, 26 Nov 2003 16:53:14 +0100 From: Julien Bournelle To: Yacine.El_Mghazli@alcatel.fr Cc: pana@ietf.org, MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba Message-ID: <20031126155314.GP582@ipv6-5.int-evry.fr> References: <3FC205C6.3020902@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC205C6.3020902@alcatel.fr> Subject: [Pana] Re: PAA-2-EP protocol requirements Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi all, > 2) One-to-many PAA-EP relation: > This means that there might be multiple EPs per PAA. If we want to use IPsec between PaC and EP, the EP must be a router. AS the PAA must be located exactly one IP hop away from the PaC, there must be no EP between PaC and PAA. So it means that EP, PaC and PAA are on the same IP subnet (Am I wrong ?). So, I wonder if it a valid scenario to have multiple EPs per PAA if we use IPsec. Any ideas ? -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Nov 26 11:04:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14421 for ; Wed, 26 Nov 2003 11:04:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP292-0004z3-I7 for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 11:04:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQG40vF019147 for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 11:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP288-0004wA-Hp for pana-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 11:04:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14331 for ; Wed, 26 Nov 2003 11:02:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP286-0000IY-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 11:03:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP285-0000IU-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 11:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP285-0004vW-6L; Wed, 26 Nov 2003 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP26h-0004sg-SC for pana@optimus.ietf.org; Wed, 26 Nov 2003 11:02:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14250 for ; Wed, 26 Nov 2003 11:01:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP26f-0000Eh-00 for pana@ietf.org; Wed, 26 Nov 2003 11:01:33 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AP26e-0000Dr-00 for pana@ietf.org; Wed, 26 Nov 2003 11:01:32 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 94201350F3; Wed, 26 Nov 2003 16:54:03 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 7D58D3F405; Wed, 26 Nov 2003 16:54:03 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003112616540219252 ; Wed, 26 Nov 2003 16:54:03 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 1D29A3F405; Wed, 26 Nov 2003 16:54:03 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AP1yc-0002Uh-SC; Wed, 26 Nov 2003 16:53:14 +0100 Date: Wed, 26 Nov 2003 16:53:14 +0100 From: Julien Bournelle To: Yacine.El_Mghazli@alcatel.fr Cc: pana@ietf.org, MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba Message-ID: <20031126155314.GP582@ipv6-5.int-evry.fr> References: <3FC205C6.3020902@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC205C6.3020902@alcatel.fr> Subject: [Pana] Re: PAA-2-EP protocol requirements Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi all, > 2) One-to-many PAA-EP relation: > This means that there might be multiple EPs per PAA. If we want to use IPsec between PaC and EP, the EP must be a router. AS the PAA must be located exactly one IP hop away from the PaC, there must be no EP between PaC and PAA. So it means that EP, PaC and PAA are on the same IP subnet (Am I wrong ?). So, I wonder if it a valid scenario to have multiple EPs per PAA if we use IPsec. Any ideas ? -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Nov 26 12:52:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19466 for ; Wed, 26 Nov 2003 12:52:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3pa-0004qu-Ar; Wed, 26 Nov 2003 12:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3pA-0004pn-Ny for pana@optimus.ietf.org; Wed, 26 Nov 2003 12:51:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19421 for ; Wed, 26 Nov 2003 12:51:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3p8-00020u-00 for pana@ietf.org; Wed, 26 Nov 2003 12:51:34 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AP3p8-00020k-00 for pana@ietf.org; Wed, 26 Nov 2003 12:51:34 -0500 Date: Wed, 26 Nov 2003 09:52:08 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: Soliman Hesham , , CC: Bernard Aboba , Jari Arkko , James Kempf , Message-ID: In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F04202F@ftmail.lab.flarion.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> I'm trying to figure out how we can: >> - just maintain one DI for the PaC, and that is used as the >> local end-point >> of the IPsec tunnel (when IPsec-based access control is used) > >> - any other IP address can be configured inside this tunnel. Router >> discovery, ND, and DHCP can be run inside the tunnel. These >> IP addresses >> should not be used as PANA DI. >> >> I think supporting DHCP-based or autoconf based address >> configuration is >> required. Additional methods, like IKE-based address config, >> is nice to >> have. > > => When you talk about the IPsec tunnel are you always > referring to the use of IPsec for access control? I mean > you're never referring to a tunnel to a remote VPN in a > corporate many hops away, right? Yes, I'm not talking about a VPN tunnel to some corporate network. > > If the above is correct I don't know how stateless address > autoconfig is expected to work through that tunnel This is what I'm trying to understand too. What are the issues there? > and why > it needs to?? Running router discovery and neighbor discovery (for DAD) inside the IPsec tunnel would provide additional security to the network. This ensures, for example, PaC does not receive unauthorized router advertisements. > A node could use one address only, same in > the outer and inner src fields. What am I missing? It could. But in the case of IPv6, using the link-local address as the outer address, and the global address as the inner address makes sense to me. Alper > > > Hesham > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Nov 26 12:52:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19481 for ; Wed, 26 Nov 2003 12:52:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3pe-0004rb-3M for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 12:52:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQHq6ut018689 for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 12:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3pd-0004rM-U8 for pana-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 12:52:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19449 for ; Wed, 26 Nov 2003 12:51:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3pc-00021L-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 12:52:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP3pb-00021I-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 12:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3pa-0004qu-Ar; Wed, 26 Nov 2003 12:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3pA-0004pn-Ny for pana@optimus.ietf.org; Wed, 26 Nov 2003 12:51:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19421 for ; Wed, 26 Nov 2003 12:51:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3p8-00020u-00 for pana@ietf.org; Wed, 26 Nov 2003 12:51:34 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AP3p8-00020k-00 for pana@ietf.org; Wed, 26 Nov 2003 12:51:34 -0500 Date: Wed, 26 Nov 2003 09:52:08 -0800 Subject: Re: [Pana] IP address configuration From: Alper Yegin To: Soliman Hesham , , CC: Bernard Aboba , Jari Arkko , James Kempf , Message-ID: In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F04202F@ftmail.lab.flarion.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> I'm trying to figure out how we can: >> - just maintain one DI for the PaC, and that is used as the >> local end-point >> of the IPsec tunnel (when IPsec-based access control is used) > >> - any other IP address can be configured inside this tunnel. Router >> discovery, ND, and DHCP can be run inside the tunnel. These >> IP addresses >> should not be used as PANA DI. >> >> I think supporting DHCP-based or autoconf based address >> configuration is >> required. Additional methods, like IKE-based address config, >> is nice to >> have. > > => When you talk about the IPsec tunnel are you always > referring to the use of IPsec for access control? I mean > you're never referring to a tunnel to a remote VPN in a > corporate many hops away, right? Yes, I'm not talking about a VPN tunnel to some corporate network. > > If the above is correct I don't know how stateless address > autoconfig is expected to work through that tunnel This is what I'm trying to understand too. What are the issues there? > and why > it needs to?? Running router discovery and neighbor discovery (for DAD) inside the IPsec tunnel would provide additional security to the network. This ensures, for example, PaC does not receive unauthorized router advertisements. > A node could use one address only, same in > the outer and inner src fields. What am I missing? It could. But in the case of IPv6, using the link-local address as the outer address, and the global address as the inner address makes sense to me. Alper > > > Hesham > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Nov 26 14:39:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23820 for ; Wed, 26 Nov 2003 14:39:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5V6-0003iF-Hc; Wed, 26 Nov 2003 14:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5UF-0003ez-TN for pana@optimus.ietf.org; Wed, 26 Nov 2003 14:38:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23759 for ; Wed, 26 Nov 2003 14:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5UD-0003Zx-00 for pana@ietf.org; Wed, 26 Nov 2003 14:38:05 -0500 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1AP5UC-0003Zt-00 for pana@ietf.org; Wed, 26 Nov 2003 14:38:04 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 26 Nov 2003 19:38:03 -0000 Message-ID: <004f01c3b454$d1e47a10$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , Cc: "Bernard Aboba" , "Jari Arkko" , "James Kempf" , References: Subject: Re: [Pana] IP address configuration Date: Wed, 26 Nov 2003 11:36:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On 11/24/03 5:52 PM, "Mohan Parthasarathy" wrote: > > > Alper, > > > > Comments below.. > >> > >> I'm trying to figure out how we can: > >> - just maintain one DI for the PaC, and that is used as the local > > end-point > >> of the IPsec tunnel (when IPsec-based access control is used) > >> - any other IP address can be configured inside this tunnel. Router > >> discovery, ND, and DHCP can be run inside the tunnel. These IP addresses > >> should not be used as PANA DI. > >> > > If you are using IPsec based access control, the functionality of EP is > > different > > on how it is configured. If EP and the access router are different boxes, > > then > > EP acts as a layer 3 router forwarding packets from the access router to the > > clients. > > That means, actually the "EP" is the "access router" from IP perspective. > Maybe we should treat these as a "colocated EP and AR" case. Relying on AR > for DHCP messaging, ND, and router discovery while relying on the EP as the > "default gateway" basically splits one link into two (PaC<===>EP, and > PaC<-->AR). How does this impact the complexity? Or, what do we lose if we > mark the EP as "AR" as well? > To keep it simple, we should co-locate AR and EP together. If we are going to use L2 mechanisms for enforcement, then it makes sense to have the separation. I don't think it makes much sense to keep them separate for Ipsec access control. I will merge them together in my next revision. -mohan > Alper > > > > > This implies decrementing ttl for all packets which won't work with ND/RD > > messages > > that are sent from the access router to the PaCs. If EP and access router > > are the same > > box, then the ttl is not decremented for locally sourced packets e.g. > > ND/RD, as the > > packets are not forwarded anymore, just locally sourced. The picture in > > draft-ietf-pana-ipsec-00.txt assumes AR and EP are separated > > and hence bypasses all ND/RD. > > > >> I think supporting DHCP-based or autoconf based address configuration is > >> required. Additional methods, like IKE-based address config, is nice to > >> have. This is so that the impact of PANA on the access network > > architecture > >> is minimal. > >> > >> It sounds like both IP-in-IP transport mode SA and tunnel mode SA with > >> wildcard phase 2 identities support these... > >> > > See above. > > > > -mohan > > > >> Alper > >> > >> > >> > >> > >> > >>> With regard to the inner address assignment through IKE or IKEv2, > >>> just use the method(s) available for tunnel mode SA. > >>> > >>> I don't think we have to support IP-in-IP transport mode SA just because > > a > >>> particular address configuration > >>> method may not be supported by tunnel mode SA. > >>> > >>> Yoshihiro Ohba > >>> > >>> > >>> > >>> > >>> > >>> > >>> "Mohan > >>> Parthasarathy" To: "Alper Yegin" > >>> , > >>> >>> , "Bernard Aboba" > >>> l.net> , > > "James > >>> Kempf" > >>> Sent by: Subject: Re: [Pana] IP > > address > >>> configuration > >>> pana-admin@ietf. > >>> org > >>> > >>> > >>> 2003/11/21 17:38 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> > >>>>> > >>>>>> the PANA-Bind-Request message. PaC should attempt this configuration > >>>>> inside > >>>>>> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless > >>> address > >>>>>> autoconfiguration or DHCP can be used. > >>>>>> > >>>>> As i clarified in my other email, you don't setup the IPsec selectors > >>> until > >>>>> you have > >>>>> acquired the "routeable" (inner) address. And these addresses are used > >>> as > >>>>> selectors > >>>>> in the SPD. > >>>>> > >>>>>> Both pre-PANA and post-PANA addresses are used by the PaC at the same > >>>>> time, > >>>>>> though post-PANA addresses only appear inside the tunnel. A post-PANA > >>>>>> address has no significance for the PANA session or access control. > >>>>>> > >>>>> For tunnel mode SA, the outer addresses are not significant for access > >>>>> control. > >>>>> The inner addresses are used for access control. SPD selectors are > >>> inner > >>>>> addresses. > >>>> > >>>> Apparently I was still thinking in terms of IP-IP transport mode (the > >>> older > >>>> version of the draft). > >>>> > >>> Yes. The older version of the draft used just the link-local address as > >>> selectors. > >>> So, it is possible to do IPsec as soon as you are done with PANA. > >>> > >>>> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's > >>> phase > >>>> 2 identity, so that the inner IP addresses can be anything. And run > >>> address > >>>> autoconfiguration or DHCP inside the tunnel. > >>>> > >>> I am not sure whether the EP would accept the range. EP may just accept > >>> only > >>> one address as it lets any authenticated nodes spoof each other very > >>> easily. > >>> I have only seen ranges used by VPN gateways and not sure whether any > >>> host uses it or not. Again, if we can fix this in other ways e.g. using > >>> IP-IP transport mode, we should do that. > >>> > >>>> > >>>>> > >>>>>> If pre-PANA and post-PANA addresses are the same, they will be used > >>> both > >>>>>> inside and outside the tunnel (any issues with IPsec processing?). > >>> This > >>>>> can > >>>>> > >>>>> Some implementations have problem with this when the packets are > >>> destined to > >>>>> the tunnel end point address itself. > >>>> > >>>> Does this have anyting to do with the specification, or the intended > > use > >>> of > >>>> it? Or, is this simple a shortcoming or a bug in some implementations? > >>>> > >>> It is just an implementation artefact. I send packets to "DEST", route > >>> lookup > >>> returns a tunnel interface, which in turn encapsulated with outer header > >>> "DEST" , re-enters IP and loops again. This comes as a side effect of > >>> implementing IPsec tunnel mode SA as an "interface". This is not > >>> a real issue here as we can always bypass IPsec for messages sent > >>> to EP. > >>> > >>> -mohan > >>> > >>>>> Here, these will be PANA messages > >>>>> which will anway be bypassed (mentioned in the draft) i.e no IPsec for > >>> PANA > >>>>> messages flowing between PaC and PAA/EP. > >>>> > >>>> > >>>> > >>>> Alper > >>>> > >>>> > >>>>> > >>>>>> be the case when the client has a static IP address, or the DHCP > >>> address > >>>>>> assignment does not depend on the client identity. > >>>>>> > >>>>>> Comments? > >>>>>> > >>>>>> Alper > >>>>>> > >>>>> mohan > >>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Pana mailing list > >>>>>> Pana@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/pana > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pana mailing list > >>>>> Pana@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/pana > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pana mailing list > >>>> Pana@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >>> > >>> _______________________________________________ > >>> Pana mailing list > >>> Pana@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >>> > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Nov 26 14:39:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23843 for ; Wed, 26 Nov 2003 14:39:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5VF-0003k4-N8 for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 14:39:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQJd9Fl014378 for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 14:39:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5VF-0003jp-Fv for pana-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 14:39:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23801 for ; Wed, 26 Nov 2003 14:38:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5V8-0003ai-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 14:39:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP5V7-0003af-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 14:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5V6-0003iF-Hc; Wed, 26 Nov 2003 14:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5UF-0003ez-TN for pana@optimus.ietf.org; Wed, 26 Nov 2003 14:38:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23759 for ; Wed, 26 Nov 2003 14:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5UD-0003Zx-00 for pana@ietf.org; Wed, 26 Nov 2003 14:38:05 -0500 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1AP5UC-0003Zt-00 for pana@ietf.org; Wed, 26 Nov 2003 14:38:04 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 26 Nov 2003 19:38:03 -0000 Message-ID: <004f01c3b454$d1e47a10$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , Cc: "Bernard Aboba" , "Jari Arkko" , "James Kempf" , References: Subject: Re: [Pana] IP address configuration Date: Wed, 26 Nov 2003 11:36:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On 11/24/03 5:52 PM, "Mohan Parthasarathy" wrote: > > > Alper, > > > > Comments below.. > >> > >> I'm trying to figure out how we can: > >> - just maintain one DI for the PaC, and that is used as the local > > end-point > >> of the IPsec tunnel (when IPsec-based access control is used) > >> - any other IP address can be configured inside this tunnel. Router > >> discovery, ND, and DHCP can be run inside the tunnel. These IP addresses > >> should not be used as PANA DI. > >> > > If you are using IPsec based access control, the functionality of EP is > > different > > on how it is configured. If EP and the access router are different boxes, > > then > > EP acts as a layer 3 router forwarding packets from the access router to the > > clients. > > That means, actually the "EP" is the "access router" from IP perspective. > Maybe we should treat these as a "colocated EP and AR" case. Relying on AR > for DHCP messaging, ND, and router discovery while relying on the EP as the > "default gateway" basically splits one link into two (PaC<===>EP, and > PaC<-->AR). How does this impact the complexity? Or, what do we lose if we > mark the EP as "AR" as well? > To keep it simple, we should co-locate AR and EP together. If we are going to use L2 mechanisms for enforcement, then it makes sense to have the separation. I don't think it makes much sense to keep them separate for Ipsec access control. I will merge them together in my next revision. -mohan > Alper > > > > > This implies decrementing ttl for all packets which won't work with ND/RD > > messages > > that are sent from the access router to the PaCs. If EP and access router > > are the same > > box, then the ttl is not decremented for locally sourced packets e.g. > > ND/RD, as the > > packets are not forwarded anymore, just locally sourced. The picture in > > draft-ietf-pana-ipsec-00.txt assumes AR and EP are separated > > and hence bypasses all ND/RD. > > > >> I think supporting DHCP-based or autoconf based address configuration is > >> required. Additional methods, like IKE-based address config, is nice to > >> have. This is so that the impact of PANA on the access network > > architecture > >> is minimal. > >> > >> It sounds like both IP-in-IP transport mode SA and tunnel mode SA with > >> wildcard phase 2 identities support these... > >> > > See above. > > > > -mohan > > > >> Alper > >> > >> > >> > >> > >> > >>> With regard to the inner address assignment through IKE or IKEv2, > >>> just use the method(s) available for tunnel mode SA. > >>> > >>> I don't think we have to support IP-in-IP transport mode SA just because > > a > >>> particular address configuration > >>> method may not be supported by tunnel mode SA. > >>> > >>> Yoshihiro Ohba > >>> > >>> > >>> > >>> > >>> > >>> > >>> "Mohan > >>> Parthasarathy" To: "Alper Yegin" > >>> , > >>> >>> , "Bernard Aboba" > >>> l.net> , > > "James > >>> Kempf" > >>> Sent by: Subject: Re: [Pana] IP > > address > >>> configuration > >>> pana-admin@ietf. > >>> org > >>> > >>> > >>> 2003/11/21 17:38 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> > >>>>> > >>>>>> the PANA-Bind-Request message. PaC should attempt this configuration > >>>>> inside > >>>>>> the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless > >>> address > >>>>>> autoconfiguration or DHCP can be used. > >>>>>> > >>>>> As i clarified in my other email, you don't setup the IPsec selectors > >>> until > >>>>> you have > >>>>> acquired the "routeable" (inner) address. And these addresses are used > >>> as > >>>>> selectors > >>>>> in the SPD. > >>>>> > >>>>>> Both pre-PANA and post-PANA addresses are used by the PaC at the same > >>>>> time, > >>>>>> though post-PANA addresses only appear inside the tunnel. A post-PANA > >>>>>> address has no significance for the PANA session or access control. > >>>>>> > >>>>> For tunnel mode SA, the outer addresses are not significant for access > >>>>> control. > >>>>> The inner addresses are used for access control. SPD selectors are > >>> inner > >>>>> addresses. > >>>> > >>>> Apparently I was still thinking in terms of IP-IP transport mode (the > >>> older > >>>> version of the draft). > >>>> > >>> Yes. The older version of the draft used just the link-local address as > >>> selectors. > >>> So, it is possible to do IPsec as soon as you are done with PANA. > >>> > >>>> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's > >>> phase > >>>> 2 identity, so that the inner IP addresses can be anything. And run > >>> address > >>>> autoconfiguration or DHCP inside the tunnel. > >>>> > >>> I am not sure whether the EP would accept the range. EP may just accept > >>> only > >>> one address as it lets any authenticated nodes spoof each other very > >>> easily. > >>> I have only seen ranges used by VPN gateways and not sure whether any > >>> host uses it or not. Again, if we can fix this in other ways e.g. using > >>> IP-IP transport mode, we should do that. > >>> > >>>> > >>>>> > >>>>>> If pre-PANA and post-PANA addresses are the same, they will be used > >>> both > >>>>>> inside and outside the tunnel (any issues with IPsec processing?). > >>> This > >>>>> can > >>>>> > >>>>> Some implementations have problem with this when the packets are > >>> destined to > >>>>> the tunnel end point address itself. > >>>> > >>>> Does this have anyting to do with the specification, or the intended > > use > >>> of > >>>> it? Or, is this simple a shortcoming or a bug in some implementations? > >>>> > >>> It is just an implementation artefact. I send packets to "DEST", route > >>> lookup > >>> returns a tunnel interface, which in turn encapsulated with outer header > >>> "DEST" , re-enters IP and loops again. This comes as a side effect of > >>> implementing IPsec tunnel mode SA as an "interface". This is not > >>> a real issue here as we can always bypass IPsec for messages sent > >>> to EP. > >>> > >>> -mohan > >>> > >>>>> Here, these will be PANA messages > >>>>> which will anway be bypassed (mentioned in the draft) i.e no IPsec for > >>> PANA > >>>>> messages flowing between PaC and PAA/EP. > >>>> > >>>> > >>>> > >>>> Alper > >>>> > >>>> > >>>>> > >>>>>> be the case when the client has a static IP address, or the DHCP > >>> address > >>>>>> assignment does not depend on the client identity. > >>>>>> > >>>>>> Comments? > >>>>>> > >>>>>> Alper > >>>>>> > >>>>> mohan > >>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Pana mailing list > >>>>>> Pana@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/pana > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pana mailing list > >>>>> Pana@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/pana > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pana mailing list > >>>> Pana@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >>> > >>> _______________________________________________ > >>> Pana mailing list > >>> Pana@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >>> > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Nov 26 14:53:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24305 for ; Wed, 26 Nov 2003 14:53:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5ie-0004nb-TV; Wed, 26 Nov 2003 14:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5ic-0004nO-71 for pana@optimus.ietf.org; Wed, 26 Nov 2003 14:52:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24290 for ; Wed, 26 Nov 2003 14:52:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5iZ-0003lw-00 for pana@ietf.org; Wed, 26 Nov 2003 14:52:55 -0500 Received: from smtp801.mail.sc5.yahoo.com ([66.163.168.180]) by ietf-mx with smtp (Exim 4.12) id 1AP5iY-0003lt-00 for pana@ietf.org; Wed, 26 Nov 2003 14:52:54 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 26 Nov 2003 19:52:54 -0000 Message-ID: <005201c3b456$e4e006a0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , "Soliman Hesham" , Cc: "Bernard Aboba" , "Jari Arkko" , "James Kempf" , References: Subject: Re: [Pana] IP address configuration Date: Wed, 26 Nov 2003 11:52:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > >> I'm trying to figure out how we can: > >> - just maintain one DI for the PaC, and that is used as the > >> local end-point > >> of the IPsec tunnel (when IPsec-based access control is used) > > > >> - any other IP address can be configured inside this tunnel. Router > >> discovery, ND, and DHCP can be run inside the tunnel. These > >> IP addresses > >> should not be used as PANA DI. > >> > >> I think supporting DHCP-based or autoconf based address > >> configuration is > >> required. Additional methods, like IKE-based address config, > >> is nice to > >> have. > > > > => When you talk about the IPsec tunnel are you always > > referring to the use of IPsec for access control? I mean > > you're never referring to a tunnel to a remote VPN in a > > corporate many hops away, right? > > Yes, I'm not talking about a VPN tunnel to some corporate network. > > > > > If the above is correct I don't know how stateless address > > autoconfig is expected to work through that tunnel > > This is what I'm trying to understand too. What are the issues there? > It has been defined before e.g. ISATAP. But i can see a few problems here. 1) How do you send unsolicited RAs to so many PaCs ? Normally it is sent to all-nodes multicast address that reaches all PaCs. Now, you have to send multiple of them each with different protection for each of the PaC. Solicited RAs work. So, this would be a limitation. 2) The secure channel is between PaC and the AR. Two nodes cannot communicate with each other in a secure fashion. But this may not be a big limitation as the only on-link prefix is the link-local prefix which is any way not used for normal communication. -mohan > > and why > > it needs to?? > > Running router discovery and neighbor discovery (for DAD) inside the IPsec > tunnel would provide additional security to the network. This ensures, for > example, PaC does not receive unauthorized router advertisements. > > > A node could use one address only, same in > > the outer and inner src fields. What am I missing? > > It could. But in the case of IPv6, using the link-local address as the outer > address, and the global address as the inner address makes sense to me. > > Alper > > > > > > > Hesham > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Nov 26 14:53:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24320 for ; Wed, 26 Nov 2003 14:53:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5ii-0004oI-Bl for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 14:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQJr4CE018484 for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 14:53:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5ii-0004o3-5S for pana-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 14:53:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24294 for ; Wed, 26 Nov 2003 14:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5if-0003m3-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 14:53:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP5if-0003m0-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 14:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5ie-0004nb-TV; Wed, 26 Nov 2003 14:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5ic-0004nO-71 for pana@optimus.ietf.org; Wed, 26 Nov 2003 14:52:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24290 for ; Wed, 26 Nov 2003 14:52:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5iZ-0003lw-00 for pana@ietf.org; Wed, 26 Nov 2003 14:52:55 -0500 Received: from smtp801.mail.sc5.yahoo.com ([66.163.168.180]) by ietf-mx with smtp (Exim 4.12) id 1AP5iY-0003lt-00 for pana@ietf.org; Wed, 26 Nov 2003 14:52:54 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 26 Nov 2003 19:52:54 -0000 Message-ID: <005201c3b456$e4e006a0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , "Soliman Hesham" , Cc: "Bernard Aboba" , "Jari Arkko" , "James Kempf" , References: Subject: Re: [Pana] IP address configuration Date: Wed, 26 Nov 2003 11:52:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >> I'm trying to figure out how we can: > >> - just maintain one DI for the PaC, and that is used as the > >> local end-point > >> of the IPsec tunnel (when IPsec-based access control is used) > > > >> - any other IP address can be configured inside this tunnel. Router > >> discovery, ND, and DHCP can be run inside the tunnel. These > >> IP addresses > >> should not be used as PANA DI. > >> > >> I think supporting DHCP-based or autoconf based address > >> configuration is > >> required. Additional methods, like IKE-based address config, > >> is nice to > >> have. > > > > => When you talk about the IPsec tunnel are you always > > referring to the use of IPsec for access control? I mean > > you're never referring to a tunnel to a remote VPN in a > > corporate many hops away, right? > > Yes, I'm not talking about a VPN tunnel to some corporate network. > > > > > If the above is correct I don't know how stateless address > > autoconfig is expected to work through that tunnel > > This is what I'm trying to understand too. What are the issues there? > It has been defined before e.g. ISATAP. But i can see a few problems here. 1) How do you send unsolicited RAs to so many PaCs ? Normally it is sent to all-nodes multicast address that reaches all PaCs. Now, you have to send multiple of them each with different protection for each of the PaC. Solicited RAs work. So, this would be a limitation. 2) The secure channel is between PaC and the AR. Two nodes cannot communicate with each other in a secure fashion. But this may not be a big limitation as the only on-link prefix is the link-local prefix which is any way not used for normal communication. -mohan > > and why > > it needs to?? > > Running router discovery and neighbor discovery (for DAD) inside the IPsec > tunnel would provide additional security to the network. This ensures, for > example, PaC does not receive unauthorized router advertisements. > > > A node could use one address only, same in > > the outer and inner src fields. What am I missing? > > It could. But in the case of IPv6, using the link-local address as the outer > address, and the global address as the inner address makes sense to me. > > Alper > > > > > > > Hesham > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Nov 26 20:03:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07488 for ; Wed, 26 Nov 2003 20:03:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAYe-0000uF-L5; Wed, 26 Nov 2003 20:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAY2-0000tb-N7 for pana@optimus.ietf.org; Wed, 26 Nov 2003 20:02:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07473 for ; Wed, 26 Nov 2003 20:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAY0-0000L4-00 for pana@ietf.org; Wed, 26 Nov 2003 20:02:20 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1APAY0-0000KZ-00 for pana@ietf.org; Wed, 26 Nov 2003 20:02:20 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 20:01:50 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042036@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Soliman Hesham , Yoshihiro.Ohba@tais.com, mohanp@sbcglobal.net Cc: Bernard Aboba , Jari Arkko , James Kempf , pana@ietf.org Subject: RE: [Pana] IP address configuration Date: Wed, 26 Nov 2003 20:01:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > > > If the above is correct I don't know how stateless address > > autoconfig is expected to work through that tunnel > > This is what I'm trying to understand too. What are the issues there? > > > and why > > it needs to?? > > Running router discovery and neighbor discovery (for DAD) > inside the IPsec > tunnel would provide additional security to the network. > This ensures, for > example, PaC does not receive unauthorized router advertisements. => I think this might be treading in unchartered items ;) I mean, is securing ND really part of the PANA charter? I think there are lots of complex issues involved here, for one IPsec does not have multicast capabilities. Having more than one AR/EP is complex, if at all possible. Running address autoconfig through the tunnel seems to require changes to the IP stack to get the order of events right. Given that there are other efforts to protect Router discovery, I think we need not reinvent this here as a side task. > > A node could use one address only, same in > > the outer and inner src fields. What am I missing? > > It could. But in the case of IPv6, using the link-local > address as the outer > address, and the global address as the inner address makes > sense to me. => Why does it make sense? Hesham _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Nov 26 20:03:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07503 for ; Wed, 26 Nov 2003 20:03:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAYh-0000ut-8g for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 20:03:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR1330p003519 for pana-archive@odin.ietf.org; Wed, 26 Nov 2003 20:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAYh-0000ug-3H for pana-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 20:03:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07478 for ; Wed, 26 Nov 2003 20:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAYf-0000LQ-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 20:03:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APAYe-0000LN-00 for pana-web-archive@ietf.org; Wed, 26 Nov 2003 20:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAYe-0000uF-L5; Wed, 26 Nov 2003 20:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAY2-0000tb-N7 for pana@optimus.ietf.org; Wed, 26 Nov 2003 20:02:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07473 for ; Wed, 26 Nov 2003 20:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAY0-0000L4-00 for pana@ietf.org; Wed, 26 Nov 2003 20:02:20 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1APAY0-0000KZ-00 for pana@ietf.org; Wed, 26 Nov 2003 20:02:20 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 20:01:50 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042036@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alper Yegin'" , Soliman Hesham , Yoshihiro.Ohba@tais.com, mohanp@sbcglobal.net Cc: Bernard Aboba , Jari Arkko , James Kempf , pana@ietf.org Subject: RE: [Pana] IP address configuration Date: Wed, 26 Nov 2003 20:01:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > > > If the above is correct I don't know how stateless address > > autoconfig is expected to work through that tunnel > > This is what I'm trying to understand too. What are the issues there? > > > and why > > it needs to?? > > Running router discovery and neighbor discovery (for DAD) > inside the IPsec > tunnel would provide additional security to the network. > This ensures, for > example, PaC does not receive unauthorized router advertisements. => I think this might be treading in unchartered items ;) I mean, is securing ND really part of the PANA charter? I think there are lots of complex issues involved here, for one IPsec does not have multicast capabilities. Having more than one AR/EP is complex, if at all possible. Running address autoconfig through the tunnel seems to require changes to the IP stack to get the order of events right. Given that there are other efforts to protect Router discovery, I think we need not reinvent this here as a side task. > > A node could use one address only, same in > > the outer and inner src fields. What am I missing? > > It could. But in the case of IPv6, using the link-local > address as the outer > address, and the global address as the inner address makes > sense to me. => Why does it make sense? Hesham _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 27 11:00:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11513 for ; Thu, 27 Nov 2003 11:00:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOYl-0007R8-N9; Thu, 27 Nov 2003 11:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOYe-0007QJ-2m for pana@optimus.ietf.org; Thu, 27 Nov 2003 10:59:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11470 for ; Thu, 27 Nov 2003 10:59:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APOYb-00024C-00 for pana@ietf.org; Thu, 27 Nov 2003 10:59:53 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1APOYa-00023s-00 for pana@ietf.org; Thu, 27 Nov 2003 10:59:52 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id hARFxH9s010223; Thu, 27 Nov 2003 16:59:17 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003112716591595:5580 ; Thu, 27 Nov 2003 16:59:15 +0100 Message-ID: <3FC61F54.4090809@alcatel.fr> Date: Thu, 27 Nov 2003 16:59:16 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org, MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba , Julien Bournelle Subject: Re: [Pana] PAA-2-EP protocol requirements References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/27/2003 16:59:15, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/27/2003 16:59:17 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi all, please see below: Alper Yegin a =E9crit: >>below are some other PAA-2-EP functionnalities (open list). should we >>consider them as also required ? not required at all ? supported >>elsewhere ? any alternative ? >> >>a) Inactive peer detection: >>The protocol used between PAA and EP should be able to detect inactive >>peer within an appropriate time period. This can be achieved by having >>both the EP and remote PAA constantly verify their connection to each >>other via keep-alive messages: a heartbeat in fact. > > > I'm not sure how much "explicit support" we need for this from the PAA2EP > protocol. There can always be ad-hoc solutions to this. For example,=20 running > some request-reply messages between the PAA and EP can be used as a > keep-alive. I can imagine an implementation resorting to such techniques > when the protocol does not have a dedicated facility.... ok. my feeling is you think it's not a requirement at all :-) >>b) Stateful approach: >>The protocol must allow to maintain some states in the PAA in order for >>an EP that went down and came back up, or an EP that is being introduced >>in the network to (re-)synchronize with the PAA. > > > We can assume PAA always has the associated state. It'd have a list of > authorized PaCs and their attributes... I don't think this is=20 something for > PAA2EP protocol to worry about... I agree, for sure the PAA maintains each PaC state, but the question here is rather about the PAA-EP communication: * does the PAA should maintain each EP state ? the reason for such a feature can be the one cited above (for an EP=20 crashing and coming back up, etc.) anyway, these questions bring up some PANA framework issues related to=20 the EP-PAA relation when we have multiple PAAs in the access network: * can a given EP relate to multiple PAAs ? * does a given PAA configure all the EPs with the same rules ? * or only the one which treat the traffic coming from the PaC ? * inter-PAAs communication ? etc... comments on these "issues" are warmly welcome ! >>In general terms, the PAA-EP protocol needs to support the stateful >>model between the PAA and the EP(s) and some other mechanism for the EP >>to learn the policies currently in effect on that access network. >> >>c) Accounting/Feedback from the EPs: >>The PAA must have an efficient way to to get the accounting information >>of PaC from EP since the PAA may be a client of the AAA backend >>infrastructure. > > > Getting statistics from the EP makes sense. For example, in the case of > SNMP, if we get the counters from the EP this is good enough. The AAA=20 client > sitting on the PAA can turn these into accoutning records. should the PAA poll the EPs to get these counters when needed (the SNMP=20 way...) or the EPs are supposed to send them periodically ? anyway, this should be somehow a requirement. > Alper > thanks, yacine >>d) ???? >> >> >>thanks, >>Yacine El Mghazli >> >> >> >> >> >> >>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >>Pana mailing list >>Pana@ietf.org >>https://www1.ietf.org/mailman/listinfo/pana >> > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 27 11:00:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11528 for ; Thu, 27 Nov 2003 11:00:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOYq-0007S8-Ey for pana-archive@odin.ietf.org; Thu, 27 Nov 2003 11:00:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARG081X028642 for pana-archive@odin.ietf.org; Thu, 27 Nov 2003 11:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOYp-0007Rt-Nt for pana-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 11:00:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11489 for ; Thu, 27 Nov 2003 10:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APOYn-00024l-00 for pana-web-archive@ietf.org; Thu, 27 Nov 2003 11:00:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APOYm-00024i-00 for pana-web-archive@ietf.org; Thu, 27 Nov 2003 11:00:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOYl-0007R8-N9; Thu, 27 Nov 2003 11:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOYe-0007QJ-2m for pana@optimus.ietf.org; Thu, 27 Nov 2003 10:59:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11470 for ; Thu, 27 Nov 2003 10:59:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APOYb-00024C-00 for pana@ietf.org; Thu, 27 Nov 2003 10:59:53 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1APOYa-00023s-00 for pana@ietf.org; Thu, 27 Nov 2003 10:59:52 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id hARFxH9s010223; Thu, 27 Nov 2003 16:59:17 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003112716591595:5580 ; Thu, 27 Nov 2003 16:59:15 +0100 Message-ID: <3FC61F54.4090809@alcatel.fr> Date: Thu, 27 Nov 2003 16:59:16 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org, MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba , Julien Bournelle Subject: Re: [Pana] PAA-2-EP protocol requirements References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/27/2003 16:59:15, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/27/2003 16:59:17 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hi all, please see below: Alper Yegin a =E9crit: >>below are some other PAA-2-EP functionnalities (open list). should we >>consider them as also required ? not required at all ? supported >>elsewhere ? any alternative ? >> >>a) Inactive peer detection: >>The protocol used between PAA and EP should be able to detect inactive >>peer within an appropriate time period. This can be achieved by having >>both the EP and remote PAA constantly verify their connection to each >>other via keep-alive messages: a heartbeat in fact. > > > I'm not sure how much "explicit support" we need for this from the PAA2EP > protocol. There can always be ad-hoc solutions to this. For example,=20 running > some request-reply messages between the PAA and EP can be used as a > keep-alive. I can imagine an implementation resorting to such techniques > when the protocol does not have a dedicated facility.... ok. my feeling is you think it's not a requirement at all :-) >>b) Stateful approach: >>The protocol must allow to maintain some states in the PAA in order for >>an EP that went down and came back up, or an EP that is being introduced >>in the network to (re-)synchronize with the PAA. > > > We can assume PAA always has the associated state. It'd have a list of > authorized PaCs and their attributes... I don't think this is=20 something for > PAA2EP protocol to worry about... I agree, for sure the PAA maintains each PaC state, but the question here is rather about the PAA-EP communication: * does the PAA should maintain each EP state ? the reason for such a feature can be the one cited above (for an EP=20 crashing and coming back up, etc.) anyway, these questions bring up some PANA framework issues related to=20 the EP-PAA relation when we have multiple PAAs in the access network: * can a given EP relate to multiple PAAs ? * does a given PAA configure all the EPs with the same rules ? * or only the one which treat the traffic coming from the PaC ? * inter-PAAs communication ? etc... comments on these "issues" are warmly welcome ! >>In general terms, the PAA-EP protocol needs to support the stateful >>model between the PAA and the EP(s) and some other mechanism for the EP >>to learn the policies currently in effect on that access network. >> >>c) Accounting/Feedback from the EPs: >>The PAA must have an efficient way to to get the accounting information >>of PaC from EP since the PAA may be a client of the AAA backend >>infrastructure. > > > Getting statistics from the EP makes sense. For example, in the case of > SNMP, if we get the counters from the EP this is good enough. The AAA=20 client > sitting on the PAA can turn these into accoutning records. should the PAA poll the EPs to get these counters when needed (the SNMP=20 way...) or the EPs are supposed to send them periodically ? anyway, this should be somehow a requirement. > Alper > thanks, yacine >>d) ???? >> >> >>thanks, >>Yacine El Mghazli >> >> >> >> >> >> >>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >>Pana mailing list >>Pana@ietf.org >>https://www1.ietf.org/mailman/listinfo/pana >> > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 27 11:18:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11902 for ; Thu, 27 Nov 2003 11:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOq9-0008Ii-4X; Thu, 27 Nov 2003 11:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOpY-0008ID-5H for pana@optimus.ietf.org; Thu, 27 Nov 2003 11:17:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11857 for ; Thu, 27 Nov 2003 11:17:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APOpX-0002Gq-00 for pana@ietf.org; Thu, 27 Nov 2003 11:17:23 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1APOpW-0002GD-00 for pana@ietf.org; Thu, 27 Nov 2003 11:17:22 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id hARGGm9s026373; Thu, 27 Nov 2003 17:16:48 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003112717164633:5764 ; Thu, 27 Nov 2003 17:16:46 +0100 Message-ID: <3FC6236E.5070308@alcatel.fr> Date: Thu, 27 Nov 2003 17:16:46 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Julien Bournelle Cc: pana@ietf.org, MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba Subject: Re: [Pana] Re: PAA-2-EP protocol requirements References: <3FC205C6.3020902@alcatel.fr> <20031126155314.GP582@ipv6-5.int-evry.fr> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/27/2003 17:16:46, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/27/2003 17:16:47 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hello Julien, Julien Bournelle a =E9crit: > Hi all, > > >> 2) One-to-many PAA-EP relation: This means that there might be >> multiple EPs per PAA. > > > If we want to use IPsec between PaC and EP, the EP must be a router. > AS the PAA must be located exactly one IP hop away from the PaC, > there must be no EP between PaC and PAA. So it means that EP, PaC and > PAA are on the same IP subnet (Am I wrong ?). So, I wonder if it a > valid scenario to have > multiple EPs per PAA if we use IPsec. > > Any ideas ? this requirement says that a given PAA can relate to n EPs. in your case n=3D1. did I misunderstand your statement ? Yacine > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 27 11:18:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11917 for ; Thu, 27 Nov 2003 11:18:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOqD-0008JV-SL for pana-archive@odin.ietf.org; Thu, 27 Nov 2003 11:18:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARGI5S7031950 for pana-archive@odin.ietf.org; Thu, 27 Nov 2003 11:18:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOqD-0008JF-MB for pana-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 11:18:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11870 for ; Thu, 27 Nov 2003 11:17:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APOqC-0002HO-00 for pana-web-archive@ietf.org; Thu, 27 Nov 2003 11:18:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APOqC-0002HK-00 for pana-web-archive@ietf.org; Thu, 27 Nov 2003 11:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOq9-0008Ii-4X; Thu, 27 Nov 2003 11:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APOpY-0008ID-5H for pana@optimus.ietf.org; Thu, 27 Nov 2003 11:17:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11857 for ; Thu, 27 Nov 2003 11:17:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APOpX-0002Gq-00 for pana@ietf.org; Thu, 27 Nov 2003 11:17:23 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1APOpW-0002GD-00 for pana@ietf.org; Thu, 27 Nov 2003 11:17:22 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id hARGGm9s026373; Thu, 27 Nov 2003 17:16:48 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003112717164633:5764 ; Thu, 27 Nov 2003 17:16:46 +0100 Message-ID: <3FC6236E.5070308@alcatel.fr> Date: Thu, 27 Nov 2003 17:16:46 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Julien Bournelle Cc: pana@ietf.org, MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba Subject: Re: [Pana] Re: PAA-2-EP protocol requirements References: <3FC205C6.3020902@alcatel.fr> <20031126155314.GP582@ipv6-5.int-evry.fr> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/27/2003 17:16:46, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/27/2003 17:16:47 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hello Julien, Julien Bournelle a =E9crit: > Hi all, > > >> 2) One-to-many PAA-EP relation: This means that there might be >> multiple EPs per PAA. > > > If we want to use IPsec between PaC and EP, the EP must be a router. > AS the PAA must be located exactly one IP hop away from the PaC, > there must be no EP between PaC and PAA. So it means that EP, PaC and > PAA are on the same IP subnet (Am I wrong ?). So, I wonder if it a > valid scenario to have > multiple EPs per PAA if we use IPsec. > > Any ideas ? this requirement says that a given PAA can relate to n EPs. in your case n=3D1. did I misunderstand your statement ? Yacine > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Nov 27 12:08:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12840 for ; Thu, 27 Nov 2003 12:08:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APPcX-0002Jl-3I; Thu, 27 Nov 2003 12:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APPbr-00029G-OO for pana@optimus.ietf.org; Thu, 27 Nov 2003 12:07:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12823 for ; Thu, 27 Nov 2003 12:07:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APPbq-0002kj-00 for pana@ietf.org; Thu, 27 Nov 2003 12:07:18 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1APPbp-0002kf-00 for pana@ietf.org; Thu, 27 Nov 2003 12:07:18 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id B5EAB36244; Thu, 27 Nov 2003 17:55:22 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id B77E43F431; Thu, 27 Nov 2003 17:55:14 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003112717551419990 ; Thu, 27 Nov 2003 17:55:14 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 04BC13F4CA; Thu, 27 Nov 2003 17:38:18 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1APP8y-0003Ib-Fn; Thu, 27 Nov 2003 17:37:28 +0100 Date: Thu, 27 Nov 2003 17:37:28 +0100 From: Julien Bournelle To: Yacine.El_Mghazli@alcatel.fr Cc: pana@ietf.org, MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba Subject: Re: [Pana] Re: PAA-2-EP protocol requirements Message-ID: <20031127163728.GX582@ipv6-5.int-evry.fr> References: <3FC205C6.3020902@alcatel.fr> <20031126155314.GP582@ipv6-5.int-evry.fr> <3FC6236E.5070308@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC6236E.5070308@alcatel.fr> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hello yacine, On Thu, Nov 27, 2003 at 05:16:46PM +0100, Yacine.El_Mghazli@alcatel.fr wrote: > >> 2) One-to-many PAA-EP relation: This means that there might be > >> multiple EPs per PAA. > > > > If we want to use IPsec between PaC and EP, the EP must be a router. > > AS the PAA must be located exactly one IP hop away from the PaC, > > there must be no EP between PaC and PAA. So it means that EP, PaC and > > PAA are on the same IP subnet (Am I wrong ?). So, I wonder if it a > > valid scenario to have > > multiple EPs per PAA if we use IPsec. > > > > Any ideas ? > > this requirement says that a given PAA can relate to n EPs. > in your case n=1. > > did I misunderstand your statement ? I guess so. I just wonder if people consider to have multiple EPs (with 1 PAA) on the same IP subnet as a relevant scenario. -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Nov 27 12:08:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12855 for ; Thu, 27 Nov 2003 12:08:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APPca-0002LV-Pa for pana-archive@odin.ietf.org; Thu, 27 Nov 2003 12:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARH84av009015 for pana-archive@odin.ietf.org; Thu, 27 Nov 2003 12:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APPca-0002L7-5m for pana-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 12:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12834 for ; Thu, 27 Nov 2003 12:07:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APPcY-0002l9-00 for pana-web-archive@ietf.org; Thu, 27 Nov 2003 12:08:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APPcY-0002l6-00 for pana-web-archive@ietf.org; Thu, 27 Nov 2003 12:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APPcX-0002Jl-3I; Thu, 27 Nov 2003 12:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APPbr-00029G-OO for pana@optimus.ietf.org; Thu, 27 Nov 2003 12:07:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12823 for ; Thu, 27 Nov 2003 12:07:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APPbq-0002kj-00 for pana@ietf.org; Thu, 27 Nov 2003 12:07:18 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1APPbp-0002kf-00 for pana@ietf.org; Thu, 27 Nov 2003 12:07:18 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id B5EAB36244; Thu, 27 Nov 2003 17:55:22 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id B77E43F431; Thu, 27 Nov 2003 17:55:14 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003112717551419990 ; Thu, 27 Nov 2003 17:55:14 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 04BC13F4CA; Thu, 27 Nov 2003 17:38:18 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1APP8y-0003Ib-Fn; Thu, 27 Nov 2003 17:37:28 +0100 Date: Thu, 27 Nov 2003 17:37:28 +0100 From: Julien Bournelle To: Yacine.El_Mghazli@alcatel.fr Cc: pana@ietf.org, MORAND Lionel FTRD/DAC/ISS , Yoshihiro Ohba Subject: Re: [Pana] Re: PAA-2-EP protocol requirements Message-ID: <20031127163728.GX582@ipv6-5.int-evry.fr> References: <3FC205C6.3020902@alcatel.fr> <20031126155314.GP582@ipv6-5.int-evry.fr> <3FC6236E.5070308@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC6236E.5070308@alcatel.fr> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hello yacine, On Thu, Nov 27, 2003 at 05:16:46PM +0100, Yacine.El_Mghazli@alcatel.fr wrote: > >> 2) One-to-many PAA-EP relation: This means that there might be > >> multiple EPs per PAA. > > > > If we want to use IPsec between PaC and EP, the EP must be a router. > > AS the PAA must be located exactly one IP hop away from the PaC, > > there must be no EP between PaC and PAA. So it means that EP, PaC and > > PAA are on the same IP subnet (Am I wrong ?). So, I wonder if it a > > valid scenario to have > > multiple EPs per PAA if we use IPsec. > > > > Any ideas ? > > this requirement says that a given PAA can relate to n EPs. > in your case n=1. > > did I misunderstand your statement ? I guess so. I just wonder if people consider to have multiple EPs (with 1 PAA) on the same IP subnet as a relevant scenario. -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 28 07:05:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24811 for ; Fri, 28 Nov 2003 07:05:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhMr-0002uu-Kh; Fri, 28 Nov 2003 07:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhMA-0002uH-Bg for pana@optimus.ietf.org; Fri, 28 Nov 2003 07:04:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24768 for ; Fri, 28 Nov 2003 07:04:02 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APhM5-0000xs-00 for pana@ietf.org; Fri, 28 Nov 2003 07:04:13 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1APhM5-0000xn-00 for pana@ietf.org; Fri, 28 Nov 2003 07:04:13 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hASC4DQ27625 for ; Fri, 28 Nov 2003 14:04:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 28 Nov 2003 14:04:11 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 14:04:11 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 14:04:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pana] IP address configuration Date: Fri, 28 Nov 2003 14:04:10 +0200 Message-ID: Thread-Topic: [Pana] IP address configuration Thread-Index: AcO0Vut63JGbPFzkScGeUMyc7guNOABT+qhA To: X-OriginalArrivalTime: 28 Nov 2003 12:04:11.0325 (UTC) FILETIME=[BBE886D0:01C3B5A7] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I took people off from cc and to fields. A more general comment here. I tried to catch up with=20 about 50 emails on the pana mailing list and found that=20 the scenarios we are talking about with PANA+IPSec and IP address configuration etc. are becoming a bit complex. I'm not up-to-date with all the documents, but it seems=20 that we have too many moving parts and architectural decisions that do not all affect plain PANA. Br, - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Mohan Parthasarathy > Sent: 26 November, 2003 21:53 > To: Alper Yegin; Soliman Hesham; Yoshihiro.Ohba@tais.com > Cc: Bernard Aboba; Jari Arkko; James Kempf; pana@ietf.org > Subject: Re: [Pana] IP address configuration >=20 >=20 >=20 > > >> I'm trying to figure out how we can: > > >> - just maintain one DI for the PaC, and that is used as the > > >> local end-point > > >> of the IPsec tunnel (when IPsec-based access control is used) > > > > > >> - any other IP address can be configured inside this=20 > tunnel. Router > > >> discovery, ND, and DHCP can be run inside the tunnel. These > > >> IP addresses > > >> should not be used as PANA DI. > > >> > > >> I think supporting DHCP-based or autoconf based address > > >> configuration is > > >> required. Additional methods, like IKE-based address config, > > >> is nice to > > >> have. > > > > > > =3D> When you talk about the IPsec tunnel are you always > > > referring to the use of IPsec for access control? I mean > > > you're never referring to a tunnel to a remote VPN in a > > > corporate many hops away, right? > > > > Yes, I'm not talking about a VPN tunnel to some corporate network. > > > > > > > > If the above is correct I don't know how stateless address > > > autoconfig is expected to work through that tunnel > > > > This is what I'm trying to understand too. What are the=20 > issues there? > > > It has been defined before e.g. ISATAP. But i can see a few problems > here. >=20 > 1) How do you send unsolicited RAs to so many PaCs ? Normally > it is sent to all-nodes multicast address that reaches all=20 > PaCs. Now, you > have to send multiple of them each with different protection for each > of the PaC. Solicited RAs work. So, this would be a limitation. >=20 > 2) The secure channel is between PaC and the AR. Two nodes cannot > communicate with each other in a secure fashion. But=20 > this may not be > a big limitation as the only on-link prefix is the=20 > link-local prefix > which is > any way not used for normal communication. >=20 > -mohan >=20 > > > and why > > > it needs to?? > > > > Running router discovery and neighbor discovery (for DAD)=20 > inside the IPsec > > tunnel would provide additional security to the network.=20 > This ensures, for > > example, PaC does not receive unauthorized router advertisements. > > > > > A node could use one address only, same in > > > the outer and inner src fields. What am I missing? > > > > It could. But in the case of IPv6, using the link-local=20 > address as the > outer > > address, and the global address as the inner address makes=20 > sense to me. > > > > Alper > > > > > > > > > > > Hesham > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 28 07:05:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24829 for ; Fri, 28 Nov 2003 07:05:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhMv-0002vh-S1 for pana-archive@odin.ietf.org; Fri, 28 Nov 2003 07:05:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASC55Aq011258 for pana-archive@odin.ietf.org; Fri, 28 Nov 2003 07:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhMv-0002vV-NG for pana-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 07:05:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24802 for ; Fri, 28 Nov 2003 07:04:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APhMr-0000zM-00 for pana-web-archive@ietf.org; Fri, 28 Nov 2003 07:05:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APhMq-0000zJ-00 for pana-web-archive@ietf.org; Fri, 28 Nov 2003 07:05:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhMr-0002uu-Kh; Fri, 28 Nov 2003 07:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhMA-0002uH-Bg for pana@optimus.ietf.org; Fri, 28 Nov 2003 07:04:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24768 for ; Fri, 28 Nov 2003 07:04:02 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APhM5-0000xs-00 for pana@ietf.org; Fri, 28 Nov 2003 07:04:13 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1APhM5-0000xn-00 for pana@ietf.org; Fri, 28 Nov 2003 07:04:13 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hASC4DQ27625 for ; Fri, 28 Nov 2003 14:04:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 28 Nov 2003 14:04:11 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 14:04:11 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 14:04:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pana] IP address configuration Date: Fri, 28 Nov 2003 14:04:10 +0200 Message-ID: Thread-Topic: [Pana] IP address configuration Thread-Index: AcO0Vut63JGbPFzkScGeUMyc7guNOABT+qhA To: X-OriginalArrivalTime: 28 Nov 2003 12:04:11.0325 (UTC) FILETIME=[BBE886D0:01C3B5A7] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I took people off from cc and to fields. A more general comment here. I tried to catch up with=20 about 50 emails on the pana mailing list and found that=20 the scenarios we are talking about with PANA+IPSec and IP address configuration etc. are becoming a bit complex. I'm not up-to-date with all the documents, but it seems=20 that we have too many moving parts and architectural decisions that do not all affect plain PANA. Br, - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Mohan Parthasarathy > Sent: 26 November, 2003 21:53 > To: Alper Yegin; Soliman Hesham; Yoshihiro.Ohba@tais.com > Cc: Bernard Aboba; Jari Arkko; James Kempf; pana@ietf.org > Subject: Re: [Pana] IP address configuration >=20 >=20 >=20 > > >> I'm trying to figure out how we can: > > >> - just maintain one DI for the PaC, and that is used as the > > >> local end-point > > >> of the IPsec tunnel (when IPsec-based access control is used) > > > > > >> - any other IP address can be configured inside this=20 > tunnel. Router > > >> discovery, ND, and DHCP can be run inside the tunnel. These > > >> IP addresses > > >> should not be used as PANA DI. > > >> > > >> I think supporting DHCP-based or autoconf based address > > >> configuration is > > >> required. Additional methods, like IKE-based address config, > > >> is nice to > > >> have. > > > > > > =3D> When you talk about the IPsec tunnel are you always > > > referring to the use of IPsec for access control? I mean > > > you're never referring to a tunnel to a remote VPN in a > > > corporate many hops away, right? > > > > Yes, I'm not talking about a VPN tunnel to some corporate network. > > > > > > > > If the above is correct I don't know how stateless address > > > autoconfig is expected to work through that tunnel > > > > This is what I'm trying to understand too. What are the=20 > issues there? > > > It has been defined before e.g. ISATAP. But i can see a few problems > here. >=20 > 1) How do you send unsolicited RAs to so many PaCs ? Normally > it is sent to all-nodes multicast address that reaches all=20 > PaCs. Now, you > have to send multiple of them each with different protection for each > of the PaC. Solicited RAs work. So, this would be a limitation. >=20 > 2) The secure channel is between PaC and the AR. Two nodes cannot > communicate with each other in a secure fashion. But=20 > this may not be > a big limitation as the only on-link prefix is the=20 > link-local prefix > which is > any way not used for normal communication. >=20 > -mohan >=20 > > > and why > > > it needs to?? > > > > Running router discovery and neighbor discovery (for DAD)=20 > inside the IPsec > > tunnel would provide additional security to the network.=20 > This ensures, for > > example, PaC does not receive unauthorized router advertisements. > > > > > A node could use one address only, same in > > > the outer and inner src fields. What am I missing? > > > > It could. But in the case of IPv6, using the link-local=20 > address as the > outer > > address, and the global address as the inner address makes=20 > sense to me. > > > > Alper > > > > > > > > > > > Hesham > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Nov 28 07:24:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25387 for ; Fri, 28 Nov 2003 07:24:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhfF-0003WS-1l; Fri, 28 Nov 2003 07:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhep-0003W2-Eh for pana@optimus.ietf.org; Fri, 28 Nov 2003 07:23:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25363 for ; Fri, 28 Nov 2003 07:23:23 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APheo-0001Fq-00 for pana@ietf.org; Fri, 28 Nov 2003 07:23:34 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1APheo-0001Fn-00 for pana@ietf.org; Fri, 28 Nov 2003 07:23:34 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hASCNWi23475 for ; Fri, 28 Nov 2003 14:23:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 28 Nov 2003 14:23:31 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 14:23:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pana] IP address configuration Date: Fri, 28 Nov 2003 14:23:30 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122331@esebe023.ntc.nokia.com> Thread-Topic: [Pana] IP address configuration Thread-Index: AcO0Vut63JGbPFzkScGeUMyc7guNOABT+qhAAACxr2A= To: , X-OriginalArrivalTime: 28 Nov 2003 12:23:31.0754 (UTC) FILETIME=[6F93F0A0:01C3B5AA] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable A good point, Dan. This may not be actually that surprising... after all, 802.11 people found out that having completely=20 separate protocols for authentication (802.1X) and other=20 aspects of getting connectivity (802.11 management frames)=20 makes it very complicated to secure the "other part". You can't authenticate before you have taken care of=20 some other things, and it's difficult to protect the=20 other things if you haven't authenticated yet. I think we have similar chicken-and-egg problems here:=20 if getting IP address is completely separate from PANA, how to secure it? And is it done before or after PANA? I guess this is one of the reasons why IKE combines into one protocol much more than just authentication (AH/ESP SA negotiation, IP address configuration, etc.). Hmm, does this lead to EAP-over-DHCP? :-) (well, that was intended as a joke, but perhaps it could be useful in some circumstances :-) Best regards, Pasi > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Dan.Forsberg@nokia.com > Sent: Friday, November 28, 2003 2:04 PM > To: pana@ietf.org > Subject: RE: [Pana] IP address configuration >=20 >=20 > I took people off from cc and to fields. >=20 > A more general comment here. I tried to catch up with=20 > about 50 emails on the pana mailing list and found that=20 > the scenarios we are talking about with PANA+IPSec and IP > address configuration etc. are becoming a bit complex. >=20 > I'm not up-to-date with all the documents, but it seems=20 > that we have too many moving parts and architectural > decisions that do not all affect plain PANA. >=20 > Br, > - Dan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Nov 28 07:24:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25402 for ; Fri, 28 Nov 2003 07:24:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhfI-0003X4-53 for pana-archive@odin.ietf.org; Fri, 28 Nov 2003 07:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASCO4Me013577 for pana-archive@odin.ietf.org; Fri, 28 Nov 2003 07:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhfH-0003Wu-TC for pana-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 07:24:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25379 for ; Fri, 28 Nov 2003 07:23:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APhfH-0001GF-00 for pana-web-archive@ietf.org; Fri, 28 Nov 2003 07:24:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APhfH-0001GC-00 for pana-web-archive@ietf.org; Fri, 28 Nov 2003 07:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhfF-0003WS-1l; Fri, 28 Nov 2003 07:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhep-0003W2-Eh for pana@optimus.ietf.org; Fri, 28 Nov 2003 07:23:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25363 for ; Fri, 28 Nov 2003 07:23:23 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APheo-0001Fq-00 for pana@ietf.org; Fri, 28 Nov 2003 07:23:34 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1APheo-0001Fn-00 for pana@ietf.org; Fri, 28 Nov 2003 07:23:34 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hASCNWi23475 for ; Fri, 28 Nov 2003 14:23:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 28 Nov 2003 14:23:31 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 14:23:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pana] IP address configuration Date: Fri, 28 Nov 2003 14:23:30 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122331@esebe023.ntc.nokia.com> Thread-Topic: [Pana] IP address configuration Thread-Index: AcO0Vut63JGbPFzkScGeUMyc7guNOABT+qhAAACxr2A= To: , X-OriginalArrivalTime: 28 Nov 2003 12:23:31.0754 (UTC) FILETIME=[6F93F0A0:01C3B5AA] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable A good point, Dan. This may not be actually that surprising... after all, 802.11 people found out that having completely=20 separate protocols for authentication (802.1X) and other=20 aspects of getting connectivity (802.11 management frames)=20 makes it very complicated to secure the "other part". You can't authenticate before you have taken care of=20 some other things, and it's difficult to protect the=20 other things if you haven't authenticated yet. I think we have similar chicken-and-egg problems here:=20 if getting IP address is completely separate from PANA, how to secure it? And is it done before or after PANA? I guess this is one of the reasons why IKE combines into one protocol much more than just authentication (AH/ESP SA negotiation, IP address configuration, etc.). Hmm, does this lead to EAP-over-DHCP? :-) (well, that was intended as a joke, but perhaps it could be useful in some circumstances :-) Best regards, Pasi > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Dan.Forsberg@nokia.com > Sent: Friday, November 28, 2003 2:04 PM > To: pana@ietf.org > Subject: RE: [Pana] IP address configuration >=20 >=20 > I took people off from cc and to fields. >=20 > A more general comment here. I tried to catch up with=20 > about 50 emails on the pana mailing list and found that=20 > the scenarios we are talking about with PANA+IPSec and IP > address configuration etc. are becoming a bit complex. >=20 > I'm not up-to-date with all the documents, but it seems=20 > that we have too many moving parts and architectural > decisions that do not all affect plain PANA. >=20 > Br, > - Dan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sun Nov 30 17:40:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15108 for ; Sun, 30 Nov 2003 17:40:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaEV-00055w-5U; Sun, 30 Nov 2003 17:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaDi-00054K-Cx for pana@optimus.ietf.org; Sun, 30 Nov 2003 17:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15077 for ; Sun, 30 Nov 2003 17:38:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaDf-0006a5-00 for pana@ietf.org; Sun, 30 Nov 2003 17:39:11 -0500 Received: from law12-f66.law12.hotmail.com ([64.4.19.66] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQaDf-0006Zo-00 for pana@ietf.org; Sun, 30 Nov 2003 17:39:11 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 14:38:41 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 22:38:41 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: Yacine.El_Mghazli@alcatel.fr, alper@docomolabs-usa.com Cc: pana@ietf.org, lionel.morand@francetelecom.com, yohba@tari.toshiba.com, Julien.Bournelle@int-evry.fr Subject: Re: [Pana] PAA-2-EP protocol requirements Date: Sun, 30 Nov 2003 14:38:41 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 22:38:41.0432 (UTC) FILETIME=[B4495980:01C3B792] Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , (sorry for the late and batched responses due to my travels) > > I'm not sure how much "explicit support" we need for this from the >PAA2EP > > protocol. There can always be ad-hoc solutions to this. For example, >running > > some request-reply messages between the PAA and EP can be used as a > > keep-alive. I can imagine an implementation resorting to such techniques > > when the protocol does not have a dedicated facility.... > >ok. my feeling is you think it's not a requirement at all :-) I don't think it is a hard requirement on the PAA2EP protocol. It may be a requirement of the architecture which can be satisfied by other means... > > >>b) Stateful approach: > >>The protocol must allow to maintain some states in the PAA in order for > >>an EP that went down and came back up, or an EP that is being introduced > >>in the network to (re-)synchronize with the PAA. > > > > > > We can assume PAA always has the associated state. It'd have a list of > > authorized PaCs and their attributes... I don't think this is something >for > > PAA2EP protocol to worry about... > >I agree, for sure the PAA maintains each PaC state, but the question >here is rather about the PAA-EP communication: >* does the PAA should maintain each EP state ? No. All PAA needs to do is to maintain state per PaC, and be able to associate a PaC with one or more EPs. So, if an EP goes down, PAA can identify the associated PaC state and bring the EP up-to-date. >the reason for such a feature can be the one cited above (for an EP >crashing and coming back up, etc.) > > > >anyway, these questions bring up some PANA framework issues related to the >EP-PAA relation when we have multiple PAAs in the access network: >* can a given EP relate to multiple PAAs ? I think we had discussed that there may be multiple PAAs on a link, but the PaC will run PANA with one of them. So, I guess yes, an EP might be associated with more than one PAA. >* does a given PAA configure all the EPs with the same rules ? The provisioning info pushed to EPs for a given PaC would be the same. >* or only the one which treat the traffic coming from the PaC ? Well, PAA decides which EPs should receive the information. And this depends on the topology. For a multi-access link with multiple access routers as EPs, each router will be provisioned with the PaC-specific info. On the other hand, if a switch is the EP, as a L2 access device there is only one connected to PaC and that single device is the EP. It will be provisioned with the PaC-specific info. >* inter-PAAs communication ? Why do we need this for? Alper >etc... > >comments on these "issues" are warmly welcome ! > > > > >>In general terms, the PAA-EP protocol needs to support the stateful > >>model between the PAA and the EP(s) and some other mechanism for the EP > >>to learn the policies currently in effect on that access network. > >> > >>c) Accounting/Feedback from the EPs: > >>The PAA must have an efficient way to to get the accounting information > >>of PaC from EP since the PAA may be a client of the AAA backend > >>infrastructure. > > > > > > Getting statistics from the EP makes sense. For example, in the case of > > SNMP, if we get the counters from the EP this is good enough. The AAA >client > > sitting on the PAA can turn these into accoutning records. > >should the PAA poll the EPs to get these counters when needed (the SNMP >way...) or the EPs are supposed to send them periodically ? > >anyway, this should be somehow a requirement. > > > > Alper > > > >thanks, >yacine > > >>d) ???? > >> > >> > >>thanks, > >>Yacine El Mghazli > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>Pana mailing list > >>Pana@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pana > >> > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana _________________________________________________________________ Set yourself up for fun at home! Get tips on home entertainment equipment, video game reviews, and more here. http://special.msn.com/home/homeent.armx _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sun Nov 30 17:40:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15124 for ; Sun, 30 Nov 2003 17:40:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaEZ-00056m-H1 for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 17:40:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUMe72v019630 for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 17:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaEY-00056X-Pl for pana-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 17:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15104 for ; Sun, 30 Nov 2003 17:39:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaEW-0006ao-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 17:40:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQaEV-0006ak-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 17:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaEV-00055w-5U; Sun, 30 Nov 2003 17:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaDi-00054K-Cx for pana@optimus.ietf.org; Sun, 30 Nov 2003 17:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15077 for ; Sun, 30 Nov 2003 17:38:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaDf-0006a5-00 for pana@ietf.org; Sun, 30 Nov 2003 17:39:11 -0500 Received: from law12-f66.law12.hotmail.com ([64.4.19.66] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQaDf-0006Zo-00 for pana@ietf.org; Sun, 30 Nov 2003 17:39:11 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 14:38:41 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 22:38:41 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: Yacine.El_Mghazli@alcatel.fr, alper@docomolabs-usa.com Cc: pana@ietf.org, lionel.morand@francetelecom.com, yohba@tari.toshiba.com, Julien.Bournelle@int-evry.fr Subject: Re: [Pana] PAA-2-EP protocol requirements Date: Sun, 30 Nov 2003 14:38:41 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 22:38:41.0432 (UTC) FILETIME=[B4495980:01C3B792] Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , (sorry for the late and batched responses due to my travels) > > I'm not sure how much "explicit support" we need for this from the >PAA2EP > > protocol. There can always be ad-hoc solutions to this. For example, >running > > some request-reply messages between the PAA and EP can be used as a > > keep-alive. I can imagine an implementation resorting to such techniques > > when the protocol does not have a dedicated facility.... > >ok. my feeling is you think it's not a requirement at all :-) I don't think it is a hard requirement on the PAA2EP protocol. It may be a requirement of the architecture which can be satisfied by other means... > > >>b) Stateful approach: > >>The protocol must allow to maintain some states in the PAA in order for > >>an EP that went down and came back up, or an EP that is being introduced > >>in the network to (re-)synchronize with the PAA. > > > > > > We can assume PAA always has the associated state. It'd have a list of > > authorized PaCs and their attributes... I don't think this is something >for > > PAA2EP protocol to worry about... > >I agree, for sure the PAA maintains each PaC state, but the question >here is rather about the PAA-EP communication: >* does the PAA should maintain each EP state ? No. All PAA needs to do is to maintain state per PaC, and be able to associate a PaC with one or more EPs. So, if an EP goes down, PAA can identify the associated PaC state and bring the EP up-to-date. >the reason for such a feature can be the one cited above (for an EP >crashing and coming back up, etc.) > > > >anyway, these questions bring up some PANA framework issues related to the >EP-PAA relation when we have multiple PAAs in the access network: >* can a given EP relate to multiple PAAs ? I think we had discussed that there may be multiple PAAs on a link, but the PaC will run PANA with one of them. So, I guess yes, an EP might be associated with more than one PAA. >* does a given PAA configure all the EPs with the same rules ? The provisioning info pushed to EPs for a given PaC would be the same. >* or only the one which treat the traffic coming from the PaC ? Well, PAA decides which EPs should receive the information. And this depends on the topology. For a multi-access link with multiple access routers as EPs, each router will be provisioned with the PaC-specific info. On the other hand, if a switch is the EP, as a L2 access device there is only one connected to PaC and that single device is the EP. It will be provisioned with the PaC-specific info. >* inter-PAAs communication ? Why do we need this for? Alper >etc... > >comments on these "issues" are warmly welcome ! > > > > >>In general terms, the PAA-EP protocol needs to support the stateful > >>model between the PAA and the EP(s) and some other mechanism for the EP > >>to learn the policies currently in effect on that access network. > >> > >>c) Accounting/Feedback from the EPs: > >>The PAA must have an efficient way to to get the accounting information > >>of PaC from EP since the PAA may be a client of the AAA backend > >>infrastructure. > > > > > > Getting statistics from the EP makes sense. For example, in the case of > > SNMP, if we get the counters from the EP this is good enough. The AAA >client > > sitting on the PAA can turn these into accoutning records. > >should the PAA poll the EPs to get these counters when needed (the SNMP >way...) or the EPs are supposed to send them periodically ? > >anyway, this should be somehow a requirement. > > > > Alper > > > >thanks, >yacine > > >>d) ???? > >> > >> > >>thanks, > >>Yacine El Mghazli > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>Pana mailing list > >>Pana@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pana > >> > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana _________________________________________________________________ Set yourself up for fun at home! Get tips on home entertainment equipment, video game reviews, and more here. http://special.msn.com/home/homeent.armx _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sun Nov 30 17:43:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15212 for ; Sun, 30 Nov 2003 17:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaHM-0005Fk-V2; Sun, 30 Nov 2003 17:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaGR-0005Ab-Gy for pana@optimus.ietf.org; Sun, 30 Nov 2003 17:42:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15174 for ; Sun, 30 Nov 2003 17:41:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaGO-0006bt-00 for pana@ietf.org; Sun, 30 Nov 2003 17:42:00 -0500 Received: from law12-f7.law12.hotmail.com ([64.4.19.7] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQaGO-0006bX-00 for pana@ietf.org; Sun, 30 Nov 2003 17:42:00 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 14:41:30 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 22:41:30 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: Julien.Bournelle@int-evry.fr, Yacine.El_Mghazli@alcatel.fr Cc: pana@ietf.org, lionel.morand@francetelecom.com, yohba@tari.toshiba.com Subject: Re: [Pana] Re: PAA-2-EP protocol requirements Date: Sun, 30 Nov 2003 14:41:30 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 22:41:30.0484 (UTC) FILETIME=[190CA340:01C3B793] Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , >If we want to use IPsec between PaC and EP, the EP must be a router. AS >the PAA must be located exactly one IP hop away from the PaC, there must >be no EP between PaC and PAA. So it means that EP, PaC and PAA are >on the same IP subnet (Am I wrong ?). So, I wonder if it a valid scenario >to have >multiple EPs per PAA if we use IPsec. If the access routers are used as EP and there are more than one.... PAA may be co-located with one of the access routers, or may be hosted on a dedicated server on the same multi-access link shared by the access routers and PaCs. Alper _________________________________________________________________ Is there a gadget-lover on your gift list? MSN Shopping has lined up some good bets! http://shopping.msn.com _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sun Nov 30 17:43:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15227 for ; Sun, 30 Nov 2003 17:43:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaHR-0005In-HK for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 17:43:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUMh5dr020375 for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 17:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaHR-0005IY-Am for pana-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 17:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15180 for ; Sun, 30 Nov 2003 17:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaHO-0006c6-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 17:43:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQaHO-0006c3-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 17:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaHM-0005Fk-V2; Sun, 30 Nov 2003 17:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaGR-0005Ab-Gy for pana@optimus.ietf.org; Sun, 30 Nov 2003 17:42:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15174 for ; Sun, 30 Nov 2003 17:41:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaGO-0006bt-00 for pana@ietf.org; Sun, 30 Nov 2003 17:42:00 -0500 Received: from law12-f7.law12.hotmail.com ([64.4.19.7] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQaGO-0006bX-00 for pana@ietf.org; Sun, 30 Nov 2003 17:42:00 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 14:41:30 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 22:41:30 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: Julien.Bournelle@int-evry.fr, Yacine.El_Mghazli@alcatel.fr Cc: pana@ietf.org, lionel.morand@francetelecom.com, yohba@tari.toshiba.com Subject: Re: [Pana] Re: PAA-2-EP protocol requirements Date: Sun, 30 Nov 2003 14:41:30 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 22:41:30.0484 (UTC) FILETIME=[190CA340:01C3B793] Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , >If we want to use IPsec between PaC and EP, the EP must be a router. AS >the PAA must be located exactly one IP hop away from the PaC, there must >be no EP between PaC and PAA. So it means that EP, PaC and PAA are >on the same IP subnet (Am I wrong ?). So, I wonder if it a valid scenario >to have >multiple EPs per PAA if we use IPsec. If the access routers are used as EP and there are more than one.... PAA may be co-located with one of the access routers, or may be hosted on a dedicated server on the same multi-access link shared by the access routers and PaCs. Alper _________________________________________________________________ Is there a gadget-lover on your gift list? MSN Shopping has lined up some good bets! http://shopping.msn.com _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sun Nov 30 18:00:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15623 for ; Sun, 30 Nov 2003 18:00:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaXr-0006KR-Hj; Sun, 30 Nov 2003 18:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaXE-0006JH-DL for pana@optimus.ietf.org; Sun, 30 Nov 2003 17:59:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15554 for ; Sun, 30 Nov 2003 17:59:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaXB-0006nG-00 for pana@ietf.org; Sun, 30 Nov 2003 17:59:21 -0500 Received: from law12-f117.law12.hotmail.com ([64.4.19.117] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQaXB-0006ml-00 for pana@ietf.org; Sun, 30 Nov 2003 17:59:21 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 14:58:51 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 22:58:51 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: mohanp@sbcglobal.net, Yoshihiro.Ohba@tais.com Cc: aboba@internaut.com, jari.arkko@piuha.net, kempf@docomolabs-usa.com, pana@ietf.org Subject: Re: [Pana] IP address configuration Date: Sun, 30 Nov 2003 14:58:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 22:58:51.0613 (UTC) FILETIME=[859C50D0:01C3B795] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA15555 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >When configuration of post-PANA address occurs before IKE/IKEv2, >it might be difficult to support the ISP selection model over shared med= ia. >So supporting this case only would be a limitation. I presume by "ISP selection" you are referring to the ability to allocate an IP address from the address pool of the selected ISP. Yes, the IPsec tunnel is bound to the PANA session, hence it implies the selected ISP. As such, this can be leveraged during the address allocation to identify the right address pool, ISP, etc. But this is not the only way. Even if the address configuration takes place outside the IPsec tunnel, some other identifier that is bound to the PANA session can be used during the process. For example, the source address of DHCP request (the DI of PaC) or the client ID field set to PANA session ID might help. >When configuration of post-PANA address occurs inside the IPsec tunnel >or inside IKE/IKEv2, it would be able to support the ISP selection model >over shared media. At least post-PANA address configuration is supporte= d >inside IKEv2 with Configuration Payload exchange. Post-PANA address=20 >configuration with DHCPv4 inside IPsec tunnel is supported by IKE +=20 >RFC3456. I am not really sure if there is no problem >with other schemes for post-PANA address configuration inside IPsec tunn= el. >I have a concern on allowing a PaC to specify wildcard address range in=20 >IPsec SA negotiation for the purpose of running Neighbor Discovery insid= e=20 >the IPsec tunnel, especially when the PaC is also a router, >it could totally affect routing behavior. Could you please elaborate on this.... Alper _________________________________________________________________ >From the hottest toys to tips on keeping fit this winter, you=92ll find a= =20 range of helpful holiday info here. =20 http://special.msn.com/network/happyholidays.armx _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sun Nov 30 18:00:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15647 for ; Sun, 30 Nov 2003 18:00:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaXu-0006LT-QV for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 18:00:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUN062Q024384 for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 18:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaXu-0006L9-78 for pana-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 18:00:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15582 for ; Sun, 30 Nov 2003 17:59:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaXr-0006o7-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 18:00:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQaXr-0006o4-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 18:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaXr-0006KR-Hj; Sun, 30 Nov 2003 18:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQaXE-0006JH-DL for pana@optimus.ietf.org; Sun, 30 Nov 2003 17:59:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15554 for ; Sun, 30 Nov 2003 17:59:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQaXB-0006nG-00 for pana@ietf.org; Sun, 30 Nov 2003 17:59:21 -0500 Received: from law12-f117.law12.hotmail.com ([64.4.19.117] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQaXB-0006ml-00 for pana@ietf.org; Sun, 30 Nov 2003 17:59:21 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 14:58:51 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 22:58:51 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: mohanp@sbcglobal.net, Yoshihiro.Ohba@tais.com Cc: aboba@internaut.com, jari.arkko@piuha.net, kempf@docomolabs-usa.com, pana@ietf.org Subject: Re: [Pana] IP address configuration Date: Sun, 30 Nov 2003 14:58:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 22:58:51.0613 (UTC) FILETIME=[859C50D0:01C3B795] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA15555 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >When configuration of post-PANA address occurs before IKE/IKEv2, >it might be difficult to support the ISP selection model over shared med= ia. >So supporting this case only would be a limitation. I presume by "ISP selection" you are referring to the ability to allocate an IP address from the address pool of the selected ISP. Yes, the IPsec tunnel is bound to the PANA session, hence it implies the selected ISP. As such, this can be leveraged during the address allocation to identify the right address pool, ISP, etc. But this is not the only way. Even if the address configuration takes place outside the IPsec tunnel, some other identifier that is bound to the PANA session can be used during the process. For example, the source address of DHCP request (the DI of PaC) or the client ID field set to PANA session ID might help. >When configuration of post-PANA address occurs inside the IPsec tunnel >or inside IKE/IKEv2, it would be able to support the ISP selection model >over shared media. At least post-PANA address configuration is supporte= d >inside IKEv2 with Configuration Payload exchange. Post-PANA address=20 >configuration with DHCPv4 inside IPsec tunnel is supported by IKE +=20 >RFC3456. I am not really sure if there is no problem >with other schemes for post-PANA address configuration inside IPsec tunn= el. >I have a concern on allowing a PaC to specify wildcard address range in=20 >IPsec SA negotiation for the purpose of running Neighbor Discovery insid= e=20 >the IPsec tunnel, especially when the PaC is also a router, >it could totally affect routing behavior. Could you please elaborate on this.... Alper _________________________________________________________________ >From the hottest toys to tips on keeping fit this winter, you=92ll find a= =20 range of helpful holiday info here. =20 http://special.msn.com/network/happyholidays.armx _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sun Nov 30 18:24:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17175 for ; Sun, 30 Nov 2003 18:24:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQav2-0008Ba-Qq; Sun, 30 Nov 2003 18:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQauT-0008BK-IH for pana@optimus.ietf.org; Sun, 30 Nov 2003 18:23:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17150 for ; Sun, 30 Nov 2003 18:23:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQauQ-00071w-00 for pana@ietf.org; Sun, 30 Nov 2003 18:23:22 -0500 Received: from law12-f27.law12.hotmail.com ([64.4.19.27] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQauQ-00071t-00 for pana@ietf.org; Sun, 30 Nov 2003 18:23:22 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 15:22:52 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 23:22:51 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: H.Soliman@flarion.com, alper@docomolabs-usa.com, Yoshihiro.Ohba@tais.com, mohanp@sbcglobal.net Cc: aboba@internaut.com, jari.arkko@piuha.net, kempf@docomolabs-usa.com, pana@ietf.org Subject: RE: [Pana] IP address configuration Date: Sun, 30 Nov 2003 15:22:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 23:22:52.0315 (UTC) FILETIME=[E055FEB0:01C3B798] Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > Running router discovery and neighbor discovery (for DAD) > > inside the IPsec > > tunnel would provide additional security to the network. > > This ensures, for > > example, PaC does not receive unauthorized router advertisements. > >=> I think this might be treading in unchartered items ;) >I mean, is securing ND really part of the PANA charter? If I have a secure channel between the two end-points, I'd try yo carry as much of my communication as possible inside this channel, unless this creates additional unjustified complexity. This is where I'm coming from... I don't think this solves 100% of the problems associated with securing ND and router discovery, but I think it can help... >I think there are lots of complex issues involved here, >for one IPsec does not have multicast capabilities. Having more >than one AR/EP is complex, if at all possible. Running address >autoconfig through the tunnel seems to require changes to the >IP stack to get the order of events right. OK, we need to look at how DAD and router discovery works on point-to-point interfaces... > >Given that there are other efforts to protect Router >discovery, I think we need not reinvent this here >as a side task. > > > > A node could use one address only, same in > > > the outer and inner src fields. What am I missing? > > > > It could. But in the case of IPv6, using the link-local > > address as the outer > > address, and the global address as the inner address makes > > sense to me. > >=> Why does it make sense? The outer address is only needed to shuttle real data packets to the EP. Also, from the PANA perspective, it'd be a much cleaner architecture if there is only one IP address visible and it is used as the device ID. Filters on the EP are only aware of this address. And there is no reason to change this address in time... These all say "link-local" to me... On the other hand, do you see any issues with using a link-local address as ther outer address of the IPsec tunnel? Alper > >Hesham > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana _________________________________________________________________ Gift-shop online from the comfort of home at MSN Shopping! No crowds, free parking. http://shopping.msn.com _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sun Nov 30 18:24:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17190 for ; Sun, 30 Nov 2003 18:24:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQav7-0008CF-8Z for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 18:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUNO5HV031503 for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 18:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQav6-0008C2-FD for pana-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 18:24:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17157 for ; Sun, 30 Nov 2003 18:23:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQav3-00072C-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 18:24:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQav3-000729-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 18:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQav2-0008Ba-Qq; Sun, 30 Nov 2003 18:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQauT-0008BK-IH for pana@optimus.ietf.org; Sun, 30 Nov 2003 18:23:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17150 for ; Sun, 30 Nov 2003 18:23:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQauQ-00071w-00 for pana@ietf.org; Sun, 30 Nov 2003 18:23:22 -0500 Received: from law12-f27.law12.hotmail.com ([64.4.19.27] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQauQ-00071t-00 for pana@ietf.org; Sun, 30 Nov 2003 18:23:22 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 15:22:52 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 23:22:51 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: H.Soliman@flarion.com, alper@docomolabs-usa.com, Yoshihiro.Ohba@tais.com, mohanp@sbcglobal.net Cc: aboba@internaut.com, jari.arkko@piuha.net, kempf@docomolabs-usa.com, pana@ietf.org Subject: RE: [Pana] IP address configuration Date: Sun, 30 Nov 2003 15:22:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 23:22:52.0315 (UTC) FILETIME=[E055FEB0:01C3B798] Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > > Running router discovery and neighbor discovery (for DAD) > > inside the IPsec > > tunnel would provide additional security to the network. > > This ensures, for > > example, PaC does not receive unauthorized router advertisements. > >=> I think this might be treading in unchartered items ;) >I mean, is securing ND really part of the PANA charter? If I have a secure channel between the two end-points, I'd try yo carry as much of my communication as possible inside this channel, unless this creates additional unjustified complexity. This is where I'm coming from... I don't think this solves 100% of the problems associated with securing ND and router discovery, but I think it can help... >I think there are lots of complex issues involved here, >for one IPsec does not have multicast capabilities. Having more >than one AR/EP is complex, if at all possible. Running address >autoconfig through the tunnel seems to require changes to the >IP stack to get the order of events right. OK, we need to look at how DAD and router discovery works on point-to-point interfaces... > >Given that there are other efforts to protect Router >discovery, I think we need not reinvent this here >as a side task. > > > > A node could use one address only, same in > > > the outer and inner src fields. What am I missing? > > > > It could. But in the case of IPv6, using the link-local > > address as the outer > > address, and the global address as the inner address makes > > sense to me. > >=> Why does it make sense? The outer address is only needed to shuttle real data packets to the EP. Also, from the PANA perspective, it'd be a much cleaner architecture if there is only one IP address visible and it is used as the device ID. Filters on the EP are only aware of this address. And there is no reason to change this address in time... These all say "link-local" to me... On the other hand, do you see any issues with using a link-local address as ther outer address of the IPsec tunnel? Alper > >Hesham > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana _________________________________________________________________ Gift-shop online from the comfort of home at MSN Shopping! No crowds, free parking. http://shopping.msn.com _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sun Nov 30 18:39:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17467 for ; Sun, 30 Nov 2003 18:39:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQb9Y-0000Pv-D8; Sun, 30 Nov 2003 18:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQb96-0000Pe-9W for pana@optimus.ietf.org; Sun, 30 Nov 2003 18:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17450 for ; Sun, 30 Nov 2003 18:38:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQb93-00079e-00 for pana@ietf.org; Sun, 30 Nov 2003 18:38:29 -0500 Received: from law12-f47.law12.hotmail.com ([64.4.19.47] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQb92-00079R-00 for pana@ietf.org; Sun, 30 Nov 2003 18:38:28 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 15:37:58 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 23:37:58 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: pana@ietf.org Date: Sun, 30 Nov 2003 15:37:58 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 23:37:58.0686 (UTC) FILETIME=[FC933BE0:01C3B79A] Subject: [Pana] Use of unspecified IP addresses (IETF58 discussion) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hello, The use of unspecified IP addresses with PANA clients was discussed at the latest IETF meeting. The discussion notes and the associated presentation slides can be found at: http://www.toshiba.com/tari/pana/ietf58-pana.html People who were not at the meeting might want to look at them and provide feedback. - Chairs _________________________________________________________________ Gift-shop online from the comfort of home at MSN Shopping! No crowds, free parking. http://shopping.msn.com _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sun Nov 30 18:39:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17483 for ; Sun, 30 Nov 2003 18:39:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQb9a-0000Qh-M8 for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 18:39:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUNd2q0001645 for pana-archive@odin.ietf.org; Sun, 30 Nov 2003 18:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQb9a-0000QS-Gl for pana-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 18:39:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17461 for ; Sun, 30 Nov 2003 18:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQb9X-00079s-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 18:38:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQb9X-00079p-00 for pana-web-archive@ietf.org; Sun, 30 Nov 2003 18:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQb9Y-0000Pv-D8; Sun, 30 Nov 2003 18:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQb96-0000Pe-9W for pana@optimus.ietf.org; Sun, 30 Nov 2003 18:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17450 for ; Sun, 30 Nov 2003 18:38:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQb93-00079e-00 for pana@ietf.org; Sun, 30 Nov 2003 18:38:29 -0500 Received: from law12-f47.law12.hotmail.com ([64.4.19.47] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AQb92-00079R-00 for pana@ietf.org; Sun, 30 Nov 2003 18:38:28 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Nov 2003 15:37:58 -0800 Received: from 81.213.12.48 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 30 Nov 2003 23:37:58 GMT X-Originating-IP: [81.213.12.48] X-Originating-Email: [aeyegin@hotmail.com] From: "Alper Yegin" To: pana@ietf.org Date: Sun, 30 Nov 2003 15:37:58 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2003 23:37:58.0686 (UTC) FILETIME=[FC933BE0:01C3B79A] Subject: [Pana] Use of unspecified IP addresses (IETF58 discussion) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hello, The use of unspecified IP addresses with PANA clients was discussed at the latest IETF meeting. The discussion notes and the associated presentation slides can be found at: http://www.toshiba.com/tari/pana/ietf58-pana.html People who were not at the meeting might want to look at them and provide feedback. - Chairs _________________________________________________________________ Gift-shop online from the comfort of home at MSN Shopping! No crowds, free parking. http://shopping.msn.com _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana