From jari.arkko@lmf.ericsson.se Thu Jul 1 18:18:15 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05447 for ; Thu, 1 Jul 2004 18:18:14 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i61MIDAh012314 for ; Fri, 2 Jul 2004 00:18:13 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 00:18:12 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L79V1KDS; Fri, 2 Jul 2004 00:18:13 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i61MICXA018142; Fri, 2 Jul 2004 00:18:12 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i61MHLIt018326; Fri, 2 Jul 2004 00:17:21 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i61MHLi3018325; Fri, 2 Jul 2004 00:17:21 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i61MHJIt018318 for ; Fri, 2 Jul 2004 00:17:19 +0200 (MET DST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i61MHAQ29365; Thu, 1 Jul 2004 15:17:10 -0700 X-mProtect: <200407012217> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddy7eOf; Thu, 01 Jul 2004 15:17:08 PDT Message-ID: <40E48E86.2080401@iprg.nokia.com> Date: Thu, 01 Jul 2004 15:21:58 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> In-Reply-To: <40E38A23.9030500@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 01 Jul 2004 22:18:12.0519 (UTC) FILETIME=[4C329B70:01C45FB9] Content-Transfer-Encoding: 7bit Greg Daley wrote: > In the MIPv6 case, it may be possible to exchange delegation > chain messages over the home tunnel to ensure that the MN knows > that the HA is authorized to be a router for the prefix. > Also, the MN could sign the key of the router and send back > a proxy certificate by a similar message. > > There may have to be a control plane request in the message > sent back to the router which could request use of the address, > and proxying. With MIPv6 this is already done if the > proxy certificate is sent within a BU/BAck. sounds like an idea that would work. maybe you should write up a draft on this. Vijay -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 1 23:31:29 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19115 for ; Thu, 1 Jul 2004 23:31:29 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i623VTWR015608 for ; Fri, 2 Jul 2004 05:31:30 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 05:31:29 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MFZ7A2P1; Fri, 2 Jul 2004 05:31:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i623VSXA020684; Fri, 2 Jul 2004 05:31:28 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i623UYIt014915; Fri, 2 Jul 2004 05:30:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i623UXfC014914; Fri, 2 Jul 2004 05:30:33 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i623UVIt014886 for ; Fri, 2 Jul 2004 05:30:31 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LBZK5BF5LS8WWXIH@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Fri, 02 Jul 2004 13:26:09 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BC6EC80034; Fri, 02 Jul 2004 13:26:08 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id A5BFF3C009; Fri, 02 Jul 2004 13:26:08 +1000 (EST) Date: Fri, 02 Jul 2004 13:26:08 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Vijay Devarapalli Cc: Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40E4D5D0.6090907@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 02 Jul 2004 03:31:29.0214 (UTC) FILETIME=[0FE6A5E0:01C45FE5] Content-Transfer-Encoding: 7BIT Hi Vijay, I'll see if I can get some time before the drafts deadline. I think we'd have to talk about functional requirements rather than implementation specifics. We will still have to look carefully at the existing SEND to see if the security model matches though... :) Greg Vijay Devarapalli wrote: > Greg Daley wrote: > >> In the MIPv6 case, it may be possible to exchange delegation >> chain messages over the home tunnel to ensure that the MN knows >> that the HA is authorized to be a router for the prefix. >> Also, the MN could sign the key of the router and send back >> a proxy certificate by a similar message. >> >> There may have to be a control plane request in the message >> sent back to the router which could request use of the address, >> and proxying. With MIPv6 this is already done if the >> proxy certificate is sent within a BU/BAck. > > > sounds like an idea that would work. maybe you should > write up a draft on this. > > Vijay -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jul 6 14:07:39 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08004 for ; Tue, 6 Jul 2004 14:07:39 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i66I7dAh007481 for ; Tue, 6 Jul 2004 20:07:39 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Jul 2004 20:07:39 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q9FGDC; Tue, 6 Jul 2004 20:07:39 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i66I7cXA022762; Tue, 6 Jul 2004 20:07:38 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i66I6WIt027803; Tue, 6 Jul 2004 20:06:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i66I6WC9027802; Tue, 6 Jul 2004 20:06:32 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i66I6TIt027786 for ; Tue, 6 Jul 2004 20:06:30 +0200 (MET DST) Message-ID: <03b501c46384$1118fe20$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jean-Michel COMBES" , References: <012701c45d01$e4a05600$4aa1c10a@rd.francetelecom.fr> Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Tue, 6 Jul 2004 11:07:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 06 Jul 2004 18:07:39.0258 (UTC) FILETIME=[1FBDC5A0:01C46384] Content-Transfer-Encoding: 7bit Jean-Michel, Proxy ND and the details of how to use address certificates for end hosts are two issues the WG decided to leave out for now, until it is clearer whether there is any interest in implementing and deploying SEND. As a result of the IESG review, the RFC will have the following paragraph (or something approx. like it) at the end of Section 1: Out of scope for this document is the use of identity certificates provisioned on end hosts for authorizing address use, and security of ND when the entity defending an address is not the same as the entity claiming that adddress (also known as "proxy ND"). These are extensions of SEND that may be treated in separate documents should the need arise. I think this should address the issue you've raised. jak ----- Original Message ----- From: "Jean-Michel COMBES" To: Sent: Monday, June 28, 2004 4:20 AM Subject: Problem of interaction between SEND(CGA) and the IPv6 mobility > Hi, > > IMO, it would be necessary to add a warning in the Security Considerations > section regarding the interaction between SEND(CGA) and the IPv6 mobility > protocols. > > *** Problem *** > > This problem concerns the following IPv6 mobility protocols: > - MIPv6 [3] > - HMIPv6 [4] > - FMIPv6 [5] > - NEMO [6] > > For each of these protocols, the "mobility manager" (HA for MIPv6 and NEMO, > MAP for HMIPv6, PAR for FMIPv6) may have to intercept the packets for the > Mobile to tunnel them to its real location. > > To do such a thing, the "mobile manager" uses NDP. > As example, from RFC 3775: > "In order to do this, when a node begins serving as the home agent it MUST > multicast onto the home link a Neighbor Advertisement message [12] on behalf > of the mobile node. For the home address specified in the Binding Update, > the home agent sends a Neighbor Advertisement message [12] to the all-nodes > multicast address on the home link, to advertise the home agent's own > link-layer address for this IP address on behalf of the mobile node. If the > Link-Layer Address Compatibility (L) flag has been specified in the Binding > Update, the home agent MUST do the same for the link-local address of the > mobile node." > > The others IPv6 mobility protocols use exactly the same mechanism. > > (This mechanism is not clear in FMIPv6 but it is pretty sure this is the > same mechanism) > > So, if SEND(CGA) is used, the "mobility manager" MUST have the private key > (associated to the public key used to generated the CGA address) used by the > Mobile to sign its ND packets. > > *** References *** > > [1] draft-ietf-send-ndopt-05.txt, "SEcure Neighbor Discovery (SEND)", J. > Arkko (Editor)/J. Kempf/B. Sommerfeld/B. Zill/P. Nikander, April 2004 > [2] draft-ietf-send-cga-06, "Cryptographically Generated Addresses (CGA)", > T. Aura, April 2004 > [3] RFC 3775, "Mobility Support in IPv6", D. Johnson/C. Perkins/J. Arkko, > June 2004 > [4] draft-ietf-mipshop-hmipv6-02.txt, "Hierarchical Mobile IPv6 mobility > management (HMIPv6)", H. Soliman/C. Catelluccia/K. El Malki/L.Bellier, June > 2004 > [5] draft-ietf-mipshop-fast-mipv6-01.txt, "Fast Handovers for Mobile IPv6", > R. Koodli (Editor), January 2004 > [6] draft-ietf-nemo-basic-support-03.txt, "Network Mobility (NEMO) Basic > Support Protocol", V. Devarapalli/R. Wakikawa/A. Petrescu/P. Thubert, June > 2004 > > > Regards. > > JMC. > > France Telecom - R&D Division - MAPS/NSS > Jean-Michel COMBES, Internet/Intranet Security > E-Mail: jeanmichel.combes@francetelecom.com > Phone: +33 (0)1 45 29 45 94 > Fax: +33 (0)1 45 29 65 19 > Mobile: +33 (0)6 07 29 30 16 > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jul 6 14:33:53 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10416 for ; Tue, 6 Jul 2004 14:33:52 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i66IXqPA016982 for ; Tue, 6 Jul 2004 20:33:52 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Jul 2004 20:33:51 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321K0F59; Tue, 6 Jul 2004 20:33:51 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i66IXfwg003778; Tue, 6 Jul 2004 20:33:42 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i66IX9It005864; Tue, 6 Jul 2004 20:33:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i66IX9wp005863; Tue, 6 Jul 2004 20:33:09 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i66IX7It005858 for ; Tue, 6 Jul 2004 20:33:08 +0200 (MET DST) Message-ID: <042f01c46387$ca1f24f0$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jean-Michel COMBES" , Cc: References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Tue, 6 Jul 2004 11:33:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 06 Jul 2004 18:33:51.0521 (UTC) FILETIME=[C8E21110:01C46387] Content-Transfer-Encoding: 7bit Jean-Michel, > 1) I agree that the issue that you mention is a > limitation. I'm not sure the security considerations > section is the right place to explain the limitation, > however; it seems that the limitation is functional > rather than security related. IMO, this is a security issue because SEND works if the "proxy" has the Mobile's key and so the issue is in fact linked to the CGA key distribution (Mobile -> "proxy" or "proxy" -> Mobile) jak>> If the paragraph in Section 1 I posted won't do, please propose some text and placement in the security considerations section that will address your concerns. > > In any case, Section 7.14 (Limitations) already > states: "Proxy Neighbor Discovery is not supported > by this specification." Do you think more text > is needed? Yes, IMO, I think we need more text ... I am afraid to see in some drafts "Just use SEND" as we saw for RFC 2401 with "Just use IPsec". jak>> I'm afraid to say "not our problem". If people are not willing to take the time to read the drafts and understand what the technology does and doesn't do, then there is not much we can do about it. SEND is not a panacea. Of course, when someone does use the "pixy dust" approach and we notice it, we should try to call them out on it. > > 2) I believe there's a solution that can support > proxy ND with SEND; for now the WG has determined > that it will not include the solution in the current > RFC. However, there's a plan to develop an extension > later. I guess the interest level for SEND and its > combined use with things like MIPv6 determines how > soon is "later". Chairs? > > 3) In the meanwhile, MIPv6 home addresses and SEND would > work with so called virtual home networks where the > mobile nodes never go to. Agree. This is the right solution for MIPv6, HMIPv6 and NEMO ... > Care-of addresses will of > course work with SEND in any case. ... but with FMIPv6 we have still a problem: the "proxy" function is concerning the Co@ (for the tunneling between the PAR and the NAR). jak>> Depending on whether the wireless link technology supports predictive or reactive handover, there may be an issue with proxying. For a predictive technology, the NAR may be required to proxy since the PAR informs it of the new CoA prior to the actual link handover. However, this is entirely theoretical at the moment, because there is no widely available wireless link technology that supports predictive handover and, simultaneously, would be in a position to use FMIPv6. The cellular technologies all do local link handover optimization their own way ("stretchy PPP" for 3GPP2, GPRS for PP). 802.16 may support predictive handover, but the WG doing mobility is about 2 years from completing the basic link design (I think it's .16e) if I understand correctly. With a reactive wireless link technology, there's no need for proxying because the mobile doesn't actually claim the CoA until it is on the link. 802.11 is a reactive technology, as is 802.15.2 (Bluetooth), and so they don't need proxying. Given the focus in SEND on meeting immediate technology needs quickly rather than doing the full solution too late, the WG decided to forgo working on secure proxying for now, though the design team did discuss some approaches. If SEND turns out to be popular, we can have a BOF and restart the WG to work on the remaining issues. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jul 6 17:09:27 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23168 for ; Tue, 6 Jul 2004 17:09:27 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i66L9RPA001470 for ; Tue, 6 Jul 2004 23:09:28 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Jul 2004 23:09:27 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321K06JR; Tue, 6 Jul 2004 23:09:27 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i66L9Kwg011028; Tue, 6 Jul 2004 23:09:20 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i66L8bIt017440; Tue, 6 Jul 2004 23:08:37 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i66L8bE1017439; Tue, 6 Jul 2004 23:08:37 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i66L8ZIt017416 for ; Tue, 6 Jul 2004 23:08:35 +0200 (MET DST) Message-ID: <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" , Cc: "Jean-Michel COMBES" , , References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Tue, 6 Jul 2004 14:09:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 06 Jul 2004 21:09:27.0194 (UTC) FILETIME=[8560B7A0:01C4639D] Content-Transfer-Encoding: 7bit Greg, If the minimum path MTU on the tunnel is too small, the DCA could potentially get fragmented, and the cert exchange could suffer from the same problem that IPsec cert exchange does, namely some router on the path drops the packet. I'd think that this would not be as severe a problem in IPv6 as IPv4, because theoretically the end hosts are responsible for handling path MTU discovery and fragmentation rather than the routers, but I'm not sure whether the implemented and deployed equipment actually lives up to this. Might be worth testing. In addition, by RFC 3775, the HA and MN need to have an IPsec SA in place to secure the MIPv6 signaling traffic. Now, this SA doesn't actually require the HA to identify what prefixes it is authorized to route, like the SEND SA does, but it does require the HA to be authenticatable. So I'd think adding the address extension to the certificates used to identify the HA would be a better option, provided, of course the SA is constructed using certificates, as it would avoid having the HA send the same set of certs twice. It might be useful to have some kind of flag or something in the HA Discovery message to request that the HA identify what prefixes it is authorized to route, not sure. There's feeling among some that the address extension for authorized prefixes is too fine-grained a mechanism, and that just having the router identify itself in an authenticatable way is sufficient. Time and deployment popularity will tell. jak ----- Original Message ----- From: "Vijay Devarapalli" To: Cc: "Jean-Michel COMBES" ; ; Sent: Thursday, July 01, 2004 3:21 PM Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility > Greg Daley wrote: > > In the MIPv6 case, it may be possible to exchange delegation > > chain messages over the home tunnel to ensure that the MN knows > > that the HA is authorized to be a router for the prefix. > > Also, the MN could sign the key of the router and send back > > a proxy certificate by a similar message. > > > > There may have to be a control plane request in the message > > sent back to the router which could request use of the address, > > and proxying. With MIPv6 this is already done if the > > proxy certificate is sent within a BU/BAck. > > sounds like an idea that would work. maybe you should > write up a draft on this. > > Vijay > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jul 6 20:02:39 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05691 for ; Tue, 6 Jul 2004 20:02:39 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6702bPA014676 for ; Wed, 7 Jul 2004 02:02:38 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Jul 2004 02:02:37 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321LA3CZ; Wed, 7 Jul 2004 02:02:37 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6702Wwg017171; Wed, 7 Jul 2004 02:02:32 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6701WIt006319; Wed, 7 Jul 2004 02:01:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6701WaX006318; Wed, 7 Jul 2004 02:01:32 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6701TIt006302 for ; Wed, 7 Jul 2004 02:01:30 +0200 (MET DST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LC6C9TIE7Y8Y4X5M@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Wed, 7 Jul 2004 09:59:54 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DE6B8AB54E; Wed, 07 Jul 2004 09:56:14 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id B20134FB12; Wed, 07 Jul 2004 09:56:14 +1000 (EST) Date: Wed, 07 Jul 2004 09:56:14 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: James Kempf Cc: Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40EB3C1E.6090808@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 07 Jul 2004 00:02:37.0708 (UTC) FILETIME=[B69B54C0:01C463B5] Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > Greg, > > If the minimum path MTU on the tunnel is too small, the DCA could > potentially get fragmented, and the cert exchange could suffer from the same > problem that IPsec cert exchange does, namely some router on the path drops > the packet. I'd think that this would not be as severe a problem in IPv6 as > IPv4, because theoretically the end hosts are responsible for handling path > MTU discovery and fragmentation rather than the routers, but I'm not sure > whether the implemented and deployed equipment actually lives up to this. > Might be worth testing. Certainly. > In addition, by RFC 3775, the HA and MN need to have an IPsec SA in place to > secure the MIPv6 signaling traffic. Now, this SA doesn't actually require > the HA to identify what prefixes it is authorized to route, like the SEND SA > does, but it does require the HA to be authenticatable. So I'd think adding > the address extension to the certificates used to identify the HA would be a > better option, provided, of course the SA is constructed using certificates, > as it would avoid having the HA send the same set of certs twice. This sounds like a good idea too. > It might be useful to have some kind of flag or something in the HA > Discovery message to request that the HA identify what prefixes it is > authorized to route, not sure. There's feeling among some that the address > extension for authorized prefixes is too fine-grained a mechanism, and that > just having the router identify itself in an authenticatable way is > sufficient. Time and deployment popularity will tell. Indeed. I can understand that a simple certificate saying I'm a router for ISP XYZ is considered sufficient in this case. What's important is a mechanism which allows the HA pass a the correct public key for the MN to sign (whether in IPSec key exchanges or not). The they used for SEND may not be the same public key IPSec key negotiation, though. The responding indication from the MN needs to provide both an authorization and a timestamp though (which sounds like a certificate, too). So we need to determine if this response can be sent in (just) DCA, or needs to be put into the end of a BU message, which would cause MTU issues too. Perhaps an option indicating the HA's public key (actually a hash over the key as used in SEND) and the authorization timestamp could be included in both messages (BU and DCA). A more radical alternative would rely only upon the routing authorization of a router for a particular prefix, and allowing routers to create neighbour cache state for any address they are authorized to route (except for other routers' addresses). This wouldn't require the MN to sign a key at all, and would be based on the timing of the NCE of the proxying router (the original timer from the address owner being kept in limbo, to use in verifying an MN's return). This entrenches authorized prefixes though. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 7 11:44:14 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26759 for ; Wed, 7 Jul 2004 11:44:14 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i67FiFAh024584 for ; Wed, 7 Jul 2004 17:44:16 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Jul 2004 17:44:15 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3236F6LM; Wed, 7 Jul 2004 17:44:15 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i67FiEXA017281; Wed, 7 Jul 2004 17:44:14 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i67FhKIt023922; Wed, 7 Jul 2004 17:43:20 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i67FhK49023920; Wed, 7 Jul 2004 17:43:20 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i67FhIIt023889 for ; Wed, 7 Jul 2004 17:43:18 +0200 (MET DST) Message-ID: <007f01c46439$3acf8ad0$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> <40EB3C1E.6090808@eng.monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Wed, 7 Jul 2004 08:44:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 07 Jul 2004 15:44:15.0868 (UTC) FILETIME=[422263C0:01C46439] Content-Transfer-Encoding: 7bit Greg, Greg, > I can understand that a simple certificate saying > I'm a router for ISP XYZ is considered sufficient > in this case. > > What's important is a mechanism which allows the HA > pass a the correct public key for the MN to sign (whether > in IPSec key exchanges or not). > The they used for SEND may not be the same public key > IPSec key negotiation, though. > > The responding indication from the MN needs to provide > both an authorization and a timestamp though (which > sounds like a certificate, too). So we need to > determine if this response can be sent in (just) DCA, > or needs to be put into the end of a BU message, which > would cause MTU issues too. > Perhaps an option indicating the HA's public key (actually > a hash over the key as used in SEND) and the authorization > timestamp could be included in both messages (BU and DCA). > I guess I'm not following you here. Why do you want the HA to send a public key to the MN to sign? In SEND, the host isn't acting as a certificate authority. The router is providing the host with a certificate chain including the router's certificate with the router's public key, allowing the host to verify the authenticity of the router's public key and providing that key to host so the host can verify Router Advertisements. Is there some different requirement for Mobile IP that we've missed? > > > A more radical alternative would rely only > upon the routing authorization of a router for a > particular prefix, and allowing routers to create > neighbour cache state for any address they are > authorized to route (except for other routers' > addresses). > > This wouldn't require the MN to sign a key at all, > and would be based on the timing of the NCE of the > proxying router (the original timer from the > address owner being kept in limbo, to use in > verifying an MN's return). > > This entrenches authorized prefixes though. > What threat is this intended to mitigate? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 7 21:28:27 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03005 for ; Wed, 7 Jul 2004 21:28:26 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i681SRAh031129 for ; Thu, 8 Jul 2004 03:28:28 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Jul 2004 03:28:27 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321L25PB; Thu, 8 Jul 2004 03:28:27 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i681S6wg022882; Thu, 8 Jul 2004 03:28:06 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i681QkIt003050; Thu, 8 Jul 2004 03:26:46 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i681QkX0003049; Thu, 8 Jul 2004 03:26:46 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i681QgIt003029 for ; Thu, 8 Jul 2004 03:26:43 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LC7TODRGJW8WXJH9@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 08 Jul 2004 11:25:58 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 70B5E80033; Thu, 08 Jul 2004 11:25:56 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 541793C008; Thu, 08 Jul 2004 11:25:56 +1000 (EST) Date: Thu, 08 Jul 2004 11:25:56 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: James Kempf Cc: Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40ECA2A4.8040708@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> <40EB3C1E.6090808@eng.monash.edu.au> <007f01c46439$3acf8ad0$536115ac@dcml.docomolabsusa.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 08 Jul 2004 01:28:27.0668 (UTC) FILETIME=[DEA29D40:01C4648A] Content-Transfer-Encoding: 7BIT Hi James, Perhaps I'm getting a little ahead of myself. I'll try to describe myself below. I hope my interchangable use of the words MN as the proxied node and HA/Router as the proxier don't cause confusion. What's needed is a mechanism to allow the HA to undertake proxy neighbour discovery for the MN on the home link (or a node or router to be a proxy for host). MIPv6 has a mechanism for PND, but it is unsecured, as is all PND. What's needed for other hosts on the home subnet to trust a (secured) PND is either a blanket authorization for an authorized router to proxy on a particular subnet, or a delegated authority from a host that another may act on its behalf in ND. Below I describe each of the possible schemes and outline some advantages and disadvantages. In the first case, the router and MN don't need to exchange any information about keys. The router/HA just starts advertising for a particular MN address, and people believe them because they're the router (with router certificates). The second case allows devices which are known to the MN to start undertaking advertisement on the MN's behalf, but require some proof to show to neighbours on the link that the proxy behaviour is authorized by the end host. The proof could easily be some sort of simple certificate generated by the MN (fairly minimal) which the proxy can show to others in a DCA message, if they question the proxy's authority. The signature in the certificate would be tied to the CGA which is being proxied. It would sign the public key of the host who is allowed to proxy. That public key being that key used for signing its SEND messages. Obviously this key generation and communication of authorization exceeds any requirement for a SEND host yet mandated. Of the two schemes, one requires no exchange of keying information, but cannot be directly tied to the MN's wishes. The other requires the proxy to send its public key to the proxied in order for it to generate a certificate, for the proxy to advertise to others when doing (secured) PND. Of course, if the MN already knows the public key of the MN because it has been there (or has received it in IKE), then the MN doesn't need to re-learn it when proxying starts. The MN will still need some explicit way of providing its authorization (the certificate) to the router when the proxying starts. If explicit authorization for particular subnets isn't available in the advertised SEND router certificate delegation, then the first method may not be a good idea (not sure yet, but uneasy about any router with any delegation chain being able to proxy without a proxied host knowing). The proxied host's certificate generation may be useful in a home networking environment since a host could try to delegate authority to an ND proxy, which may not be trusted as a router on the closer-to-internet network (and so may be more generally applicable). Greg James Kempf wrote: > Greg, > > Greg, > > >>I can understand that a simple certificate saying >>I'm a router for ISP XYZ is considered sufficient >>in this case. >> >>What's important is a mechanism which allows the HA >>pass a the correct public key for the MN to sign (whether >>in IPSec key exchanges or not). >>The they used for SEND may not be the same public key >>IPSec key negotiation, though. >> >>The responding indication from the MN needs to provide >>both an authorization and a timestamp though (which >>sounds like a certificate, too). So we need to >>determine if this response can be sent in (just) DCA, >>or needs to be put into the end of a BU message, which >>would cause MTU issues too. >>Perhaps an option indicating the HA's public key (actually >>a hash over the key as used in SEND) and the authorization >>timestamp could be included in both messages (BU and DCA). >> > > > I guess I'm not following you here. Why do you want the HA to send a public > key to the MN to sign? In SEND, the host isn't acting as a certificate > authority. The router is providing the host with a certificate chain > including the router's certificate with the router's public key, allowing > the host to verify the authenticity of the router's public key and providing > that key to host so the host can verify Router Advertisements. Is there some > different requirement for Mobile IP that we've missed? Please tell me if the description I've made above doesn't clear this up. > >> >>A more radical alternative would rely only >>upon the routing authorization of a router for a >>particular prefix, and allowing routers to create >>neighbour cache state for any address they are >>authorized to route (except for other routers' >>addresses). >> >>This wouldn't require the MN to sign a key at all, >>and would be based on the timing of the NCE of the >>proxying router (the original timer from the >>address owner being kept in limbo, to use in >>verifying an MN's return). >> >>This entrenches authorized prefixes though. >> > > > What threat is this intended to mitigate? This is only related to the mechanism which trusts routers to do proxying without certificate generation by the proxied SEND host. Knowing which prefixes a router may be authorized for helps to avoid unpleasant situations where a router starts usurping another's role. This may particularly be useful if there are more than one 'authorized router' on a link, potentially authorized for (advertising?) different prefixes. It may be possible for the router which didn't advertise a particular prefix to start sending Proxy NA's for a host. If the authorization isn't explicit about which prefixes a router may proxy or route for, it may not be a good idea to allow routers to proxy for addresses without explicit authority provided by the proxied address owner. Does this clarify some of my concern in this case? Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 8 12:24:35 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07112 for ; Thu, 8 Jul 2004 12:24:34 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i68GOZAh020332 for ; Thu, 8 Jul 2004 18:24:35 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Jul 2004 18:24:35 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321LPA0P; Thu, 8 Jul 2004 18:24:35 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i68GOYXA000030; Thu, 8 Jul 2004 18:24:34 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i68GNTIt007657; Thu, 8 Jul 2004 18:23:29 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i68GNT8e007656; Thu, 8 Jul 2004 18:23:29 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i68GNRIt007630 for ; Thu, 8 Jul 2004 18:23:27 +0200 (MET DST) Message-ID: <00f201c46507$fea2b8f0$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> <40EB3C1E.6090808@eng.monash.edu.au> <007f01c46439$3acf8ad0$536115ac@dcml.docomolabsusa.com> <40ECA2A4.8040708@eng.monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Thu, 8 Jul 2004 09:24:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 08 Jul 2004 16:24:35.0611 (UTC) FILETIME=[0ED39EB0:01C46508] Content-Transfer-Encoding: 7bit Greg, Thanx for the explanation, I think I understand better. > > I'll try to describe myself below. I hope my > interchangable use of the words MN as the proxied > node and HA/Router as the proxier don't cause confusion. > > > What's needed is a mechanism to allow the > HA to undertake proxy neighbour discovery for > the MN on the home link (or a node or router > to be a proxy for host). MIPv6 has a mechanism > for PND, but it is unsecured, as is all PND. > PND needs security, but I think we ought to understand why (i.e. the problem statement). In the mobile context, I can think of only two cases where PND would need security: 1) NAR proxying during FMIP predictive handover. However as I mentioned in my previous post, there are currently no wireless link types able to do predictive handover that would use FMIP. 2) DAD defense of an autoconfigured home address by the HA, so the MN doesn't have to. However, as discussed in draft-kempf-mip6-bootstrap-problem-statement-00.txt and in the soon to be released boostrapping design team WG draft, it is today not possible to use a dynamically allocated IPv6 home address with MIP6 because the HA can't verify if the MN is authorized to use the address. The bootstrapping design solution will address this issue. Are there any others? Since neither of these is a problem at the moment, there doesn't seem to be a particularly compelling need to come up with a secure PND solution right now, IMHO. > What's needed for other hosts on the home subnet > to trust a (secured) PND is either a > blanket authorization for an authorized router to > proxy on a particular subnet, or a delegated > authority from a host that another may act on its behalf > in ND. > > Below I describe each of the possible schemes and > outline some advantages and disadvantages. > > In the first case, the router and MN don't need to > exchange any information about keys. > The router/HA just starts advertising for a particular > MN address, and people believe them because they're > the router (with router certificates). > If the router has a cert and the MN has validated it, then this would only require the NA response to be signed by the router. However, this kind of "trust the network" approach is not likely to appeal to "only the host can be trusted" purists. > The second case allows devices which are known to the MN > to start undertaking advertisement on the MN's behalf, > but require some proof to show to neighbours on the link > that the proxy behaviour is authorized by the end host. > > The proof could easily be some sort of simple certificate > generated by the MN (fairly minimal) which the proxy > can show to others in a DCA message, if they question > the proxy's authority. > > The signature in the certificate would be tied to > the CGA which is being proxied. It would sign the > public key of the host who is allowed to proxy. > That public key being that key used for signing its > SEND messages. > > Obviously this key generation and communication of > authorization exceeds any requirement for a SEND host > yet mandated. > The SEND design team talked about having the MN issue an authorization certificate to the router. There would need to be some protocol involved for this, of course. > > > Of the two schemes, one requires no exchange of > keying information, but cannot be directly tied to the > MN's wishes. > > The other requires the proxy to send its public key to > the proxied in order for it to generate a certificate, > for the proxy to advertise to others when doing (secured) > PND. > > Of course, if the MN already knows the public key of the MN > because it has been there (or has received it in IKE), > then the MN doesn't need to re-learn it when proxying starts. > The MN will still need some explicit way of providing > its authorization (the certificate) to the router when the > proxying starts. > I think you mean "if the HA already knows the public key..." but, yes, I understand what you're saying. > > > If explicit authorization for particular subnets isn't > available in the advertised SEND router certificate > delegation, then the first method may not be a good idea > (not sure yet, but uneasy about any router with any > delegation chain being able to proxy without a proxied > host knowing). > > The proxied host's certificate generation may be useful > in a home networking environment since a host could > try to delegate authority to an ND proxy, which may not > be trusted as a router on the closer-to-internet network > (and so may be more generally applicable). > These are all considerations. At some point, solving the security problem for PND will become more compelling, IMHO. Right now, there's more urgent problems, like fixing bootstrapping for MIPv6. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 8 17:53:03 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04453 for ; Thu, 8 Jul 2004 17:53:02 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i68Lr4Ah009764 for ; Thu, 8 Jul 2004 23:53:04 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Jul 2004 23:53:04 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA44WJBJ; Thu, 8 Jul 2004 23:53:03 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i68Lqswg027030; Thu, 8 Jul 2004 23:52:54 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i68LpsIt006490; Thu, 8 Jul 2004 23:51:54 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i68LpsrC006489; Thu, 8 Jul 2004 23:51:54 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i68LpnIt006485 for ; Thu, 8 Jul 2004 23:51:50 +0200 (MET DST) Message-ID: <01c201c46535$e07f55d0$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "James Kempf" , Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> <40EB3C1E.6090808@eng.monash.edu.au> <007f01c46439$3acf8ad0$536115ac@dcml.docomolabsusa.com> <40ECA2A4.8040708@eng.monash.edu.au> <00f201c46507$fea2b8f0$536115ac@dcml.docomolabsusa.com> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Thu, 8 Jul 2004 14:52:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 08 Jul 2004 21:53:04.0071 (UTC) FILETIME=[F1FBF570:01C46535] Content-Transfer-Encoding: 7bit > 1) NAR proxying during FMIP predictive handover. However as I mentioned in > my previous post, there are currently no wireless link types able to do > predictive handover that would use FMIP. > Vijay points out that PND is needed for reactive handover too. The PAR must defend the MN's old CoA until the tunnel to the new CoA is torn down; otherwise the old CoA may be claimed by a new host arriving on the old link. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 8 23:55:20 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15109 for ; Thu, 8 Jul 2004 23:55:19 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i693tKWR027830 for ; Fri, 9 Jul 2004 05:55:21 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jul 2004 05:55:20 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q9XJ7N; Fri, 9 Jul 2004 05:55:20 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i693tJXA011301; Fri, 9 Jul 2004 05:55:19 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i693sMIt015872; Fri, 9 Jul 2004 05:54:22 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i693sMPt015871; Fri, 9 Jul 2004 05:54:22 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i693sKIt015853 for ; Fri, 9 Jul 2004 05:54:21 +0200 (MET DST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LC9D469H868WXNH2@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Fri, 09 Jul 2004 13:53:08 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 15466AB542; Fri, 09 Jul 2004 13:53:06 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id EEC2E4FB09; Fri, 09 Jul 2004 13:53:05 +1000 (EST) Date: Fri, 09 Jul 2004 13:53:05 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: James Kempf Cc: Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40EE16A1.7090905@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> <40EB3C1E.6090808@eng.monash.edu.au> <007f01c46439$3acf8ad0$536115ac@dcml.docomolabsusa.com> <40ECA2A4.8040708@eng.monash.edu.au> <00f201c46507$fea2b8f0$536115ac@dcml.docomolabsusa.com> <01c201c46535$e07f55d0$536115ac@dcml.docomolabsusa.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 09 Jul 2004 03:55:20.0274 (UTC) FILETIME=[8DC55320:01C46568] Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: >>1) NAR proxying during FMIP predictive handover. However as I mentioned in >>my previous post, there are currently no wireless link types able to do >>predictive handover that would use FMIP. >> > > > Vijay points out that PND is needed for reactive handover too. The PAR must > defend the MN's old CoA until the tunnel to the new CoA is torn down; > otherwise the old CoA may be claimed by a new host arriving on the old link. Your response is faster than mine... It may be that we need a Problem Statement to show what needs to be done. It would be good to have something to talk about even if we're not having a session at IETF60, so perhaps we can get some of this into a draft. Vijay also mentioned this before... Hi Vijay. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jul 9 14:20:01 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17118 for ; Fri, 9 Jul 2004 14:20:00 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i69IK0PA010772 for ; Fri, 9 Jul 2004 20:20:01 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jul 2004 20:20:00 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA447V8Z; Fri, 9 Jul 2004 20:19:59 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i69IJuXA002124; Fri, 9 Jul 2004 20:19:56 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i69IJ5It016849; Fri, 9 Jul 2004 20:19:05 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i69IJ5el016848; Fri, 9 Jul 2004 20:19:05 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i69IJ2It016829 for ; Fri, 9 Jul 2004 20:19:03 +0200 (MET DST) Message-ID: <00cc01c465e1$510e11a0$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , , References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> <40EB3C1E.6090808@eng.monash.edu.au> <007f01c46439$3acf8ad0$536115ac@dcml.docomolabsusa.com> <40ECA2A4.8040708@eng.monash.edu.au> <00f201c46507$fea2b8f0$536115ac@dcml.docomolabsusa.com> <01c201c46535$e07f55d0$536115ac@dcml.docomolabsusa.com> <40EE16A1.7090905@eng.monash.edu.au> Subject: Proxy Neighbor Discovery Security in MOBOPTS? (was: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility) Date: Fri, 9 Jul 2004 11:19:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 09 Jul 2004 18:20:00.0054 (UTC) FILETIME=[58878560:01C465E1] Content-Transfer-Encoding: 7bit Hi Greg, The SEND WG actually will be shutting down shortly, so I'm not sure where to send a PND problem statement. We could hold a BOF in Washington (cause it is too late for San Diego) I suppose, but if we were to do that, I'd like to see a bit more committment from people about actually doing the work and from vendors about actually implementing it. So far, that's not there. Given the lack of real product interest, we could also do it in the context of MOBOPTS (cc'ed) since it does seem to be a security issue for FMIP. Shall we organize a BAR BOF at IETF 60? jak ----- Original Message ----- From: "Greg Daley" To: "James Kempf" Cc: "Vijay Devarapalli" ; "Jean-Michel COMBES" ; ; Sent: Thursday, July 08, 2004 8:53 PM Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility > Hi James, > > James Kempf wrote: > >>1) NAR proxying during FMIP predictive handover. However as I mentioned in > >>my previous post, there are currently no wireless link types able to do > >>predictive handover that would use FMIP. > >> > > > > > > Vijay points out that PND is needed for reactive handover too. The PAR must > > defend the MN's old CoA until the tunnel to the new CoA is torn down; > > otherwise the old CoA may be claimed by a new host arriving on the old link. > > Your response is faster than mine... > > It may be that we need a Problem Statement to > show what needs to be done. > > It would be good to have something to talk about > even if we're not having a session at IETF60, > so perhaps we can get some of this into a draft. > > Vijay also mentioned this before... > > Hi Vijay. > > Greg > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jul 10 04:32:24 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29439 for ; Sat, 10 Jul 2004 04:32:23 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6A8WNPA000667 for ; Sat, 10 Jul 2004 10:32:23 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 Jul 2004 10:32:23 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321LYSN8; Sat, 10 Jul 2004 10:32:22 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6A8WLXA008974; Sat, 10 Jul 2004 10:32:21 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6A8TwIt007472; Sat, 10 Jul 2004 10:29:58 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6A8TwsV007471; Sat, 10 Jul 2004 10:29:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6A8TvIt007467 for ; Sat, 10 Jul 2004 10:29:57 +0200 (MET DST) Received: from mta.imail.kolumbus.fi ([193.229.5.110]) by fep01-app.kolumbus.fi with ESMTP id <20040710082957.KGPI13175.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> for ; Sat, 10 Jul 2004 11:29:57 +0300 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: Subject: resolutions to the IESG comments Date: Sat, 10 Jul 2004 11:29:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040710082957.KGPI13175.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 10 Jul 2004 08:32:23.0015 (UTC) FILETIME=[6C1C0F70:01C46658] Content-Transfer-Encoding: 7bit Folks, I have tentatively addressed the issues raised in the IESG review. It would be useful if people in the WG would take a look and review the modifications. The issues and diffs can be found here: http://www.arkko.com/publications/send/issues/ --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jul 10 16:26:42 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00334 for ; Sat, 10 Jul 2004 16:26:41 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6AKQfPA007664 for ; Sat, 10 Jul 2004 22:26:42 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 Jul 2004 22:26:41 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q0ARY7; Sat, 10 Jul 2004 22:26:41 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6AKQWwg026176; Sat, 10 Jul 2004 22:26:32 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6AKPRIt017378; Sat, 10 Jul 2004 22:25:27 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6AKPQP6017377; Sat, 10 Jul 2004 22:25:26 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6AKPOIt017360 for ; Sat, 10 Jul 2004 22:25:25 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LCBI18X85A8WXNB7@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Sun, 11 Jul 2004 02:35:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4960780034; Sun, 11 Jul 2004 02:35:06 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2FC6A3C00A; Sun, 11 Jul 2004 02:35:06 +1000 (EST) Received: from [211.28.113.154] by mail-store-2.its.monash.edu.au (mshttpd) ; Sun, 11 Jul 2004 02:35:06 +1000 Date: Sun, 11 Jul 2004 02:35:06 +1000 From: Greg Daley Subject: Re: Proxy Neighbor Discovery Security in MOBOPTS? (was: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility) To: James Kempf Cc: greg.daley@eng.monash.edu.au, Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net, mobopts@irtf.org Message-id: <3c8b1a3cc880.3cc8803c8b1a@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.26 (built Mar 31 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 10 Jul 2004 20:26:41.0408 (UTC) FILETIME=[35B3D800:01C466BC] Content-Transfer-Encoding: 7BIT Hi James, (et al, sorry for cross post). ----- Original Message ----- From: James Kempf Date: Saturday, July 10, 2004 4:19 am Subject: Proxy Neighbor Discovery Security in MOBOPTS? (was: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility) > Hi Greg, > > The SEND WG actually will be shutting down shortly, so I'm not sure > where to > send a PND problem statement. We could hold a BOF in Washington > (cause it is > too late for San Diego) I suppose, but if we were to do that, I'd > like to > see a bit more committment from people about actually doing the > work and > from vendors about actually implementing it. So far, that's not there. That sounds fair. We'll see if it's considered required for implementations soon though. I'd like to see that we don't get a lot of SEND implementations out in the wild which can't get upgraded to Proxy-SEND. > Given the lack of real product interest, we could also do it in the > contextof MOBOPTS (cc'ed) since it does seem to be a security issue > for FMIP. Shall > we organize a BAR BOF at IETF 60? Just as context for MOBOPTs, proxy neighbour discovery is required for MIPv6 support on the Home Network too. The Bar BoF sounds like a good idea if we can get a quick problem statement going about it. We'll see if people are interested enough. I'd vote we go to a real bar this time though. Greg There may be interest if we talk to Dave Thaler too about his NDproxy. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jul 10 18:33:37 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04849 for ; Sat, 10 Jul 2004 18:33:36 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6AMXbWR013090 for ; Sun, 11 Jul 2004 00:33:37 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Jul 2004 00:33:36 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32365NXL; Sun, 11 Jul 2004 00:33:36 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6AMXZXA015178; Sun, 11 Jul 2004 00:33:35 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6AMWbIt021653; Sun, 11 Jul 2004 00:32:37 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6AMWbTc021652; Sun, 11 Jul 2004 00:32:37 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i6AMWYIt021644 for ; Sun, 11 Jul 2004 00:32:35 +0200 (MET DST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.72 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 10 Jul 2004 22:32:33 -0000 Message-ID: <009001c466cd$cb38e990$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "James Kempf" , "Jean-Michel COMBES" , Cc: References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <042f01c46387$ca1f24f0$536115ac@dcml.docomolabsusa.com> Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Sat, 10 Jul 2004 15:32:22 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 10 Jul 2004 22:33:36.0724 (UTC) FILETIME=[F0C8D940:01C466CD] Content-Transfer-Encoding: 7bit James, > > jak>> Depending on whether the wireless link technology supports predictive > or reactive handover, there may be an issue with proxying. For a predictive > technology, the NAR may be required to proxy since the PAR informs it of the > new CoA prior to the actual link handover. However, this is entirely > theoretical at the moment, because there is no widely available wireless > link technology that supports predictive handover and, simultaneously, would > be in a position to use FMIPv6. The cellular technologies all do local link > handover optimization their own way ("stretchy PPP" for 3GPP2, GPRS for PP). > 802.16 may support predictive handover, but the WG doing mobility is about 2 > years from completing the basic link design (I think it's .16e) if I > understand correctly. With a reactive wireless link technology, there's no > need for proxying because the mobile doesn't actually claim the CoA until it > is on the link. 802.11 is a reactive technology, as is 802.15.2 (Bluetooth), I don't understand this part. Why do you think in 802.11, that the NAR cannot defend the new CoA when the MN is on the old link ? When the node is on the old link, why can't it do the standard FMIPv6 like on any other link ? thanks mohan > and so they don't need proxying. Given the focus in SEND on meeting > immediate technology needs quickly rather than doing the full solution too > late, the WG decided to forgo working on secure proxying for now, though the > design team did discuss some approaches. If SEND turns out to be popular, we > can have a BOF and restart the WG to work on the remaining issues. > > jak > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jul 10 18:39:44 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05035 for ; Sat, 10 Jul 2004 18:39:43 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6AMdiWR013580 for ; Sun, 11 Jul 2004 00:39:44 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Jul 2004 00:39:44 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q0A55S; Sun, 11 Jul 2004 00:39:44 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6AMdhXA015209; Sun, 11 Jul 2004 00:39:43 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6AMdSIt022944; Sun, 11 Jul 2004 00:39:28 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6AMdRV3022943; Sun, 11 Jul 2004 00:39:27 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp809.mail.sc5.yahoo.com (smtp809.mail.sc5.yahoo.com [66.163.168.188]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i6AMdPIt022939 for ; Sun, 11 Jul 2004 00:39:26 +0200 (MET DST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.72 with login) by smtp809.mail.sc5.yahoo.com with SMTP; 10 Jul 2004 22:39:24 -0000 Message-ID: <009601c466ce$bfe1a9f0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , "James Kempf" Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <40E23032.1070809@eng.monash.edu.au> <40E342FC.5060103@iprg.nokia.com> <40E38A23.9030500@eng.monash.edu.au> <40E48E86.2080401@iprg.nokia.com> <071801c4639d$81436730$536115ac@dcml.docomolabsusa.com> <40EB3C1E.6090808@eng.monash.edu.au> <007f01c46439$3acf8ad0$536115ac@dcml.docomolabsusa.com> <40ECA2A4.8040708@eng.monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Sat, 10 Jul 2004 15:39:23 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 10 Jul 2004 22:39:44.0478 (UTC) FILETIME=[CBFBA7E0:01C466CE] Content-Transfer-Encoding: 7bit Greg, > Hi James, > > Perhaps I'm getting a little ahead of myself. > > I'll try to describe myself below. I hope my > interchangable use of the words MN as the proxied > node and HA/Router as the proxier don't cause confusion. > > > What's needed is a mechanism to allow the > HA to undertake proxy neighbour discovery for > the MN on the home link (or a node or router > to be a proxy for host). MIPv6 has a mechanism > for PND, but it is unsecured, as is all PND. > > What's needed for other hosts on the home subnet > to trust a (secured) PND is either a > blanket authorization for an authorized router to > proxy on a particular subnet, or a delegated > authority from a host that another may act on its behalf > in ND. > > Below I describe each of the possible schemes and > outline some advantages and disadvantages. > > In the first case, the router and MN don't need to > exchange any information about keys. > The router/HA just starts advertising for a particular > MN address, and people believe them because they're > the router (with router certificates). > > The second case allows devices which are known to the MN > to start undertaking advertisement on the MN's behalf, > but require some proof to show to neighbours on the link > that the proxy behaviour is authorized by the end host. > > The proof could easily be some sort of simple certificate > generated by the MN (fairly minimal) which the proxy > can show to others in a DCA message, if they question > the proxy's authority. > > The signature in the certificate would be tied to > the CGA which is being proxied. It would sign the > public key of the host who is allowed to proxy. > That public key being that key used for signing its > SEND messages. > > Obviously this key generation and communication of > authorization exceeds any requirement for a SEND host > yet mandated. > > > > Of the two schemes, one requires no exchange of > keying information, but cannot be directly tied to the > MN's wishes. > > The other requires the proxy to send its public key to > the proxied in order for it to generate a certificate, > for the proxy to advertise to others when doing (secured) > PND. > > Of course, if the MN already knows the public key of the MN > because it has been there (or has received it in IKE), > then the MN doesn't need to re-learn it when proxying starts. > The MN will still need some explicit way of providing > its authorization (the certificate) to the router when the > proxying starts. > > > > If explicit authorization for particular subnets isn't > available in the advertised SEND router certificate > delegation, then the first method may not be a good idea > (not sure yet, but uneasy about any router with any > delegation chain being able to proxy without a proxied > host knowing). > > The proxied host's certificate generation may be useful > in a home networking environment since a host could > try to delegate authority to an ND proxy, which may not > be trusted as a router on the closer-to-internet network > (and so may be more generally applicable). > Which deployment scenario requires secured Proxy ND ? If MIPv6 is deployed by the operators, there would not be a real home link AFAIK. If MIPv6 is deployed in an enterprise, the trust is sufficient enough to not require proxy ND i guess. So, i am missing something on where proxy-ND would be required in practice. thanks mohan > Greg > > James Kempf wrote: > > Greg, > > > > Greg, > > > > > >>I can understand that a simple certificate saying > >>I'm a router for ISP XYZ is considered sufficient > >>in this case. > >> > >>What's important is a mechanism which allows the HA > >>pass a the correct public key for the MN to sign (whether > >>in IPSec key exchanges or not). > >>The they used for SEND may not be the same public key > >>IPSec key negotiation, though. > >> > >>The responding indication from the MN needs to provide > >>both an authorization and a timestamp though (which > >>sounds like a certificate, too). So we need to > >>determine if this response can be sent in (just) DCA, > >>or needs to be put into the end of a BU message, which > >>would cause MTU issues too. > >>Perhaps an option indicating the HA's public key (actually > >>a hash over the key as used in SEND) and the authorization > >>timestamp could be included in both messages (BU and DCA). > >> > > > > > > I guess I'm not following you here. Why do you want the HA to send a public > > key to the MN to sign? In SEND, the host isn't acting as a certificate > > authority. The router is providing the host with a certificate chain > > including the router's certificate with the router's public key, allowing > > the host to verify the authenticity of the router's public key and providing > > that key to host so the host can verify Router Advertisements. Is there some > > different requirement for Mobile IP that we've missed? > > Please tell me if the description I've made above > doesn't clear this up. > > > > >> > >>A more radical alternative would rely only > >>upon the routing authorization of a router for a > >>particular prefix, and allowing routers to create > >>neighbour cache state for any address they are > >>authorized to route (except for other routers' > >>addresses). > >> > >>This wouldn't require the MN to sign a key at all, > >>and would be based on the timing of the NCE of the > >>proxying router (the original timer from the > >>address owner being kept in limbo, to use in > >>verifying an MN's return). > >> > >>This entrenches authorized prefixes though. > >> > > > > > > What threat is this intended to mitigate? > > This is only related to the mechanism which > trusts routers to do proxying without certificate > generation by the proxied SEND host. > Knowing which prefixes a router may be authorized > for helps to avoid unpleasant situations where > a router starts usurping another's role. > > This may particularly be useful if there are more > than one 'authorized router' on a link, potentially > authorized for (advertising?) different prefixes. > > It may be possible for the router which didn't > advertise a particular prefix to start sending > Proxy NA's for a host. > If the authorization isn't explicit about > which prefixes a router may proxy or route for, > it may not be a good idea to allow routers to > proxy for addresses without explicit authority > provided by the proxied address owner. > > Does this clarify some of my concern in this case? > > Greg > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 08:01:34 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18094 for ; Sun, 11 Jul 2004 08:01:34 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6BC1XAh001224 for ; Sun, 11 Jul 2004 14:01:33 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Jul 2004 14:01:33 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q0C9L1; Sun, 11 Jul 2004 14:01:33 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6BC1WXA020082; Sun, 11 Jul 2004 14:01:32 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BC0KIt005395; Sun, 11 Jul 2004 14:00:20 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6BC0Ktl005380; Sun, 11 Jul 2004 14:00:20 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BC0GIt005269 for ; Sun, 11 Jul 2004 14:00:18 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCCMN1489K8Y5A3M@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Sun, 11 Jul 2004 21:58:00 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 772A580033; Sun, 11 Jul 2004 21:57:59 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6061F3C004; Sun, 11 Jul 2004 21:57:59 +1000 (EST) Received: from [211.28.76.48] by mail-store-2.its.monash.edu.au (mshttpd); Sun, 11 Jul 2004 21:57:59 +1000 Date: Sun, 11 Jul 2004 21:57:59 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Mohan Parthasarathy Cc: greg.daley@eng.monash.edu.au, James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Message-id: <3d63743db38f.3db38f3d6374@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.26 (built Mar 31 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Jul 2004 12:01:33.0663 (UTC) FILETIME=[CF4AB6F0:01C4673E] Content-Transfer-Encoding: 7BIT Hi Mohan, > > > Which deployment scenario requires secured Proxy ND ? If MIPv6 > is deployed by the operators, there would not be a real home link > AFAIK. If MIPv6 is deployed in an enterprise, the trust is sufficient > enough to not require proxy ND i guess. So, i am missing something > on where proxy-ND would be required in practice. Actually there's a possibility that Enterprises will be some of the earlier adopters of Mobile IPv6, as opposed to carriers (well not opposed, but as an adjunct). In this case, or in the case that a device is actually on a home network, it may make sense to turn off MIPv6 processing when at home (better MTUs, no per-packet IPSec processing load etc). For real (not dummy/loopback) home networks, there is a need for proxy ND, since we may have neighbours on the home network who wish to talk to us. In fact, there was discussion during Mobile IPv6 development aimed at getting rid of home networks in the specification (rather than just in implementations by using dummy homes). This was rejected at the time (I was in the party for removing them, and simplifying the spec). Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 08:14:18 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18704 for ; Sun, 11 Jul 2004 08:14:18 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6BCEIAh001985 for ; Sun, 11 Jul 2004 14:14:18 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Jul 2004 14:14:18 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4VDV6M; Sun, 11 Jul 2004 14:14:18 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6BCEAwg023528; Sun, 11 Jul 2004 14:14:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BCDZIt008391; Sun, 11 Jul 2004 14:13:35 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6BCDZw9008390; Sun, 11 Jul 2004 14:13:35 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BCDWIt008374 for ; Sun, 11 Jul 2004 14:13:33 +0200 (MET DST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LCCN4VGPUQ8Y7N47@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Sun, 11 Jul 2004 22:12:24 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 90612AB542; Sun, 11 Jul 2004 22:12:22 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 79A424FB03; Sun, 11 Jul 2004 22:12:22 +1000 (EST) Received: from [211.28.76.48] by mail-store-2.its.monash.edu.au (mshttpd); Sun, 11 Jul 2004 22:12:22 +1000 Date: Sun, 11 Jul 2004 22:12:22 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Mohan Parthasarathy Cc: greg.daley@eng.monash.edu.au, James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Message-id: <3d571d3d7650.3d76503d571d@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.26 (built Mar 31 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Jul 2004 12:14:18.0202 (UTC) FILETIME=[96FE1BA0:01C46740] Content-Transfer-Encoding: 7BIT Hi Mohan, I think I've only half answered your question Please see below. ... > If MIPv6 is deployed in an enterprise, the trust is sufficient > enough to not require proxy ND i guess. ... I actually think this is a big problem: assuming that devices on the home link are secured. Typically, I'd ask the question: How many viruses attack other hosts from inside the corporate firewall? It's reasonable to expect that any attack is possible. I heard of an attack a long time ago which used ARP spoofing and SNMP to destroy a certain brand of router's configuration. The attacker needed to be on-link. Nowadays in IPv4, a single person receiving an e-mail attachment can cause grief for anyone on the link (or on multiple links), by scanning or multicasting to all IP addresses in the subnet. My guess is that with IPv6 on-link address suffixes using (typically) 64 bits, attackers will need to use multicast to identify other nodes on-link, or monitor exchanges such as ND to identify and attack victims. Of course, this is likely not to be a problem for the short term, nor may it be explicitly related to Proxy Neighbour Disocvery and its use in MIPv6. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 08:29:59 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19536 for ; Sun, 11 Jul 2004 08:29:58 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6BCTwAh002763 for ; Sun, 11 Jul 2004 14:29:58 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Jul 2004 14:29:58 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4VDXJN; Sun, 11 Jul 2004 14:29:58 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6BCTrwg024051; Sun, 11 Jul 2004 14:29:53 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BCTAIt012400; Sun, 11 Jul 2004 14:29:10 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6BCTAeD012399; Sun, 11 Jul 2004 14:29:10 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BCT8It012395 for ; Sun, 11 Jul 2004 14:29:09 +0200 (MET DST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LCCNMOKPUM8Y7SA2@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Sun, 11 Jul 2004 22:26:46 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 10580AB542; Sun, 11 Jul 2004 22:26:44 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id F25154FB0A; Sun, 11 Jul 2004 22:26:43 +1000 (EST) Received: from [211.28.76.48] by mail-store-2.its.monash.edu.au (mshttpd); Sun, 11 Jul 2004 22:26:43 +1000 Date: Sun, 11 Jul 2004 22:26:43 +1000 From: Greg Daley Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility To: Mohan Parthasarathy Cc: James Kempf , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Message-id: <3da5693d86aa.3d86aa3da569@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.26 (built Mar 31 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Jul 2004 12:29:58.0511 (UTC) FILETIME=[C775DFF0:01C46742] Content-Transfer-Encoding: 7BIT Hi James and Mohan, It's not the NAR which needs to do proxying, it's the PAR. The PAR is on the network where the MN has existing NCE's with other hosts and routers. The PAR has to override these NCE's with its own link-layer address to begin forwarding packets received on-link for the MN. This is required for Both the predictive and non-predictive scenarios. ----- Original Message ----- From: Mohan Parthasarathy Date: Sunday, July 11, 2004 8:32 am Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility > James, > > > > > > jak>> Depending on whether the wireless link technology supports > predictive> or reactive handover, there may be an issue with > proxying. For a predictive > > technology, the NAR may be required to proxy since the PAR > informs it of the > > new CoA prior to the actual link handover. However, this is entirely > > theoretical at the moment, because there is no widely available > wireless> link technology that supports predictive handover and, > simultaneously, would > > be in a position to use FMIPv6. The cellular technologies all do > local link > > handover optimization their own way ("stretchy PPP" for 3GPP2, > GPRS for PP). > > 802.16 may support predictive handover, but the WG doing mobility > is about 2 > > years from completing the basic link design (I think it's .16e) > if I > > understand correctly. With a reactive wireless link technology, > there's no > > need for proxying because the mobile doesn't actually claim the > CoA until it > > is on the link. 802.11 is a reactive technology, as is 802.15.2 > (Bluetooth), > I don't understand this part. Why do you think in 802.11, that the > NAR cannot defend > the new CoA when the MN is on the old link ? When the node is on > the old link, why can't it > do the standard FMIPv6 like on any other link ? > > thanks > mohan > > > and so they don't need proxying. Given the focus in SEND on meeting > > immediate technology needs quickly rather than doing the full > solution too > > late, the WG decided to forgo working on secure proxying for now, > though the > > design team did discuss some approaches. If SEND turns out to be > popular, we > > can have a BOF and restart the WG to work on the remaining issues. That sounds OK with me (although FMIPv6 and MIPv6 do require proxying if they share a 'home' or 'old' link with other devices). Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 17:03:24 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13065 for ; Sun, 11 Jul 2004 17:03:24 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6BL3PWR027264 for ; Sun, 11 Jul 2004 23:03:25 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Jul 2004 23:03:24 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4VFF4F; Sun, 11 Jul 2004 23:03:24 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6BL3NXA023637; Sun, 11 Jul 2004 23:03:23 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BL2WIt000553; Sun, 11 Jul 2004 23:02:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6BL2V38000552; Sun, 11 Jul 2004 23:02:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp810.mail.sc5.yahoo.com (smtp810.mail.sc5.yahoo.com [66.163.170.80]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i6BL2TIt000547 for ; Sun, 11 Jul 2004 23:02:29 +0200 (MET DST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.59.233 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 11 Jul 2004 21:02:28 -0000 Message-ID: <004e01c4678a$5f6b45b0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Greg Daley" Cc: , "James Kempf" , "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <3d63743db38f.3db38f3d6374@monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Sun, 11 Jul 2004 14:02:27 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Jul 2004 21:03:24.0983 (UTC) FILETIME=[818C7470:01C4678A] Content-Transfer-Encoding: 7bit > Hi Mohan, > > > > > > Which deployment scenario requires secured Proxy ND ? If MIPv6 > > is deployed by the operators, there would not be a real home link > > AFAIK. If MIPv6 is deployed in an enterprise, the trust is sufficient > > enough to not require proxy ND i guess. So, i am missing something > > on where proxy-ND would be required in practice. > > Actually there's a possibility that > Enterprises will be some of the earlier adopters > of Mobile IPv6, as opposed to carriers > (well not opposed, but as an adjunct). > > In this case, or in the case that a device > is actually on a home network, it may make sense > to turn off MIPv6 processing when at home > (better MTUs, no per-packet IPSec processing load > etc). > > For real (not dummy/loopback) home networks, > there is a need for proxy ND, since we may have > neighbours on the home network who wish to > talk to us. > My question was a bit confusing. I did not intend to question the need for proxy ND. Only the security for it in the context of MIPv6, which you answered in your next mail. -mohan > In fact, there was discussion during Mobile IPv6 > development aimed at getting rid of home networks > in the specification (rather than just in > implementations by using dummy homes). This was > rejected at the time (I was in the party for > removing them, and simplifying the spec). > > Greg > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 18:11:13 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16158 for ; Sun, 11 Jul 2004 18:11:13 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6BMB9PA003548 for ; Mon, 12 Jul 2004 00:11:14 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 00:11:09 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4VFMHG; Mon, 12 Jul 2004 00:11:09 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6BMAswg019379; Mon, 12 Jul 2004 00:10:54 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BMA0It018043; Mon, 12 Jul 2004 00:10:00 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6BM9xQi018041; Mon, 12 Jul 2004 00:09:59 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i6BM9vIt018005 for ; Mon, 12 Jul 2004 00:09:58 +0200 (MET DST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.59.233 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 11 Jul 2004 22:09:56 -0000 Message-ID: <005601c46793$cbf6f770$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Greg Daley" Cc: , "James Kempf" , "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <3d571d3d7650.3d76503d571d@monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Sun, 11 Jul 2004 15:09:54 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Jul 2004 22:11:09.0734 (UTC) FILETIME=[F8543C60:01C46793] Content-Transfer-Encoding: 7bit > Hi Mohan, > > I think I've only half answered your question > > Please see below. > > ... > > If MIPv6 is deployed in an enterprise, the trust is sufficient > > enough to not require proxy ND i guess. > ... ^^^ Just to clarify : "secure" was missing above. > > I actually think this is a big problem: > assuming that devices on the home link are > secured. > What do you mean by "secured" ? SEND or something else ? > Typically, I'd ask the question: > How many viruses attack other hosts from inside > the corporate firewall? > > It's reasonable to expect that any attack is > possible. I heard of an attack a long time ago > which used ARP spoofing and SNMP to destroy > a certain brand of router's configuration. > > The attacker needed to be on-link. > > Nowadays in IPv4, a single person receiving an e-mail attachment can cause grief for anyone on the link (or on multiple links), by scanning or > multicasting to all IP addresses in the subnet. > > My guess is that with IPv6 on-link address suffixes > using (typically) 64 bits, attackers will need to > use multicast to identify other nodes on-link, or > monitor exchanges such as ND to identify and > attack victims. > I am not sure i understood all of it. A virus infecting a machine that uses SEND can enjoy all the benefits of SEND. How does SEND prevent the virus from spreading ? Perhaps, i am missing something here. I agree that if the enterprise adopts SEND for some reason, then when it deploys MIP6, for the same reason it may also want to secure proxy-ND also. But it will be interesting to see how and when enterprise begins to deploy SEND. > Of course, this is likely not to be a problem > for the short term, nor may it be explicitly > related to Proxy Neighbour Disocvery and its > use in MIPv6. > > Greg > -mohan -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 18:12:11 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16269 for ; Sun, 11 Jul 2004 18:12:11 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6BMCBWR003265 for ; Mon, 12 Jul 2004 00:12:12 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 00:12:11 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321L87YS; Mon, 12 Jul 2004 00:12:11 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6BMCAXA024121; Mon, 12 Jul 2004 00:12:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BMC1It018572; Mon, 12 Jul 2004 00:12:01 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6BMC1CG018568; Mon, 12 Jul 2004 00:12:01 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp812.mail.sc5.yahoo.com (smtp812.mail.sc5.yahoo.com [66.163.170.82]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i6BMBxIt018523 for ; Mon, 12 Jul 2004 00:11:59 +0200 (MET DST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.59.233 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 11 Jul 2004 22:11:58 -0000 Message-ID: <005a01c46794$14587a20$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Greg Daley" Cc: "James Kempf" , "Jean-Michel COMBES" , , References: <3da5693d86aa.3d86aa3da569@monash.edu.au> Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Sun, 11 Jul 2004 15:11:55 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Jul 2004 22:12:11.0411 (UTC) FILETIME=[1D176630:01C46794] Content-Transfer-Encoding: 7bit > Hi James and Mohan, > > It's not the NAR which needs to do proxying, > it's the PAR. > It is required on the NAR also so that it can defend the address till the MN attaches to the new link. -mohan > The PAR is on the network where the MN has > existing NCE's with other hosts and routers. > The PAR has to override these NCE's with its > own link-layer address to begin forwarding > packets received on-link for the MN. > > This is required for Both the predictive > and non-predictive scenarios. > > ----- Original Message ----- > From: Mohan Parthasarathy > Date: Sunday, July 11, 2004 8:32 am > Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility > > > James, > > > > > > > > > > jak>> Depending on whether the wireless link technology supports > > predictive> or reactive handover, there may be an issue with > > proxying. For a predictive > > > technology, the NAR may be required to proxy since the PAR > > informs it of the > > > new CoA prior to the actual link handover. However, this is entirely > > > theoretical at the moment, because there is no widely available > > wireless> link technology that supports predictive handover and, > > simultaneously, would > > > be in a position to use FMIPv6. The cellular technologies all do > > local link > > > handover optimization their own way ("stretchy PPP" for 3GPP2, > > GPRS for PP). > > > 802.16 may support predictive handover, but the WG doing mobility > > is about 2 > > > years from completing the basic link design (I think it's .16e) > > if I > > > understand correctly. With a reactive wireless link technology, > > there's no > > > need for proxying because the mobile doesn't actually claim the > > CoA until it > > > is on the link. 802.11 is a reactive technology, as is 802.15.2 > > (Bluetooth), > > I don't understand this part. Why do you think in 802.11, that the > > NAR cannot defend > > the new CoA when the MN is on the old link ? When the node is on > > the old link, why can't it > > do the standard FMIPv6 like on any other link ? > > > > thanks > > mohan > > > > > and so they don't need proxying. Given the focus in SEND on meeting > > > immediate technology needs quickly rather than doing the full > > solution too > > > late, the WG decided to forgo working on secure proxying for now, > > though the > > > design team did discuss some approaches. If SEND turns out to be > > popular, we > > > can have a BOF and restart the WG to work on the remaining issues. > > That sounds OK with me (although FMIPv6 and MIPv6 > do require proxying if they share a 'home' or 'old' > link with other devices). > > Greg > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 19:15:47 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18523 for ; Sun, 11 Jul 2004 19:15:46 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6BNFlWR007947 for ; Mon, 12 Jul 2004 01:15:48 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 01:15:47 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3236860C; Mon, 12 Jul 2004 01:15:47 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6BNFiwg021377; Mon, 12 Jul 2004 01:15:44 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BNEtIt007452; Mon, 12 Jul 2004 01:14:55 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6BNEtK9007449; Mon, 12 Jul 2004 01:14:55 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BNEqIt007431 for ; Mon, 12 Jul 2004 01:14:53 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCDA8JQ5RE8WW3AW@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 12 Jul 2004 09:13:31 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7423D80035; Mon, 12 Jul 2004 09:13:30 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4BA673C005; Mon, 12 Jul 2004 09:13:30 +1000 (EST) Date: Mon, 12 Jul 2004 09:13:30 +1000 From: Greg Daley Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility To: Mohan Parthasarathy Cc: James Kempf , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F1C99A.6030204@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3da5693d86aa.3d86aa3da569@monash.edu.au> <005a01c46794$14587a20$6401a8c0@adithya> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Jul 2004 23:15:47.0403 (UTC) FILETIME=[FF9991B0:01C4679C] Content-Transfer-Encoding: 7BIT Hi Mohan, Mohan Parthasarathy wrote: > > >>Hi James and Mohan, >> >>It's not the NAR which needs to do proxying, >>it's the PAR. >> > > It is required on the NAR also so that it can defend the address till the > MN attaches to the new link. That is correct if you believe that DAD defense of an predicted address is necessary to FMIPv6 :) Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 19:27:09 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18976 for ; Sun, 11 Jul 2004 19:27:09 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6BNRAAh001724 for ; Mon, 12 Jul 2004 01:27:11 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 01:27:10 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3236874W; Mon, 12 Jul 2004 01:27:10 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6BNR5wg021648; Mon, 12 Jul 2004 01:27:05 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BNQYIt010787; Mon, 12 Jul 2004 01:26:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6BNQYVb010786; Mon, 12 Jul 2004 01:26:34 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6BNQVIt010767 for ; Mon, 12 Jul 2004 01:26:32 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCDAN6WFHQ8WW1Q8@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 12 Jul 2004 09:25:19 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B01CF80036; Mon, 12 Jul 2004 09:25:18 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 921213C003; Mon, 12 Jul 2004 09:25:18 +1000 (EST) Date: Mon, 12 Jul 2004 09:25:18 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Mohan Parthasarathy Cc: James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F1CC5E.8090106@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 11 Jul 2004 23:27:10.0813 (UTC) FILETIME=[96F1A8D0:01C4679E] Content-Transfer-Encoding: 7BIT Hi Mohan, Perhaps I may have used some unclear terminology... Mohan Parthasarathy wrote: > >>Hi Mohan, >> >>I think I've only half answered your question >> >>Please see below. >> >>... >> >>>If MIPv6 is deployed in an enterprise, the trust is sufficient >>>enough to not require proxy ND i guess. >> >>... ^^^ > > Just to clarify : "secure" was missing above. > OK. >>I actually think this is a big problem: >>assuming that devices on the home link are >>secured. >> > > What do you mean by "secured" ? SEND or something else ? Actually, I was talking about the concept that people assume that once you're firewalled off from the Internet, that robust security measures don't need to be applied. SEND helps provide robustness, because it is harder to break another's neighbour cache entries. > >>Typically, I'd ask the question: >>How many viruses attack other hosts from inside >>the corporate firewall? >> >>It's reasonable to expect that any attack is >>possible. I heard of an attack a long time ago >>which used ARP spoofing and SNMP to destroy >>a certain brand of router's configuration. >> >>The attacker needed to be on-link. >> >>Nowadays in IPv4, a single person receiving an e-mail attachment can cause grief for anyone on the link (or on multiple links), by > > scanning or > >>multicasting to all IP addresses in the subnet. >> >>My guess is that with IPv6 on-link address suffixes >>using (typically) 64 bits, attackers will need to >>use multicast to identify other nodes on-link, or >>monitor exchanges such as ND to identify and >>attack victims. >> > > I am not sure i understood all of it. A virus infecting a machine that uses SEND > can enjoy all the benefits of SEND. How does SEND prevent the virus from > spreading ? Perhaps, i am missing something here. The SEND device which is infected has all of the abilities of a SEND node: It can create neighbour cache entries for itself, and solicit others to advertise (that's all). Compromising a SEND node only allows the SEND node to change state related to itself. If nodes on the link didn't use SEND, a compromised node could attack any Neighbour Cache Entry it saw fit by generating bogus packets. The same issue exists for any node compromised when insecure proxy ND is available. > I agree that if the enterprise adopts SEND for some reason, then when it deploys MIP6, > for the same reason it may also want to secure proxy-ND also. But it will be > interesting to see how and when enterprise begins to deploy SEND. I think that SEND's costs are all to do with authorizing routers and configuring hosts to recognize at least one trust anchor. If an organization can set up certificates for Router Discovery, protecting on-link communications using SEND/CGA comes almost for free (except managing DNS records). Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 11 21:19:38 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22996 for ; Sun, 11 Jul 2004 21:19:37 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6C1JcAh008546 for ; Mon, 12 Jul 2004 03:19:38 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 03:19:38 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q010W8; Mon, 12 Jul 2004 03:19:38 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6C1JbXA025616; Mon, 12 Jul 2004 03:19:37 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6C1IeIt011048; Mon, 12 Jul 2004 03:18:40 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6C1IeBA011047; Mon, 12 Jul 2004 03:18:40 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6C1IcIt011043 for ; Mon, 12 Jul 2004 03:18:39 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCDEJCIE708WW3EA@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 12 Jul 2004 11:16:45 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E55F080034 for ; Mon, 12 Jul 2004 11:16:44 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id D0A423C006 for ; Mon, 12 Jul 2004 11:16:44 +1000 (EST) Date: Mon, 12 Jul 2004 11:16:44 +1000 From: Greg Daley Subject: Securing Proxy Neighbour Discovery Problem Statement To: ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F1E67C.9050601@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Jul 2004 01:19:38.0388 (UTC) FILETIME=[4CCFE540:01C467AE] Content-Transfer-Encoding: 7BIT Hi, I've just submitted a short (10 pages with 3667/8 boilerplate!) draft on securing proxy Neighbour Discovery. Here is a description: "Securing Proxy Neighbour Discovery Problem Statement" Abstract: Proxy Neighbour Discovery is used to provide an address presence on a link from hosts which are absent. It allows a host to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. Proxy Neighbour Discovery is used in Mobile IPv6 and related protocols to provide reachability from hosts on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. Proxy Neighbour Discovery currently cannot be secured using SEND. SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbour Discovery relates to Secured Neighbour Discovery. This draft should appear in the repository shortly, but in the mean time is available at the URL: http://www.ctie.monash.edu.au/ipv6/draft-daley-send-spnd-prob-00.txt (Another message will announce this on irtf-mobopts apologies if you recieve this twice). Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jul 12 12:01:04 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19927 for ; Mon, 12 Jul 2004 12:01:03 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6CG13WR014077 for ; Mon, 12 Jul 2004 18:01:04 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 18:01:03 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q0KV52; Mon, 12 Jul 2004 18:01:02 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6CG11XA009417; Mon, 12 Jul 2004 18:01:01 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6CFxrIt020436; Mon, 12 Jul 2004 17:59:53 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6CFxrQH020429; Mon, 12 Jul 2004 17:59:53 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6CFxoIt020308 for ; Mon, 12 Jul 2004 17:59:51 +0200 (MET DST) Message-ID: <007201c46829$5e2b7270$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Greg Daley" Cc: , "Vijay Devarapalli" , "Jean-Michel COMBES" , , , References: <3c8b1a3cc880.3cc8803c8b1a@monash.edu.au> Subject: Re: Proxy Neighbor Discovery Security in MOBOPTS? (was: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility) Date: Mon, 12 Jul 2004 09:00:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Jul 2004 16:01:03.0417 (UTC) FILETIME=[6EBEEA90:01C46829] Content-Transfer-Encoding: 7bit > The Bar BoF sounds like a good idea if we can get a > quick problem statement going about it. > We'll see if people are interested enough. > > I'd vote we go to a real bar this time though. > Fine by me. MOBOPTS is currently scheduled for Mon. 1-3, so perhaps we could do Mon. evening after the last sessions? Meet at the IETF Registration desk at 10? Alternatively, Bill and Rajeev, do we have some time during the meeting to disucss this? > Greg > > There may be interest if we talk to Dave Thaler too > about his NDproxy. > I talked to Dave about his NDproxy last time in Seoul, and I don't think the two are comparable. He's looking for a way to proxy the L2 address, not the IP address, if I remember correctly. The two are different. But I think it would be useful if he could be at the BAR BOF or whatever, since he's done some thinking about the problem. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jul 12 12:20:28 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21087 for ; Mon, 12 Jul 2004 12:20:27 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6CGKTWR017268 for ; Mon, 12 Jul 2004 18:20:29 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 18:20:28 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4VL68M; Mon, 12 Jul 2004 18:20:28 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6CGKRXA009719; Mon, 12 Jul 2004 18:20:27 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6CGJgIt008199; Mon, 12 Jul 2004 18:19:42 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6CGJfgG008189; Mon, 12 Jul 2004 18:19:41 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6CGJdIt008079 for ; Mon, 12 Jul 2004 18:19:39 +0200 (MET DST) Message-ID: <00b301c4682c$234af060$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mohan Parthasarathy" , "Jean-Michel COMBES" , Cc: References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <042f01c46387$ca1f24f0$536115ac@dcml.docomolabsusa.com> <009001c466cd$cb38e990$6401a8c0@adithya> Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Mon, 12 Jul 2004 09:20:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Jul 2004 16:20:28.0626 (UTC) FILETIME=[2543B320:01C4682C] Content-Transfer-Encoding: 7bit For reactive handover, the NAR doesn't know the new CoA until the MN switches to the new link. I suppose the MN could configure prior to switching if it had information on prefixes available on the new link, but in .11, the interface firmware typically makes the switch decision and it is difficult for the OS to intervene. For predictive handover, of course, the HI/HAck sends the new CoA to the NAR, so it can defend. jak ----- Original Message ----- From: "Mohan Parthasarathy" To: "James Kempf" ; "Jean-Michel COMBES" ; Cc: Sent: Saturday, July 10, 2004 3:32 PM Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility > James, > > > > > > jak>> Depending on whether the wireless link technology supports predictive > > or reactive handover, there may be an issue with proxying. For a predictive > > technology, the NAR may be required to proxy since the PAR informs it of the > > new CoA prior to the actual link handover. However, this is entirely > > theoretical at the moment, because there is no widely available wireless > > link technology that supports predictive handover and, simultaneously, would > > be in a position to use FMIPv6. The cellular technologies all do local link > > handover optimization their own way ("stretchy PPP" for 3GPP2, GPRS for PP). > > 802.16 may support predictive handover, but the WG doing mobility is about 2 > > years from completing the basic link design (I think it's .16e) if I > > understand correctly. With a reactive wireless link technology, there's no > > need for proxying because the mobile doesn't actually claim the CoA until it > > is on the link. 802.11 is a reactive technology, as is 802.15.2 (Bluetooth), > > I don't understand this part. Why do you think in 802.11, that the NAR cannot defend > the new CoA when the MN is on the old link ? When the node is on the old link, why can't it > do the standard FMIPv6 like on any other link ? > > thanks > mohan > > > and so they don't need proxying. Given the focus in SEND on meeting > > immediate technology needs quickly rather than doing the full solution too > > late, the WG decided to forgo working on secure proxying for now, though the > > design team did discuss some approaches. If SEND turns out to be popular, we > > can have a BOF and restart the WG to work on the remaining issues. > > > > jak > > > > > > -------------------------------------------------------------------- > > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > > body to . > > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jul 12 12:22:49 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21277 for ; Mon, 12 Jul 2004 12:22:48 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6CGMoWR017740 for ; Mon, 12 Jul 2004 18:22:50 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 18:22:50 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4VL7LS; Mon, 12 Jul 2004 18:22:50 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6CGMXwg004611; Mon, 12 Jul 2004 18:22:33 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6CGMKIt014651; Mon, 12 Jul 2004 18:22:20 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6CGMKlg014632; Mon, 12 Jul 2004 18:22:20 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6CGMHIt014487 for ; Mon, 12 Jul 2004 18:22:18 +0200 (MET DST) Message-ID: <00d001c4682c$81c0c340$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Greg Daley" , "Mohan Parthasarathy" Cc: "Jean-Michel COMBES" , , References: <3da5693d86aa.3d86aa3da569@monash.edu.au> Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Mon, 12 Jul 2004 09:23:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Jul 2004 16:22:50.0487 (UTC) FILETIME=[79D1F870:01C4682C] Content-Transfer-Encoding: 7bit Yes, that's right. PAR must proxy for both reactive and predictive handover, NAR must proxy for predictive handover. jak ----- Original Message ----- From: "Greg Daley" To: "Mohan Parthasarathy" Cc: "James Kempf" ; "Jean-Michel COMBES" ; ; Sent: Sunday, July 11, 2004 5:26 AM Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility > Hi James and Mohan, > > It's not the NAR which needs to do proxying, > it's the PAR. > > The PAR is on the network where the MN has > existing NCE's with other hosts and routers. > The PAR has to override these NCE's with its > own link-layer address to begin forwarding > packets received on-link for the MN. > > This is required for Both the predictive > and non-predictive scenarios. > > ----- Original Message ----- > From: Mohan Parthasarathy > Date: Sunday, July 11, 2004 8:32 am > Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility > > > James, > > > > > > > > > > jak>> Depending on whether the wireless link technology supports > > predictive> or reactive handover, there may be an issue with > > proxying. For a predictive > > > technology, the NAR may be required to proxy since the PAR > > informs it of the > > > new CoA prior to the actual link handover. However, this is entirely > > > theoretical at the moment, because there is no widely available > > wireless> link technology that supports predictive handover and, > > simultaneously, would > > > be in a position to use FMIPv6. The cellular technologies all do > > local link > > > handover optimization their own way ("stretchy PPP" for 3GPP2, > > GPRS for PP). > > > 802.16 may support predictive handover, but the WG doing mobility > > is about 2 > > > years from completing the basic link design (I think it's .16e) > > if I > > > understand correctly. With a reactive wireless link technology, > > there's no > > > need for proxying because the mobile doesn't actually claim the > > CoA until it > > > is on the link. 802.11 is a reactive technology, as is 802.15.2 > > (Bluetooth), > > I don't understand this part. Why do you think in 802.11, that the > > NAR cannot defend > > the new CoA when the MN is on the old link ? When the node is on > > the old link, why can't it > > do the standard FMIPv6 like on any other link ? > > > > thanks > > mohan > > > > > and so they don't need proxying. Given the focus in SEND on meeting > > > immediate technology needs quickly rather than doing the full > > solution too > > > late, the WG decided to forgo working on secure proxying for now, > > though the > > > design team did discuss some approaches. If SEND turns out to be > > popular, we > > > can have a BOF and restart the WG to work on the remaining issues. > > That sounds OK with me (although FMIPv6 and MIPv6 > do require proxying if they share a 'home' or 'old' > link with other devices). > > Greg > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jul 12 13:02:36 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24078 for ; Mon, 12 Jul 2004 13:02:35 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6CH2bWR023410 for ; Mon, 12 Jul 2004 19:02:37 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 19:02:36 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q0LAXZ; Mon, 12 Jul 2004 19:02:30 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6CH2TXA010252; Mon, 12 Jul 2004 19:02:30 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6CH0PIt024898; Mon, 12 Jul 2004 19:00:25 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6CH0OZ9024878; Mon, 12 Jul 2004 19:00:24 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp804.mail.sc5.yahoo.com (smtp804.mail.sc5.yahoo.com [66.163.168.183]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i6CH0JIt024524 for ; Mon, 12 Jul 2004 19:00:22 +0200 (MET DST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp804.mail.sc5.yahoo.com with SMTP; 12 Jul 2004 17:00:19 -0000 Message-ID: <002801c46831$b6ee8e30$861167c0@adithya> From: "Mohan Parthasarathy" To: "James Kempf" , "Jean-Michel COMBES" , Cc: References: <013701c45d0f$8e54c7f0$4aa1c10a@rd.francetelecom.fr> <042f01c46387$ca1f24f0$536115ac@dcml.docomolabsusa.com> <009001c466cd$cb38e990$6401a8c0@adithya> <00b301c4682c$234af060$536115ac@dcml.docomolabsusa.com> Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Mon, 12 Jul 2004 10:00:20 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 12 Jul 2004 17:02:36.0533 (UTC) FILETIME=[0803B250:01C46832] Content-Transfer-Encoding: 7bit > For reactive handover, the NAR doesn't know the new CoA until the MN > switches to the new link. I suppose the MN could configure prior to > switching if it had information on prefixes available on the new link, but > in .11, the interface firmware typically makes the switch decision and it is > difficult for the OS to intervene. > Look at http://hostap.epitest.fi and follow the README there. There are different modes the driver can operate on. And one of the modes (mode 3), the firmware and driver does not involve in any handoff decision. -mohan > For predictive handover, of course, the HI/HAck sends the new CoA to the > NAR, so it can defend. > > jak > > ----- Original Message ----- > From: "Mohan Parthasarathy" > To: "James Kempf" ; "Jean-Michel COMBES" > ; > Cc: > Sent: Saturday, July 10, 2004 3:32 PM > Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility > > > > James, > > > > > > > > > > jak>> Depending on whether the wireless link technology supports > predictive > > > or reactive handover, there may be an issue with proxying. For a > predictive > > > technology, the NAR may be required to proxy since the PAR informs it of > the > > > new CoA prior to the actual link handover. However, this is entirely > > > theoretical at the moment, because there is no widely available wireless > > > link technology that supports predictive handover and, simultaneously, > would > > > be in a position to use FMIPv6. The cellular technologies all do local > link > > > handover optimization their own way ("stretchy PPP" for 3GPP2, GPRS for > PP). > > > 802.16 may support predictive handover, but the WG doing mobility is > about 2 > > > years from completing the basic link design (I think it's .16e) if I > > > understand correctly. With a reactive wireless link technology, there's > no > > > need for proxying because the mobile doesn't actually claim the CoA > until it > > > is on the link. 802.11 is a reactive technology, as is 802.15.2 > (Bluetooth), > > > > I don't understand this part. Why do you think in 802.11, that the NAR > cannot defend > > the new CoA when the MN is on the old link ? When the node is on the old > link, why can't it > > do the standard FMIPv6 like on any other link ? > > > > thanks > > mohan > > > > > and so they don't need proxying. Given the focus in SEND on meeting > > > immediate technology needs quickly rather than doing the full solution > too > > > late, the WG decided to forgo working on secure proxying for now, though > the > > > design team did discuss some approaches. If SEND turns out to be > popular, we > > > can have a BOF and restart the WG to work on the remaining issues. > > > > > > jak > > > > > > > > > -------------------------------------------------------------------- > > > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > > > body to . > > > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jul 12 22:03:00 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13859 for ; Mon, 12 Jul 2004 22:02:59 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6D231Ah013688 for ; Tue, 13 Jul 2004 04:03:01 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Jul 2004 04:03:00 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321MHHG0; Tue, 13 Jul 2004 04:03:00 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6D22xXA015547; Tue, 13 Jul 2004 04:02:59 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6D20YIt019549; Tue, 13 Jul 2004 04:00:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6D20Y8v019535; Tue, 13 Jul 2004 04:00:34 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i6D20VIt019382 for ; Tue, 13 Jul 2004 04:00:31 +0200 (MET DST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 13 Jul 2004 02:00:29 -0000 Message-ID: <011001c4687d$2a7b9780$861167c0@adithya> From: "Mohan Parthasarathy" To: Cc: "James Kempf" , "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Mon, 12 Jul 2004 19:00:26 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 13 Jul 2004 02:03:00.0787 (UTC) FILETIME=[86603830:01C4687D] Content-Transfer-Encoding: 7bit > > > > I am not sure i understood all of it. A virus infecting a machine that uses SEND > > can enjoy all the benefits of SEND. How does SEND prevent the virus from > > spreading ? Perhaps, i am missing something here. > > The SEND device which is infected has all of the abilities > of a SEND node: > > It can create neighbour cache entries for itself, and solicit > others to advertise (that's all). > > Compromising a SEND node only allows the SEND node to change > state related to itself. > > If nodes on the link didn't use SEND, a compromised node could > attack any Neighbour Cache Entry it saw fit by generating bogus > packets. > > The same issue exists for any node compromised when insecure > proxy ND is available. > Ok. But for this to work, you can't have a mix of SEND and non-SEND nodes. I am not sure whether it is realistic to transition completely to SEND. > > I agree that if the enterprise adopts SEND for some reason, then when it deploys MIP6, > > for the same reason it may also want to secure proxy-ND also. But it will be > > interesting to see how and when enterprise begins to deploy SEND. > > I think that SEND's costs are all to do with authorizing routers > and configuring hosts to recognize at least one trust anchor. > > If an organization can set up certificates for Router Discovery, > protecting on-link communications using SEND/CGA comes almost > for free (except managing DNS records). > With the approach that you wrote up in this thread, you need certificates for NS/NA also if i am not mistaken. Are there any specific reasons why current SEND does not use non-CGA approach for NS/NA ? From section 4 of SEND: This specification also allows a node to use non-CGAs with certificates to authorize their use. However, the details of such use are beyond the scope of this specification. -mohan > Greg > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jul 12 22:26:13 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16159 for ; Mon, 12 Jul 2004 22:26:12 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6D2QEPA017143 for ; Tue, 13 Jul 2004 04:26:14 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Jul 2004 04:26:13 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3237H2LW; Tue, 13 Jul 2004 04:25:55 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6D2PsXA015714; Tue, 13 Jul 2004 04:25:54 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6D2O0It015921; Tue, 13 Jul 2004 04:24:00 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6D2Nxde015896; Tue, 13 Jul 2004 04:23:59 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6D2NvIt015559 for ; Tue, 13 Jul 2004 04:23:57 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCEV4JAOK68Y5K1E@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Tue, 13 Jul 2004 12:22:46 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 35A198003C; Tue, 13 Jul 2004 12:22:41 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 35D5F3C017; Tue, 13 Jul 2004 12:22:40 +1000 (EST) Date: Tue, 13 Jul 2004 12:22:39 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Mohan Parthasarathy Cc: James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F3476F.6000408@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 13 Jul 2004 02:26:13.0668 (UTC) FILETIME=[C498FE40:01C46880] Content-Transfer-Encoding: 7BIT Hi Mohan, Mohan Parthasarathy wrote: > > > > > > >>>I am not sure i understood all of it. A virus infecting a machine that uses SEND >>>can enjoy all the benefits of SEND. How does SEND prevent the virus from >>>spreading ? Perhaps, i am missing something here. >> >>The SEND device which is infected has all of the abilities >>of a SEND node: >> >>It can create neighbour cache entries for itself, and solicit >>others to advertise (that's all). >> >>Compromising a SEND node only allows the SEND node to change >>state related to itself. >> >>If nodes on the link didn't use SEND, a compromised node could >>attack any Neighbour Cache Entry it saw fit by generating bogus >>packets. >> >>The same issue exists for any node compromised when insecure >>proxy ND is available. >> > > Ok. But for this to work, you can't have a mix of SEND and non-SEND nodes. > I am not sure whether it is realistic to transition completely to SEND. Actually non-send nodes will never see the SEND options, so it may be possible to be backwards compatible with them (as is already done in SEND). The actual resources devoted to non-SEND nodes can be restricted, and the main thing is that SEND advertisements cannot be overwritten with a non-SEND advertisement. >>>I agree that if the enterprise adopts SEND for some reason, then when it deploys MIP6, >>>for the same reason it may also want to secure proxy-ND also. But it will be >>>interesting to see how and when enterprise begins to deploy SEND. >> >>I think that SEND's costs are all to do with authorizing routers >>and configuring hosts to recognize at least one trust anchor. >> >>If an organization can set up certificates for Router Discovery, >>protecting on-link communications using SEND/CGA comes almost >>for free (except managing DNS records). >> > > With the approach that you wrote up in this thread, you need certificates > for NS/NA also if i am not mistaken. Are there any specific reasons why > current SEND does not use non-CGA approach for NS/NA ? From section 4 > of SEND: > > This specification also allows a node to use non-CGAs with > certificates to authorize their use. However, the details of such > use are beyond the scope of this specification. I think that people were considering what may be necessary in the future (alternative security mechanisms such as ABKs, for example) and also the need for proxying, which was not unheard of at the time. What we need to see is if the security for proxying is needed, particularly that there are valid scenarios where PND needs to be done. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jul 13 12:02:31 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20435 for ; Tue, 13 Jul 2004 12:02:30 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6DG2QPA015264 for ; Tue, 13 Jul 2004 18:02:30 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Jul 2004 18:02:25 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4VW1AM; Tue, 13 Jul 2004 18:02:23 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6DG24wg011937; Tue, 13 Jul 2004 18:02:04 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6DG0lIt014150; Tue, 13 Jul 2004 18:00:47 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6DG0kU0014125; Tue, 13 Jul 2004 18:00:46 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6DG0iIt013915 for ; Tue, 13 Jul 2004 18:00:45 +0200 (MET DST) Message-ID: <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Mohan Parthasarathy" Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Tue, 13 Jul 2004 09:01:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 13 Jul 2004 16:02:25.0893 (UTC) FILETIME=[CA518150:01C468F2] Content-Transfer-Encoding: 7bit > >>>I am not sure i understood all of it. A virus infecting a machine that uses SEND > >>>can enjoy all the benefits of SEND. How does SEND prevent the virus from > >>>spreading ? Perhaps, i am missing something here. > >> > >>The SEND device which is infected has all of the abilities > >>of a SEND node: > >> > >>It can create neighbour cache entries for itself, and solicit > >>others to advertise (that's all). > >> > >>Compromising a SEND node only allows the SEND node to change > >>state related to itself. > >> > >>If nodes on the link didn't use SEND, a compromised node could > >>attack any Neighbour Cache Entry it saw fit by generating bogus > >>packets. > >> > >>The same issue exists for any node compromised when insecure > >>proxy ND is available. > >> > > > > Ok. But for this to work, you can't have a mix of SEND and non-SEND nodes. > > I am not sure whether it is realistic to transition completely to SEND. > > Actually non-send nodes will never see the SEND options, so > it may be possible to be backwards compatible with them > (as is already done in SEND). > > The actual resources devoted to non-SEND nodes can be restricted, > and the main thing is that SEND advertisements cannot be overwritten > with a non-SEND advertisement. > Right, I'm not sure exactly what led to that conclusion, Mohan. The SEND spec supports both secure and insecure nodes on the same link. A node can be configured to accept or reject nonsecured NAs and RAs. If the node rejects nonsecured NAs and RAs, then there shouldn't be a problem with proxies if they are secured. Am I missing something? > >>>I agree that if the enterprise adopts SEND for some reason, then when it deploys MIP6, > >>>for the same reason it may also want to secure proxy-ND also. But it will be > >>>interesting to see how and when enterprise begins to deploy SEND. > >> > >>I think that SEND's costs are all to do with authorizing routers > >>and configuring hosts to recognize at least one trust anchor. > >> > >>If an organization can set up certificates for Router Discovery, > >>protecting on-link communications using SEND/CGA comes almost > >>for free (except managing DNS records). > >> > > > > With the approach that you wrote up in this thread, you need certificates > > for NS/NA also if i am not mistaken. Are there any specific reasons why > > current SEND does not use non-CGA approach for NS/NA ? From section 4 > > of SEND: > > > > This specification also allows a node to use non-CGAs with > > certificates to authorize their use. However, the details of such > > use are beyond the scope of this specification. > > I think that people were considering what may be necessary in the > future (alternative security mechanisms such as ABKs, for example) > and also the need for proxying, which was not unheard of at the time. > > What we need to see is if the security for proxying is needed, > particularly that there are valid scenarios where PND needs to > be done. > Actually, there are a couple issues with address certificates for hosts: 1) Host certificate provisioning is one of the thorniest issues in IP security. In general, it hasn't really proven to be widely deployable, and many equate it with the "global PKI" bogie. The solutions (like TLS/SSL) that have been widely deployed primarily involve cert provisioning of network entities like servers. In the SEND case, the base spec only requires the routers to be provisioned. Hosts only need root CA certs. Since there are far fewer routers than hosts, ISPs don't have to go the the difficulty and expense of running a PKI for all their customers, just for their internal equipment.* 2) Even if host certificates were easy to provision, it is not exactly clear how one would indicate in the certificate that a particular host is entitled to a particular IP address. An extension or something, like the address prefix extension for routers, would be one way to go. But the extension probably wouldn't give the entire address, probably just the MAC address used to form the interface identifier (Mobile IP home addresses might be an exception). That way, the certificate could be used with a variety of subnet prefixes. However, the MAC address isn't controlled by the IETF, and very few MAC layers provide such certs (I think Cablelabs and 802.16 do). And, in addition, there's DHCP to consider. The base SEND spec doesn't include support for DHCP, since CGAs are autoconfigured, but any spec using certs should. So, given these deployment issues, the SEND WG decided to punt on address certs for now, until its clear whether people are actually willing to implement and deploy the technology. The base spec allows address certs, but it doesn't provide any details about how to use them. Again, if there's interest, it can be done later. jak *Small plug for my employer: Docomo runs a PKI called FirstPass that allows all FOMA hosts to be provisioned with a certificate for bidirectional TLS authentication. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jul 13 20:46:40 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16251 for ; Tue, 13 Jul 2004 20:46:39 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6E0kXPA005918 for ; Wed, 14 Jul 2004 02:46:33 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 02:46:33 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4VYXJ8; Wed, 14 Jul 2004 02:46:32 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6E0kKwg003165; Wed, 14 Jul 2004 02:46:20 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6E0jFIt028706; Wed, 14 Jul 2004 02:45:15 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6E0jFGJ028692; Wed, 14 Jul 2004 02:45:15 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6E0jCIt028420 for ; Wed, 14 Jul 2004 02:45:13 +0200 (MET DST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCG609IOSU8WW7LM@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Wed, 14 Jul 2004 10:44:41 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6D658AB547; Wed, 14 Jul 2004 10:44:40 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 537A34FB0C; Wed, 14 Jul 2004 10:44:40 +1000 (EST) Date: Wed, 14 Jul 2004 10:44:40 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: James Kempf Cc: Mohan Parthasarathy , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F481F8.3070806@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 00:46:33.0084 (UTC) FILETIME=[024E0BC0:01C4693C] Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: [chop] >>>for NS/NA also if i am not mistaken. Are there any specific reasons why >>>current SEND does not use non-CGA approach for NS/NA ? From section 4 >>>of SEND: >>> >>> This specification also allows a node to use non-CGAs with >>> certificates to authorize their use. However, the details of such >>> use are beyond the scope of this specification. >> >>I think that people were considering what may be necessary in the >>future (alternative security mechanisms such as ABKs, for example) >>and also the need for proxying, which was not unheard of at the time. >> >>What we need to see is if the security for proxying is needed, >>particularly that there are valid scenarios where PND needs to >>be done. >> > > > Actually, there are a couple issues with address certificates for hosts: > > 1) Host certificate provisioning is one of the thorniest issues in IP > security. In general, it hasn't really proven to be widely deployable, and > many equate it with the "global PKI" bogie. The solutions (like TLS/SSL) > that have been widely deployed primarily involve cert provisioning of > network entities like servers. In the SEND case, the base spec only requires > the routers to be provisioned. Hosts only need root CA certs. Since there > are far fewer routers than hosts, ISPs don't have to go the the difficulty > and expense of running a PKI for all their customers, just for their > internal equipment.* > > 2) Even if host certificates were easy to provision, it is not exactly clear > how one would indicate in the certificate that a particular host is entitled > to a particular IP address. An extension or something, like the address > prefix extension for routers, would be one way to go. But the extension > probably wouldn't give the entire address, probably just the MAC address > used to form the interface identifier (Mobile IP home addresses might be an > exception). That way, the certificate could be used with a variety of subnet > prefixes. However, the MAC address isn't controlled by the IETF, and very > few MAC layers provide such certs (I think Cablelabs and 802.16 do). And, in > addition, there's DHCP to consider. The base SEND spec doesn't include > support for DHCP, since CGAs are autoconfigured, but any spec using certs > should. > > So, given these deployment issues, the SEND WG decided to punt on address > certs for now, until its clear whether people are actually willing to > implement and deploy the technology. The base spec allows address certs, but > it doesn't provide any details about how to use them. Again, if there's > interest, it can be done later. Please don't think I'm "teaching you to suck eggs" (instructing you in what you already know), but just clarifying if we're on the same path. I'd guess that the principle difference is that CGA's provide sufficient proof of ownership for ND (since we're adjacent to the device, and the prefix is one of a small set we're interested in). In proxy neighbour discovery the assumption is modified a little, allowing devices which aren't present to be advertised, but only through a currently existing local SEND node. Using CGAs as the start of authority for securing PND seems to be an appropriate step considering the existing setup in SEND. certificates prove that the CGA owner (through the included public key and signature) has delegated its authority itself. This removes a requirement for central control of the certificates. Does this sound alright to you? > jak > > *Small plug for my employer: Docomo runs a PKI called FirstPass that allows > all FOMA hosts to be provisioned with a certificate for bidirectional TLS > authentication. > > we know who to address all the PKI questions to then.... Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jul 13 22:20:14 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28367 for ; Tue, 13 Jul 2004 22:20:13 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6E2KEWR029196 for ; Wed, 14 Jul 2004 04:20:14 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 04:20:13 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q0XV1D; Wed, 14 Jul 2004 04:20:13 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6E2KCXA023410; Wed, 14 Jul 2004 04:20:12 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6E2JDIt008137; Wed, 14 Jul 2004 04:19:13 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6E2JCVG008132; Wed, 14 Jul 2004 04:19:12 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp813.mail.sc5.yahoo.com (smtp813.mail.sc5.yahoo.com [66.163.170.83]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i6E2JAIt008035 for ; Wed, 14 Jul 2004 04:19:11 +0200 (MET DST) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 14 Jul 2004 02:19:09 -0000 Message-ID: <00af01c46948$f02f4cd0$861167c0@adithya> From: "Mohan Parthasarathy" To: "James Kempf" , Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Tue, 13 Jul 2004 19:19:04 -0700 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.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 02:20:13.0373 (UTC) FILETIME=[184216D0:01C46949] Content-Transfer-Encoding: 7bit > > >>>I am not sure i understood all of it. A virus infecting a machine that > uses SEND > > >>>can enjoy all the benefits of SEND. How does SEND prevent the virus > from > > >>>spreading ? Perhaps, i am missing something here. > > >> > > >>The SEND device which is infected has all of the abilities > > >>of a SEND node: > > >> > > >>It can create neighbour cache entries for itself, and solicit > > >>others to advertise (that's all). > > >> > > >>Compromising a SEND node only allows the SEND node to change > > >>state related to itself. > > >> > > >>If nodes on the link didn't use SEND, a compromised node could > > >>attack any Neighbour Cache Entry it saw fit by generating bogus > > >>packets. > > >> > > >>The same issue exists for any node compromised when insecure > > >>proxy ND is available. > > >> > > > > > > Ok. But for this to work, you can't have a mix of SEND and non-SEND > nodes. > > > I am not sure whether it is realistic to transition completely to SEND. > > > > Actually non-send nodes will never see the SEND options, so > > it may be possible to be backwards compatible with them > > (as is already done in SEND). > > > > The actual resources devoted to non-SEND nodes can be restricted, > > and the main thing is that SEND advertisements cannot be overwritten > > with a non-SEND advertisement. > > > > > Right, I'm not sure exactly what led to that conclusion, Mohan. The SEND > spec supports both secure and insecure nodes on the same link. A node can be > configured to accept or reject nonsecured NAs and RAs. If the node rejects > nonsecured NAs and RAs, then there shouldn't be a problem with proxies if > they are secured. Am I missing something? > No. But SEND nodes have to accept NAs from non-SEND nodes in a mixed mode environment. So, it is possible that you receive the insecure NA, send the queued packet, receive the secure NA, overide the NCE with information from secure NA. I don't know what that one packet can do. Anyway, i am a bit confused about how this relates to the original virus attack that Greg explained.. > > > >>>I agree that if the enterprise adopts SEND for some reason, then when > it deploys MIP6, > > >>>for the same reason it may also want to secure proxy-ND also. But it > will be > > >>>interesting to see how and when enterprise begins to deploy SEND. > > >> > > >>I think that SEND's costs are all to do with authorizing routers > > >>and configuring hosts to recognize at least one trust anchor. > > >> > > >>If an organization can set up certificates for Router Discovery, > > >>protecting on-link communications using SEND/CGA comes almost > > >>for free (except managing DNS records). > > >> > > > > > > With the approach that you wrote up in this thread, you need > certificates > > > for NS/NA also if i am not mistaken. Are there any specific reasons why > > > current SEND does not use non-CGA approach for NS/NA ? From section 4 > > > of SEND: > > > > > > This specification also allows a node to use non-CGAs with > > > certificates to authorize their use. However, the details of such > > > use are beyond the scope of this specification. > > > > I think that people were considering what may be necessary in the > > future (alternative security mechanisms such as ABKs, for example) > > and also the need for proxying, which was not unheard of at the time. > > > > What we need to see is if the security for proxying is needed, > > particularly that there are valid scenarios where PND needs to > > be done. > > > > Actually, there are a couple issues with address certificates for hosts: > > 1) Host certificate provisioning is one of the thorniest issues in IP > security. In general, it hasn't really proven to be widely deployable, and > many equate it with the "global PKI" bogie. The solutions (like TLS/SSL) > that have been widely deployed primarily involve cert provisioning of > network entities like servers. In the SEND case, the base spec only requires > the routers to be provisioned. Hosts only need root CA certs. Since there > are far fewer routers than hosts, ISPs don't have to go the the difficulty > and expense of running a PKI for all their customers, just for their > internal equipment.* > > 2) Even if host certificates were easy to provision, it is not exactly clear > how one would indicate in the certificate that a particular host is entitled > to a particular IP address. An extension or something, like the address Hmm.. if i have the right private key, isn't that sufficient that i own the address on the certificate ? > prefix extension for routers, would be one way to go. But the extension > probably wouldn't give the entire address, probably just the MAC address > used to form the interface identifier (Mobile IP home addresses might be an > exception). That way, the certificate could be used with a variety of subnet > prefixes. However, the MAC address isn't controlled by the IETF, and very > few MAC layers provide such certs (I think Cablelabs and 802.16 do). And, in > addition, there's DHCP to consider. The base SEND spec doesn't include > support for DHCP, since CGAs are autoconfigured, but any spec using certs > should. > > So, given these deployment issues, the SEND WG decided to punt on address > certs for now, until its clear whether people are actually willing to > implement and deploy the technology. The base spec allows address certs, but > it doesn't provide any details about how to use them. Again, if there's > interest, it can be done later. > Thanks for the clarification.. -mohan > jak > > *Small plug for my employer: Docomo runs a PKI called FirstPass that allows > all FOMA hosts to be provisioned with a certificate for bidirectional TLS > authentication. > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jul 13 23:18:54 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05170 for ; Tue, 13 Jul 2004 23:18:53 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6E3ItWR005353 for ; Wed, 14 Jul 2004 05:18:55 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 05:18:54 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3237Q0MF; Wed, 14 Jul 2004 05:18:54 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6E3Iowg007529; Wed, 14 Jul 2004 05:18:50 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6E3HvIt018006; Wed, 14 Jul 2004 05:17:57 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6E3HvCA017971; Wed, 14 Jul 2004 05:17:57 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6E3HsIt017773 for ; Wed, 14 Jul 2004 05:17:55 +0200 (MET DST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LCGBBPFQPI8Y8C5Q@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Wed, 14 Jul 2004 13:17:31 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 49FB3AB542; Wed, 14 Jul 2004 13:17:27 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2FDAC4FB06; Wed, 14 Jul 2004 13:17:27 +1000 (EST) Date: Wed, 14 Jul 2004 13:17:26 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Mohan Parthasarathy Cc: James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F4A5C6.9060606@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> <00af01c46948$f02f4cd0$861167c0@adithya> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 03:18:54.0906 (UTC) FILETIME=[4B4161A0:01C46951] Content-Transfer-Encoding: 7BIT Hi Mohan, Mohan Parthasarathy wrote: > > > >>>>>>I am not sure i understood all of it. A virus infecting a machine that >>>>> >>uses SEND >> >>>>>>can enjoy all the benefits of SEND. How does SEND prevent the virus >>>>> >>from >> >>>>>>spreading ? Perhaps, i am missing something here. >>>>> >>>>>The SEND device which is infected has all of the abilities >>>>>of a SEND node: >>>>> >>>>>It can create neighbour cache entries for itself, and solicit >>>>>others to advertise (that's all). >>>>> >>>>>Compromising a SEND node only allows the SEND node to change >>>>>state related to itself. >>>>> >>>>>If nodes on the link didn't use SEND, a compromised node could >>>>>attack any Neighbour Cache Entry it saw fit by generating bogus >>>>>packets. >>>>> >>>>>The same issue exists for any node compromised when insecure >>>>>proxy ND is available. >>>>> >>>> >>>>Ok. But for this to work, you can't have a mix of SEND and non-SEND >>> >>nodes. >> >>>>I am not sure whether it is realistic to transition completely to SEND. >>> >>>Actually non-send nodes will never see the SEND options, so >>>it may be possible to be backwards compatible with them >>>(as is already done in SEND). >>> >>>The actual resources devoted to non-SEND nodes can be restricted, >>>and the main thing is that SEND advertisements cannot be overwritten >>>with a non-SEND advertisement. >>> >> >> >>Right, I'm not sure exactly what led to that conclusion, Mohan. The SEND >>spec supports both secure and insecure nodes on the same link. A node can be >>configured to accept or reject nonsecured NAs and RAs. If the node rejects >>nonsecured NAs and RAs, then there shouldn't be a problem with proxies if >>they are secured. Am I missing something? >> > > No. But SEND nodes have to accept NAs from non-SEND nodes > in a mixed mode environment. So, it is possible that you receive the > insecure NA, send the queued packet, receive the secure NA, overide the > NCE with information from secure NA. I don't know what that one packet > can do. Anyway, i am a bit confused about how this relates to the original > virus attack that Greg explained.. > Sorry, It seems we've strayed a bit from there. OK. The virus infected machine can transmit both SEND and non-SEND NS or NA's. In some of the most important cases though, existing devices won't believe the non-SEND transmissions from a host. This is because non-SEND NC entries cannnot override SEND NC entries (and are overriden in return), and where no non-SEND host exists, no neighbour cache creation matters unless it is for a SEND host (other creation is just an attempt to steal resources and may be controlled by limiting available resources). Almost no ND hosts will not create a neighbour cache entry from an unsolicited NA. If an uncompromised solicitor transmits a SEND NS, it may accept an NA from an unsecured attacker, but if the SEND host is present on the link, it will receive the NS and respond with a SEND NA almost immediately. Similarly, once an existing SEND neighbour cache entry exists, it cannot be overridden by a non-SEND NC entry. I guess it may be possible to set the NC entry from an unsolicited unsecured NS containing the SLLAO. In this case, the SEND neighbour will attempt to do NS/NA exchange with 5 seconds after packet flow begins on that interface, if the NC entry hasn't been updated to reachable in the interval. When the NS from the SEND node goes out, any existing SEND device which owns this address will crush the attacker's fake NC entry. It may be important to see how such upper-layer confirmations are provided for unsecured NC entries. I'd guess that a SEND node may not believe in upper layer confirmations until it has seen a (real) solicited NA from the unsecured host in response to one of its NS's. I'd have to check the existing SEND draft to see how this is covered... Hmmm. it's not. For the SEND NS/NA transmissions which a compromised device makes, they only refer to itself (as specified but the public key, signature and CGA). >>>>>>I agree that if the enterprise adopts SEND for some reason, then when >>>>> >>it deploys MIP6, >> >>>>>>for the same reason it may also want to secure proxy-ND also. But it >>>>> >>will be >> >>>>>>interesting to see how and when enterprise begins to deploy SEND. >>>>> >>>>>I think that SEND's costs are all to do with authorizing routers >>>>>and configuring hosts to recognize at least one trust anchor. >>>>> >>>>>If an organization can set up certificates for Router Discovery, >>>>>protecting on-link communications using SEND/CGA comes almost >>>>>for free (except managing DNS records). >>>>> >>>> >>>>With the approach that you wrote up in this thread, you need >>> >>certificates >> >>>>for NS/NA also if i am not mistaken. Are there any specific reasons why >>>>current SEND does not use non-CGA approach for NS/NA ? From section 4 >>>>of SEND: >>>> >>>> This specification also allows a node to use non-CGAs with >>>> certificates to authorize their use. However, the details of such >>>> use are beyond the scope of this specification. >>> >>>I think that people were considering what may be necessary in the >>>future (alternative security mechanisms such as ABKs, for example) >>>and also the need for proxying, which was not unheard of at the time. >>> >>>What we need to see is if the security for proxying is needed, >>>particularly that there are valid scenarios where PND needs to >>>be done. >>> >> >>Actually, there are a couple issues with address certificates for hosts: >> >>1) Host certificate provisioning is one of the thorniest issues in IP >>security. In general, it hasn't really proven to be widely deployable, and >>many equate it with the "global PKI" bogie. The solutions (like TLS/SSL) >>that have been widely deployed primarily involve cert provisioning of >>network entities like servers. In the SEND case, the base spec only requires >>the routers to be provisioned. Hosts only need root CA certs. Since there >>are far fewer routers than hosts, ISPs don't have to go the the difficulty >>and expense of running a PKI for all their customers, just for their >>internal equipment.* >> >>2) Even if host certificates were easy to provision, it is not exactly clear >>how one would indicate in the certificate that a particular host is entitled >>to a particular IP address. An extension or something, like the address > > > Hmm.. if i have the right private key, isn't that sufficient that i own the > address on the certificate ? Yes, but how did you get the certificate? universal PKI has a chicken and egg problem. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 00:38:13 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15702 for ; Wed, 14 Jul 2004 00:38:13 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6E4cFAh032549 for ; Wed, 14 Jul 2004 06:38:15 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 06:38:14 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3237RK2Y; Wed, 14 Jul 2004 06:38:14 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6E4c3wg009703; Wed, 14 Jul 2004 06:38:03 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6E4bIIt005196; Wed, 14 Jul 2004 06:37:18 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6E4bIcD005186; Wed, 14 Jul 2004 06:37:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6E4bHIt005134 for ; Wed, 14 Jul 2004 06:37:17 +0200 (MET DST) Received: from kolumbus.fi ([80.186.218.97]) by fep02-app.kolumbus.fi with ESMTP id <20040714043716.KUMU28426.fep02-app.kolumbus.fi@kolumbus.fi>; Wed, 14 Jul 2004 07:37:16 +0300 Message-ID: <40F4B74B.5000303@kolumbus.fi> Date: Wed, 14 Jul 2004 07:32:11 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: James Kempf , ietf-send@standards.ericsson.net Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> <40F481F8.3070806@eng.monash.edu.au> In-Reply-To: <40F481F8.3070806@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 04:38:14.0620 (UTC) FILETIME=[604419C0:01C4695C] Content-Transfer-Encoding: 7bit Greg Daley wrote: > Using CGAs as the start of authority for securing PND seems to be > an appropriate step considering the existing setup in SEND. > certificates prove that the CGA owner (through the included public > key and signature) has delegated its authority itself. > > This removes a requirement for central control of the certificates. > > Does this sound alright to you? This sounds right. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 12:37:02 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27228 for ; Wed, 14 Jul 2004 12:37:02 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6EGb3Ah030419 for ; Wed, 14 Jul 2004 18:37:04 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 18:37:03 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q09CBT; Wed, 14 Jul 2004 18:37:03 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6EGawwg021706; Wed, 14 Jul 2004 18:36:58 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EGa3It018756; Wed, 14 Jul 2004 18:36:04 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6EGa3MX018744; Wed, 14 Jul 2004 18:36:03 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EGZuIt018402 for ; Wed, 14 Jul 2004 18:35:57 +0200 (MET DST) Message-ID: <018501c469c0$be8d8700$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mohan Parthasarathy" , Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> <00af01c46948$f02f4cd0$861167c0@adithya> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Wed, 14 Jul 2004 09:36:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 16:37:03.0227 (UTC) FILETIME=[CAEB44B0:01C469C0] Content-Transfer-Encoding: 7bit > No. But SEND nodes have to accept NAs from non-SEND nodes > in a mixed mode environment. So, it is possible that you receive the > insecure NA, send the queued packet, receive the secure NA, overide the > NCE with information from secure NA. I don't know what that one packet > can do. Anyway, i am a bit confused about how this relates to the original > virus attack that Greg explained.. > OK, I think I understand. You're concerned that a node might first accept an insecure NA from an attacker, then later get a secure NA. I agree that's a problem if acceptance of insecure NAs is turned on, but turning on acceptance is at the option of the user. Regarding Greg's virus attack, I'm not familiar with the details of how ARP spoofing is used, but SEND is designed to counter the threat of ARP spoofing (ND spoofing on IPv6 I guess). jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 13:35:10 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00885 for ; Wed, 14 Jul 2004 13:35:09 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6EHZ9Ah004506 for ; Wed, 14 Jul 2004 19:35:09 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 19:35:09 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32Q09N9Z; Wed, 14 Jul 2004 19:35:08 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6EHZ2wg024612; Wed, 14 Jul 2004 19:35:02 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EHYLIt009772; Wed, 14 Jul 2004 19:34:21 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6EHYL10009765; Wed, 14 Jul 2004 19:34:21 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EHYHIt009643 for ; Wed, 14 Jul 2004 19:34:18 +0200 (MET DST) Message-ID: <024d01c469c8$e55b2d30$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Cc: "Mohan Parthasarathy" , "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> <40F481F8.3070806@eng.monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Wed, 14 Jul 2004 10:35:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 17:35:09.0162 (UTC) FILETIME=[E8B2BCA0:01C469C8] Content-Transfer-Encoding: 7bit Yes, this sounds like a start. Address certs for hosts are a separate issue, also potentially valuable, but not to be confused with PND. It would be useful if whatever mechanism was developed for PND security would cover both CGAs and address certs, as I believe we tried to do with some of the basic mechanisms in the base SEND draft. jak ----- Original Message ----- From: "Greg Daley" To: "James Kempf" Cc: "Mohan Parthasarathy" ; "Vijay Devarapalli" ; "Jean-Michel COMBES" ; ; Sent: Tuesday, July 13, 2004 5:44 PM Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility > Hi James, > > James Kempf wrote: > [chop] > >>>for NS/NA also if i am not mistaken. Are there any specific reasons why > >>>current SEND does not use non-CGA approach for NS/NA ? From section 4 > >>>of SEND: > >>> > >>> This specification also allows a node to use non-CGAs with > >>> certificates to authorize their use. However, the details of such > >>> use are beyond the scope of this specification. > >> > >>I think that people were considering what may be necessary in the > >>future (alternative security mechanisms such as ABKs, for example) > >>and also the need for proxying, which was not unheard of at the time. > >> > >>What we need to see is if the security for proxying is needed, > >>particularly that there are valid scenarios where PND needs to > >>be done. > >> > > > > > > Actually, there are a couple issues with address certificates for hosts: > > > > 1) Host certificate provisioning is one of the thorniest issues in IP > > security. In general, it hasn't really proven to be widely deployable, and > > many equate it with the "global PKI" bogie. The solutions (like TLS/SSL) > > that have been widely deployed primarily involve cert provisioning of > > network entities like servers. In the SEND case, the base spec only requires > > the routers to be provisioned. Hosts only need root CA certs. Since there > > are far fewer routers than hosts, ISPs don't have to go the the difficulty > > and expense of running a PKI for all their customers, just for their > > internal equipment.* > > > > 2) Even if host certificates were easy to provision, it is not exactly clear > > how one would indicate in the certificate that a particular host is entitled > > to a particular IP address. An extension or something, like the address > > prefix extension for routers, would be one way to go. But the extension > > probably wouldn't give the entire address, probably just the MAC address > > used to form the interface identifier (Mobile IP home addresses might be an > > exception). That way, the certificate could be used with a variety of subnet > > prefixes. However, the MAC address isn't controlled by the IETF, and very > > few MAC layers provide such certs (I think Cablelabs and 802.16 do). And, in > > addition, there's DHCP to consider. The base SEND spec doesn't include > > support for DHCP, since CGAs are autoconfigured, but any spec using certs > > should. > > > > So, given these deployment issues, the SEND WG decided to punt on address > > certs for now, until its clear whether people are actually willing to > > implement and deploy the technology. The base spec allows address certs, but > > it doesn't provide any details about how to use them. Again, if there's > > interest, it can be done later. > > Please don't think I'm "teaching you to suck eggs" (instructing > you in what you already know), but just clarifying if we're on the > same path. > > I'd guess that the principle difference is that CGA's provide > sufficient proof of ownership for ND (since we're adjacent to > the device, and the prefix is one of a small set we're interested > in). > > In proxy neighbour discovery the assumption is modified a little, > allowing devices which aren't present to be advertised, but only > through a currently existing local SEND node. > > Using CGAs as the start of authority for securing PND seems to be > an appropriate step considering the existing setup in SEND. > certificates prove that the CGA owner (through the included public > key and signature) has delegated its authority itself. > > This removes a requirement for central control of the certificates. > > Does this sound alright to you? > > > > jak > > > > *Small plug for my employer: Docomo runs a PKI called FirstPass that allows > > all FOMA hosts to be provisioned with a certificate for bidirectional TLS > > authentication. > > > > > we know who to address all the PKI questions to then.... > > Greg > > > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 13:38:48 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00982 for ; Wed, 14 Jul 2004 13:38:47 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6EHclPA021815 for ; Wed, 14 Jul 2004 19:38:47 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 19:38:46 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321MXMGZ; Wed, 14 Jul 2004 19:38:46 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6EHciXA010816; Wed, 14 Jul 2004 19:38:44 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EHcIIt020154; Wed, 14 Jul 2004 19:38:18 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6EHcIm3020137; Wed, 14 Jul 2004 19:38:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EHcGIt020022 for ; Wed, 14 Jul 2004 19:38:16 +0200 (MET DST) Message-ID: <026101c469c9$73790330$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Mohan Parthasarathy" Cc: "Vijay Devarapalli" , "Jean-Michel COMBES" , , References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> <00af01c46948$f02f4cd0$861167c0@adithya> <40F4A5C6.9060606@eng.monash.edu.au> Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility Date: Wed, 14 Jul 2004 10:38:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 17:38:46.0465 (UTC) FILETIME=[6A388B10:01C469C9] Content-Transfer-Encoding: 7bit Greg, The draft is currently in revision based on IESG feedback. If you want to raise an issue about upper layer confirmation, now's the time to do it. If you do, please give very specific text describing how to handle it and where in the draft the text should be inserted. Random discussion on the issue isn't what we need right now. Thanx. jak ----- Original Message ----- From: "Greg Daley" To: "Mohan Parthasarathy" Cc: "James Kempf" ; "Vijay Devarapalli" ; "Jean-Michel COMBES" ; ; Sent: Tuesday, July 13, 2004 8:17 PM Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility > Hi Mohan, > > Mohan Parthasarathy wrote: > > > > > > > >>>>>>I am not sure i understood all of it. A virus infecting a machine that > >>>>> > >>uses SEND > >> > >>>>>>can enjoy all the benefits of SEND. How does SEND prevent the virus > >>>>> > >>from > >> > >>>>>>spreading ? Perhaps, i am missing something here. > >>>>> > >>>>>The SEND device which is infected has all of the abilities > >>>>>of a SEND node: > >>>>> > >>>>>It can create neighbour cache entries for itself, and solicit > >>>>>others to advertise (that's all). > >>>>> > >>>>>Compromising a SEND node only allows the SEND node to change > >>>>>state related to itself. > >>>>> > >>>>>If nodes on the link didn't use SEND, a compromised node could > >>>>>attack any Neighbour Cache Entry it saw fit by generating bogus > >>>>>packets. > >>>>> > >>>>>The same issue exists for any node compromised when insecure > >>>>>proxy ND is available. > >>>>> > >>>> > >>>>Ok. But for this to work, you can't have a mix of SEND and non-SEND > >>> > >>nodes. > >> > >>>>I am not sure whether it is realistic to transition completely to SEND. > >>> > >>>Actually non-send nodes will never see the SEND options, so > >>>it may be possible to be backwards compatible with them > >>>(as is already done in SEND). > >>> > >>>The actual resources devoted to non-SEND nodes can be restricted, > >>>and the main thing is that SEND advertisements cannot be overwritten > >>>with a non-SEND advertisement. > >>> > >> > >> > >>Right, I'm not sure exactly what led to that conclusion, Mohan. The SEND > >>spec supports both secure and insecure nodes on the same link. A node can be > >>configured to accept or reject nonsecured NAs and RAs. If the node rejects > >>nonsecured NAs and RAs, then there shouldn't be a problem with proxies if > >>they are secured. Am I missing something? > >> > > > > No. But SEND nodes have to accept NAs from non-SEND nodes > > in a mixed mode environment. So, it is possible that you receive the > > insecure NA, send the queued packet, receive the secure NA, overide the > > NCE with information from secure NA. I don't know what that one packet > > can do. Anyway, i am a bit confused about how this relates to the original > > virus attack that Greg explained.. > > > > Sorry, It seems we've strayed a bit from there. > > OK. The virus infected machine can transmit both SEND and non-SEND > NS or NA's. In some of the most important cases though, existing > devices won't believe the non-SEND transmissions from a host. > > This is because non-SEND NC entries cannnot override SEND NC entries > (and are overriden in return), and where no non-SEND host exists, > no neighbour cache creation matters unless it is for a SEND host > (other creation is just an attempt to steal resources and may be > controlled by limiting available resources). > > > Almost no ND hosts will not create a neighbour cache entry from > an unsolicited NA. > > If an uncompromised solicitor transmits a SEND NS, it may accept > an NA from an unsecured attacker, but if the SEND host is present > on the link, it will receive the NS and respond with a SEND NA > almost immediately. > > Similarly, once an existing SEND neighbour cache entry exists, > it cannot be overridden by a non-SEND NC entry. > > I guess it may be possible to set the NC entry from an unsolicited > unsecured NS containing the SLLAO. In this case, the SEND neighbour > will attempt to do NS/NA exchange with 5 seconds after packet > flow begins on that interface, if the NC entry hasn't been updated to > reachable in the interval. When the NS from the SEND node goes out, > any existing SEND device which owns this address will crush the > attacker's fake NC entry. > > It may be important to see how such upper-layer confirmations are > provided for unsecured NC entries. I'd guess that a SEND node may > not believe in upper layer confirmations until it has seen a > (real) solicited NA from the unsecured host in response to one of > its NS's. > > I'd have to check the existing SEND draft to see how this is covered... > Hmmm. it's not. > > For the SEND NS/NA transmissions which a compromised device makes, > they only refer to itself (as specified but the public key, signature > and CGA). > > > >>>>>>I agree that if the enterprise adopts SEND for some reason, then when > >>>>> > >>it deploys MIP6, > >> > >>>>>>for the same reason it may also want to secure proxy-ND also. But it > >>>>> > >>will be > >> > >>>>>>interesting to see how and when enterprise begins to deploy SEND. > >>>>> > >>>>>I think that SEND's costs are all to do with authorizing routers > >>>>>and configuring hosts to recognize at least one trust anchor. > >>>>> > >>>>>If an organization can set up certificates for Router Discovery, > >>>>>protecting on-link communications using SEND/CGA comes almost > >>>>>for free (except managing DNS records). > >>>>> > >>>> > >>>>With the approach that you wrote up in this thread, you need > >>> > >>certificates > >> > >>>>for NS/NA also if i am not mistaken. Are there any specific reasons why > >>>>current SEND does not use non-CGA approach for NS/NA ? From section 4 > >>>>of SEND: > >>>> > >>>> This specification also allows a node to use non-CGAs with > >>>> certificates to authorize their use. However, the details of such > >>>> use are beyond the scope of this specification. > >>> > >>>I think that people were considering what may be necessary in the > >>>future (alternative security mechanisms such as ABKs, for example) > >>>and also the need for proxying, which was not unheard of at the time. > >>> > >>>What we need to see is if the security for proxying is needed, > >>>particularly that there are valid scenarios where PND needs to > >>>be done. > >>> > >> > >>Actually, there are a couple issues with address certificates for hosts: > >> > >>1) Host certificate provisioning is one of the thorniest issues in IP > >>security. In general, it hasn't really proven to be widely deployable, and > >>many equate it with the "global PKI" bogie. The solutions (like TLS/SSL) > >>that have been widely deployed primarily involve cert provisioning of > >>network entities like servers. In the SEND case, the base spec only requires > >>the routers to be provisioned. Hosts only need root CA certs. Since there > >>are far fewer routers than hosts, ISPs don't have to go the the difficulty > >>and expense of running a PKI for all their customers, just for their > >>internal equipment.* > >> > >>2) Even if host certificates were easy to provision, it is not exactly clear > >>how one would indicate in the certificate that a particular host is entitled > >>to a particular IP address. An extension or something, like the address > > > > > > Hmm.. if i have the right private key, isn't that sufficient that i own the > > address on the certificate ? > > Yes, but how did you get the certificate? > > universal PKI has a chicken and egg problem. > > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 16:38:57 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17390 for ; Wed, 14 Jul 2004 16:38:55 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6EKcsAh017923 for ; Wed, 14 Jul 2004 22:38:54 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 22:38:54 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321MYHSH; Wed, 14 Jul 2004 22:38:54 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6EKccwg003067; Wed, 14 Jul 2004 22:38:38 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EKbfIt023121; Wed, 14 Jul 2004 22:37:41 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6EKbetr023108; Wed, 14 Jul 2004 22:37:40 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EKbaIt022822 for ; Wed, 14 Jul 2004 22:37:37 +0200 (MET DST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6EKbIO10991; Wed, 14 Jul 2004 13:37:18 -0700 X-mProtect: <200407142037> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKG4JM3; Wed, 14 Jul 2004 13:37:16 PDT Message-ID: <40F59985.3040706@iprg.nokia.com> Date: Wed, 14 Jul 2004 13:37:25 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: Mohan Parthasarathy , James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomola Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 20:38:54.0517 (UTC) FILETIME=[94526650:01C469E2] Content-Transfer-Encoding: 7bit Based on my loose interpretation of these discussions, it seems as if an unsolicited SEND NA might be useful as an authenticated mechansim for informing a neighbor of an L2 address change. Is my understanding correct on this? Thanks - Fred ftemplin@iprg.nokia.com Greg Daley wrote: > Hi Mohan, > > Mohan Parthasarathy wrote: > >> >> >> >>>>>>> I am not sure i understood all of it. A virus infecting a >>>>>>> machine that >>>>>> >>>>>> >>> uses SEND >>> >>>>>>> can enjoy all the benefits of SEND. How does SEND prevent the virus >>>>>> >>>>>> >>> from >>> >>>>>>> spreading ? Perhaps, i am missing something here. >>>>>> >>>>>> >>>>>> The SEND device which is infected has all of the abilities >>>>>> of a SEND node: >>>>>> >>>>>> It can create neighbour cache entries for itself, and solicit >>>>>> others to advertise (that's all). >>>>>> >>>>>> Compromising a SEND node only allows the SEND node to change >>>>>> state related to itself. >>>>>> >>>>>> If nodes on the link didn't use SEND, a compromised node could >>>>>> attack any Neighbour Cache Entry it saw fit by generating bogus >>>>>> packets. >>>>>> >>>>>> The same issue exists for any node compromised when insecure >>>>>> proxy ND is available. >>>>>> >>>>> >>>>> Ok. But for this to work, you can't have a mix of SEND and non-SEND >>>> >>>> >>> nodes. >>> >>>>> I am not sure whether it is realistic to transition completely to >>>>> SEND. >>>> >>>> >>>> Actually non-send nodes will never see the SEND options, so >>>> it may be possible to be backwards compatible with them >>>> (as is already done in SEND). >>>> >>>> The actual resources devoted to non-SEND nodes can be restricted, >>>> and the main thing is that SEND advertisements cannot be overwritten >>>> with a non-SEND advertisement. >>>> >>> >>> >>> Right, I'm not sure exactly what led to that conclusion, Mohan. The >>> SEND >>> spec supports both secure and insecure nodes on the same link. A >>> node can be >>> configured to accept or reject nonsecured NAs and RAs. If the node >>> rejects >>> nonsecured NAs and RAs, then there shouldn't be a problem with >>> proxies if >>> they are secured. Am I missing something? >>> >> >> No. But SEND nodes have to accept NAs from non-SEND nodes >> in a mixed mode environment. So, it is possible that you receive the >> insecure NA, send the queued packet, receive the secure NA, overide the >> NCE with information from secure NA. I don't know what that one packet >> can do. Anyway, i am a bit confused about how this relates to the >> original >> virus attack that Greg explained.. >> > > Sorry, It seems we've strayed a bit from there. > > OK. The virus infected machine can transmit both SEND and non-SEND > NS or NA's. In some of the most important cases though, existing > devices won't believe the non-SEND transmissions from a host. > > This is because non-SEND NC entries cannnot override SEND NC entries > (and are overriden in return), and where no non-SEND host exists, > no neighbour cache creation matters unless it is for a SEND host > (other creation is just an attempt to steal resources and may be > controlled by limiting available resources). > > > Almost no ND hosts will not create a neighbour cache entry from > an unsolicited NA. > > If an uncompromised solicitor transmits a SEND NS, it may accept > an NA from an unsecured attacker, but if the SEND host is present > on the link, it will receive the NS and respond with a SEND NA > almost immediately. > > Similarly, once an existing SEND neighbour cache entry exists, > it cannot be overridden by a non-SEND NC entry. > > I guess it may be possible to set the NC entry from an unsolicited > unsecured NS containing the SLLAO. In this case, the SEND neighbour > will attempt to do NS/NA exchange with 5 seconds after packet > flow begins on that interface, if the NC entry hasn't been updated to > reachable in the interval. When the NS from the SEND node goes out, > any existing SEND device which owns this address will crush the > attacker's fake NC entry. > > It may be important to see how such upper-layer confirmations are > provided for unsecured NC entries. I'd guess that a SEND node may > not believe in upper layer confirmations until it has seen a > (real) solicited NA from the unsecured host in response to one of > its NS's. > > I'd have to check the existing SEND draft to see how this is covered... > Hmmm. it's not. > > For the SEND NS/NA transmissions which a compromised device makes, > they only refer to itself (as specified but the public key, signature > and CGA). > > >>>>>>> I agree that if the enterprise adopts SEND for some reason, then >>>>>>> when >>>>>> >>>>>> >>> it deploys MIP6, >>> >>>>>>> for the same reason it may also want to secure proxy-ND also. >>>>>>> But it >>>>>> >>>>>> >>> will be >>> >>>>>>> interesting to see how and when enterprise begins to deploy SEND. >>>>>> >>>>>> >>>>>> I think that SEND's costs are all to do with authorizing routers >>>>>> and configuring hosts to recognize at least one trust anchor. >>>>>> >>>>>> If an organization can set up certificates for Router Discovery, >>>>>> protecting on-link communications using SEND/CGA comes almost >>>>>> for free (except managing DNS records). >>>>>> >>>>> >>>>> With the approach that you wrote up in this thread, you need >>>> >>>> >>> certificates >>> >>>>> for NS/NA also if i am not mistaken. Are there any specific >>>>> reasons why >>>>> current SEND does not use non-CGA approach for NS/NA ? From section 4 >>>>> of SEND: >>>>> >>>>> This specification also allows a node to use non-CGAs with >>>>> certificates to authorize their use. However, the details of >>>>> such >>>>> use are beyond the scope of this specification. >>>> >>>> >>>> I think that people were considering what may be necessary in the >>>> future (alternative security mechanisms such as ABKs, for example) >>>> and also the need for proxying, which was not unheard of at the time. >>>> >>>> What we need to see is if the security for proxying is needed, >>>> particularly that there are valid scenarios where PND needs to >>>> be done. >>>> >>> >>> Actually, there are a couple issues with address certificates for >>> hosts: >>> >>> 1) Host certificate provisioning is one of the thorniest issues in IP >>> security. In general, it hasn't really proven to be widely >>> deployable, and >>> many equate it with the "global PKI" bogie. The solutions (like >>> TLS/SSL) >>> that have been widely deployed primarily involve cert provisioning of >>> network entities like servers. In the SEND case, the base spec only >>> requires >>> the routers to be provisioned. Hosts only need root CA certs. Since >>> there >>> are far fewer routers than hosts, ISPs don't have to go the the >>> difficulty >>> and expense of running a PKI for all their customers, just for their >>> internal equipment.* >>> >>> 2) Even if host certificates were easy to provision, it is not >>> exactly clear >>> how one would indicate in the certificate that a particular host is >>> entitled >>> to a particular IP address. An extension or something, like the address >> >> >> >> Hmm.. if i have the right private key, isn't that sufficient that i >> own the >> address on the certificate ? > > > Yes, but how did you get the certificate? > > universal PKI has a chicken and egg problem. > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 16:57:38 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19941 for ; Wed, 14 Jul 2004 16:57:37 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6EKvbWR009060 for ; Wed, 14 Jul 2004 22:57:37 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 22:57:37 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3237YNGW; Wed, 14 Jul 2004 22:57:36 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6EKvZXA012840; Wed, 14 Jul 2004 22:57:35 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EKv7It023254; Wed, 14 Jul 2004 22:57:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6EKv7av023245; Wed, 14 Jul 2004 22:57:07 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6EKv3It023082 for ; Wed, 14 Jul 2004 22:57:04 +0200 (MET DST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6EKuqH09133; Wed, 14 Jul 2004 13:56:52 -0700 X-mProtect: <200407142056> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHnwsve; Wed, 14 Jul 2004 13:56:49 PDT Message-ID: <40F59E1A.9050704@iprg.nokia.com> Date: Wed, 14 Jul 2004 13:56:58 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin CC: greg.daley@eng.monash.edu.au, Mohan Parthasarathy , James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomola Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Jul 2004 20:57:37.0127 (UTC) FILETIME=[31731770:01C469E5] Content-Transfer-Encoding: 7bit Hmm... I guess for routers, an unsolicited SEND RA with an SLLAO and sent to an IPv6 unicast address will do pretty much the same thing - right? I guess I'd better go off and take a closer look at the specs now... Fred ftemplin@iprg.nokia.com Fred Templin wrote: > Based on my loose interpretation of these discussions, it seems as > if an unsolicited SEND NA might be useful as an authenticated > mechansim for informing a neighbor of an L2 address change. > Is my understanding correct on this? > > Thanks - Fred > ftemplin@iprg.nokia.com > > Greg Daley wrote: > >> Hi Mohan, >> >> Mohan Parthasarathy wrote: >> >>> >>> >>> >>>>>>>> I am not sure i understood all of it. A virus infecting a >>>>>>>> machine that >>>>>>> >>>>>>> >>>>>>> >>>> uses SEND >>>> >>>>>>>> can enjoy all the benefits of SEND. How does SEND prevent the >>>>>>>> virus >>>>>>> >>>>>>> >>>>>>> >>>> from >>>> >>>>>>>> spreading ? Perhaps, i am missing something here. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The SEND device which is infected has all of the abilities >>>>>>> of a SEND node: >>>>>>> >>>>>>> It can create neighbour cache entries for itself, and solicit >>>>>>> others to advertise (that's all). >>>>>>> >>>>>>> Compromising a SEND node only allows the SEND node to change >>>>>>> state related to itself. >>>>>>> >>>>>>> If nodes on the link didn't use SEND, a compromised node could >>>>>>> attack any Neighbour Cache Entry it saw fit by generating bogus >>>>>>> packets. >>>>>>> >>>>>>> The same issue exists for any node compromised when insecure >>>>>>> proxy ND is available. >>>>>>> >>>>>> >>>>>> Ok. But for this to work, you can't have a mix of SEND and non-SEND >>>>> >>>>> >>>>> >>>> nodes. >>>> >>>>>> I am not sure whether it is realistic to transition completely to >>>>>> SEND. >>>>> >>>>> >>>>> >>>>> Actually non-send nodes will never see the SEND options, so >>>>> it may be possible to be backwards compatible with them >>>>> (as is already done in SEND). >>>>> >>>>> The actual resources devoted to non-SEND nodes can be restricted, >>>>> and the main thing is that SEND advertisements cannot be overwritten >>>>> with a non-SEND advertisement. >>>>> >>>> >>>> >>>> Right, I'm not sure exactly what led to that conclusion, Mohan. The >>>> SEND >>>> spec supports both secure and insecure nodes on the same link. A >>>> node can be >>>> configured to accept or reject nonsecured NAs and RAs. If the node >>>> rejects >>>> nonsecured NAs and RAs, then there shouldn't be a problem with >>>> proxies if >>>> they are secured. Am I missing something? >>>> >>> >>> No. But SEND nodes have to accept NAs from non-SEND nodes >>> in a mixed mode environment. So, it is possible that you receive the >>> insecure NA, send the queued packet, receive the secure NA, overide the >>> NCE with information from secure NA. I don't know what that one packet >>> can do. Anyway, i am a bit confused about how this relates to the >>> original >>> virus attack that Greg explained.. >>> >> >> Sorry, It seems we've strayed a bit from there. >> >> OK. The virus infected machine can transmit both SEND and non-SEND >> NS or NA's. In some of the most important cases though, existing >> devices won't believe the non-SEND transmissions from a host. >> >> This is because non-SEND NC entries cannnot override SEND NC entries >> (and are overriden in return), and where no non-SEND host exists, >> no neighbour cache creation matters unless it is for a SEND host >> (other creation is just an attempt to steal resources and may be >> controlled by limiting available resources). >> >> >> Almost no ND hosts will not create a neighbour cache entry from >> an unsolicited NA. >> >> If an uncompromised solicitor transmits a SEND NS, it may accept >> an NA from an unsecured attacker, but if the SEND host is present >> on the link, it will receive the NS and respond with a SEND NA >> almost immediately. >> >> Similarly, once an existing SEND neighbour cache entry exists, >> it cannot be overridden by a non-SEND NC entry. >> >> I guess it may be possible to set the NC entry from an unsolicited >> unsecured NS containing the SLLAO. In this case, the SEND neighbour >> will attempt to do NS/NA exchange with 5 seconds after packet >> flow begins on that interface, if the NC entry hasn't been updated to >> reachable in the interval. When the NS from the SEND node goes out, >> any existing SEND device which owns this address will crush the >> attacker's fake NC entry. >> >> It may be important to see how such upper-layer confirmations are >> provided for unsecured NC entries. I'd guess that a SEND node may >> not believe in upper layer confirmations until it has seen a >> (real) solicited NA from the unsecured host in response to one of >> its NS's. >> >> I'd have to check the existing SEND draft to see how this is covered... >> Hmmm. it's not. >> >> For the SEND NS/NA transmissions which a compromised device makes, >> they only refer to itself (as specified but the public key, signature >> and CGA). >> >> >>>>>>>> I agree that if the enterprise adopts SEND for some reason, >>>>>>>> then when >>>>>>> >>>>>>> >>>>>>> >>>> it deploys MIP6, >>>> >>>>>>>> for the same reason it may also want to secure proxy-ND also. >>>>>>>> But it >>>>>>> >>>>>>> >>>>>>> >>>> will be >>>> >>>>>>>> interesting to see how and when enterprise begins to deploy SEND. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think that SEND's costs are all to do with authorizing routers >>>>>>> and configuring hosts to recognize at least one trust anchor. >>>>>>> >>>>>>> If an organization can set up certificates for Router Discovery, >>>>>>> protecting on-link communications using SEND/CGA comes almost >>>>>>> for free (except managing DNS records). >>>>>>> >>>>>> >>>>>> With the approach that you wrote up in this thread, you need >>>>> >>>>> >>>>> >>>> certificates >>>> >>>>>> for NS/NA also if i am not mistaken. Are there any specific >>>>>> reasons why >>>>>> current SEND does not use non-CGA approach for NS/NA ? From >>>>>> section 4 >>>>>> of SEND: >>>>>> >>>>>> This specification also allows a node to use non-CGAs with >>>>>> certificates to authorize their use. However, the details >>>>>> of such >>>>>> use are beyond the scope of this specification. >>>>> >>>>> >>>>> >>>>> I think that people were considering what may be necessary in the >>>>> future (alternative security mechanisms such as ABKs, for example) >>>>> and also the need for proxying, which was not unheard of at the time. >>>>> >>>>> What we need to see is if the security for proxying is needed, >>>>> particularly that there are valid scenarios where PND needs to >>>>> be done. >>>>> >>>> >>>> Actually, there are a couple issues with address certificates for >>>> hosts: >>>> >>>> 1) Host certificate provisioning is one of the thorniest issues in IP >>>> security. In general, it hasn't really proven to be widely >>>> deployable, and >>>> many equate it with the "global PKI" bogie. The solutions (like >>>> TLS/SSL) >>>> that have been widely deployed primarily involve cert provisioning of >>>> network entities like servers. In the SEND case, the base spec only >>>> requires >>>> the routers to be provisioned. Hosts only need root CA certs. Since >>>> there >>>> are far fewer routers than hosts, ISPs don't have to go the the >>>> difficulty >>>> and expense of running a PKI for all their customers, just for their >>>> internal equipment.* >>>> >>>> 2) Even if host certificates were easy to provision, it is not >>>> exactly clear >>>> how one would indicate in the certificate that a particular host is >>>> entitled >>>> to a particular IP address. An extension or something, like the >>>> address >>> >>> >>> >>> >>> Hmm.. if i have the right private key, isn't that sufficient that i >>> own the >>> address on the certificate ? >> >> >> >> Yes, but how did you get the certificate? >> >> universal PKI has a chicken and egg problem. >> >> >> -------------------------------------------------------------------- >> To unsubscribe from this list, send email with "UNSUBSCRIBE" in the >> body to . >> Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html >> -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 21:40:36 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28781 for ; Wed, 14 Jul 2004 21:40:35 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6F1eZPA029496 for ; Thu, 15 Jul 2004 03:40:36 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 03:40:35 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4WCCMM; Thu, 15 Jul 2004 03:40:35 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6F1eYXA015110; Thu, 15 Jul 2004 03:40:34 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F1dUIt017515; Thu, 15 Jul 2004 03:39:30 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6F1dUg2017493; Thu, 15 Jul 2004 03:39:30 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F1dRIt017273 for ; Thu, 15 Jul 2004 03:39:28 +0200 (MET DST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCHM25JHJK8Y5WZT@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 15 Jul 2004 11:35:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3D4F3AB543 for ; Thu, 15 Jul 2004 11:35:07 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1D9074FB10 for ; Thu, 15 Jul 2004 11:35:07 +1000 (EST) Date: Thu, 15 Jul 2004 11:35:06 +1000 From: Greg Daley Subject: Creating a valid neighbour cache entry with an unsecured NS? To: ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F5DF4A.2080109@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 01:40:35.0476 (UTC) FILETIME=[B9558D40:01C46A0C] Content-Transfer-Encoding: 7BIT Hi In conversation with Mohan and James, I think I found an issue which is not sufficiently covered in the base SEND draft. Perhaps this is too late or not a major problem, but here's a rundown: Where SEND nodes provide backward compatability with non-SEND nodes, it may be possible for a non-SEND attacker to create a new neighbour cache entry on a victim SEND node for a legitimate third party which also uses SEND. In order for such an attack to occur, the SEND host must have no SEND neighbour cache state for the third node, and therefore has no existing data traffic. The attacking node sends a solicitation message including a Source Link-layer Address option to the victim, purporting to be the third party. This creates a neighbour cache entry in the STALE state, which can be used for up to five seconds before invoking neighbour unreachability detection. While SEND messaging from the third party will override is neighbour cache entry, upper layer confirmation for the communication can be used to extend the lifetime of the attack. Here is some text to cover the issue: (not sure about SHOULD NOT or MUST NOT for the second case.) " ... * Neighbor Solicitations for the purpose of Neighbor Unreachabilty Detection (NUD) MUST be sent to that neighbor's solicited-nodes multicast address, if the entry is not secured with SEND. * Upper layer confirmations on unsecured neighbor cache entries SHOULD NOT update neighbor cache state from STALE to REACHABLE on a SEND node. This ensures that if an entry spoofing a valid SEND host is created by a non-SEND attacker without being solicited, NUD will always be done within 5 seconds of use of the entry for data transmission. ..." I think this would fit section 8 after the dot point: * The Neighbor Cache, Prefix List and Default Router list entries MUST have a secured/insecure flag that indicates whether the message that caused the creation or last update of the entry was secured or insecure. Received insecure messages MUST NOT cause changes to existing secured entries in the Neighbor Cache, Prefix List or Default Router List. The Neighbor Cache SHOULD implement a flag on entries indicating whether the entry is secured. Received secured messages MUST cause an update of the matching entries and flagging of them as secured. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 23:04:41 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04107 for ; Wed, 14 Jul 2004 23:04:41 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6F34gAh011228 for ; Thu, 15 Jul 2004 05:04:42 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 05:04:42 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4WCNKX; Thu, 15 Jul 2004 05:04:42 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6F34Ywg015991; Thu, 15 Jul 2004 05:04:34 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F33jIt025619; Thu, 15 Jul 2004 05:03:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6F33jUR025606; Thu, 15 Jul 2004 05:03:45 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F33hIt025455 for ; Thu, 15 Jul 2004 05:03:43 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCHP41JXPA8Y5KQS@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 15 Jul 2004 13:02:56 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0517880033; Thu, 15 Jul 2004 13:02:56 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id DEDD63C00E; Thu, 15 Jul 2004 13:02:55 +1000 (EST) Date: Thu, 15 Jul 2004 13:02:55 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Fred Templin Cc: Mohan Parthasarathy , James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F5F3DF.3010404@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <40F59985.3040706@iprg.nokia.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 03:04:42.0282 (UTC) FILETIME=[797708A0:01C46A18] Content-Transfer-Encoding: 7BIT Hi Fred Fred Templin wrote: > Based on my loose interpretation of these discussions, it seems as > if an unsolicited SEND NA might be useful as an authenticated > mechansim for informing a neighbor of an L2 address change. > Is my understanding correct on this? Yes, although it will only update existing NC entries. Where unsolicited NAs are multicast, they'll update any of the neighbour cache entries for hosts where they're received, if they have enough SEND foo to do so. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 14 23:12:02 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04302 for ; Wed, 14 Jul 2004 23:12:01 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6F3C1WR014700 for ; Thu, 15 Jul 2004 05:12:02 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 05:12:01 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3237Z4LN; Thu, 15 Jul 2004 05:12:01 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6F3Bxwg016220; Thu, 15 Jul 2004 05:11:59 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F3BgIt022746; Thu, 15 Jul 2004 05:11:42 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6F3Bf9w022739; Thu, 15 Jul 2004 05:11:41 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F3BdIt022571 for ; Thu, 15 Jul 2004 05:11:40 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCHPBEHTHE8WW9BS@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 15 Jul 2004 13:08:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0495C80033; Thu, 15 Jul 2004 13:08:52 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id D92023C003; Thu, 15 Jul 2004 13:08:51 +1000 (EST) Date: Thu, 15 Jul 2004 13:08:51 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Fred Templin Cc: Mohan Parthasarathy , James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F5F543.2010704@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <40F59E1A.9050704@iprg.nokia.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 03:12:01.0538 (UTC) FILETIME=[7F482E20:01C46A19] Content-Transfer-Encoding: 7BIT Hi Fred, Fred Templin wrote: > Hmm... I guess for routers, an unsolicited SEND RA with > an SLLAO and sent to an IPv6 unicast address will do > pretty much the same thing - right? I guess I'd better > go off and take a closer look at the specs now... Yes, the routers will probably do unsolicited RAs anyway though. The difference between the unsolicited NA and the unsolicited RA is that hosts will probably create a neighbour cache entry for the unsolicited RA, whereas only existing NCEs will be updated with the unsolicited NA. If we're talking proxyND, the unsolicited NA (override flag set) should do the trick if there's been a link-layer change caused by a node moving away, or the proxy being changed. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 15 00:46:19 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08614 for ; Thu, 15 Jul 2004 00:46:18 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6F4kGWR024252 for ; Thu, 15 Jul 2004 06:46:20 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 06:46:16 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3237Z0DS; Thu, 15 Jul 2004 06:46:16 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6F4kFXA016455; Thu, 15 Jul 2004 06:46:15 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F4jGIt026392; Thu, 15 Jul 2004 06:45:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6F4jFpt026371; Thu, 15 Jul 2004 06:45:15 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep32-app.kolumbus.fi (fep32-0.kolumbus.fi [193.229.0.63]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F4jEIt026148 for ; Thu, 15 Jul 2004 06:45:14 +0200 (MET DST) Received: from kolumbus.fi ([80.186.218.97]) by fep32-app.kolumbus.fi with ESMTP id <20040715044512.TUKM21628.fep32-app.kolumbus.fi@kolumbus.fi>; Thu, 15 Jul 2004 07:45:12 +0300 Message-ID: <40F60AA1.1070102@kolumbus.fi> Date: Thu, 15 Jul 2004 07:40:01 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: ietf-send@standards.ericsson.net Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? References: <40F5DF4A.2080109@eng.monash.edu.au> In-Reply-To: <40F5DF4A.2080109@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 04:46:16.0297 (UTC) FILETIME=[A9C7ED90:01C46A26] Content-Transfer-Encoding: 7bit Greg Daley wrote: > Where SEND nodes provide backward compatability with > non-SEND nodes, it may be possible for a non-SEND attacker > to create a new neighbour cache entry on a victim SEND node > for a legitimate third party which also uses SEND. > In order for such an attack to occur, the SEND host > must have no SEND neighbour cache state for the third > node, and therefore has no existing data traffic. > The attacking node sends a solicitation message including > a Source Link-layer Address option to the > victim, purporting to be the third party. > This creates a neighbour cache entry in the STALE state, > which can be used for up to five seconds before > invoking neighbour unreachability detection. This is correct. > While SEND messaging from the third party will override > is neighbour cache entry, upper layer confirmation > for the communication can be used to extend the lifetime > of the attack. This is true as well. I think the real question is if we consider this as an attack, given that the third party did not actually want to communicate with our victim node. I guess the answer is "yes", because the victim is still fooled into believing the third party contacted it. For instance, my server could be fooled into believing that my laptop contacted it whereas in reality the laptop did not have a need to contact the server and the communications actually came from an attacker. > Here is some text to cover the issue: > > (not sure about SHOULD NOT or MUST NOT for the second case.) > > " > ... > > * Neighbor Solicitations for the purpose of Neighbor > Unreachabilty Detection (NUD) MUST be sent to that > neighbor's solicited-nodes multicast address, if the > entry is not secured with SEND. Ok. > * Upper layer confirmations on unsecured neighbor cache entries > SHOULD NOT update neighbor cache state from STALE to REACHABLE > on a SEND node. This ensures that if an entry spoofing a valid > SEND host is created by a non-SEND attacker without being > solicited, NUD will always be done within 5 seconds of use of > the entry for data transmission. This sounds OK too, although I do worry about the performance impact to SEND nodes who are communicating with non-SEND nodes. They'll be doing NUD all the time. Is this a problem? --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 15 01:19:17 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10233 for ; Thu, 15 Jul 2004 01:19:17 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6F5JGPA022069 for ; Thu, 15 Jul 2004 07:19:16 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 07:19:15 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4WC7PG; Thu, 15 Jul 2004 07:19:15 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6F5JCwg020326; Thu, 15 Jul 2004 07:19:12 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F5IWIt002357; Thu, 15 Jul 2004 07:18:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6F5IW4U002342; Thu, 15 Jul 2004 07:18:32 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F5ITIt002230 for ; Thu, 15 Jul 2004 07:18:30 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LCHJF5YSW28WY7YP@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 15 Jul 2004 10:20:09 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 22FF380033; Thu, 15 Jul 2004 10:20:06 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id F0F1B3C00C; Thu, 15 Jul 2004 10:20:05 +1000 (EST) Date: Thu, 15 Jul 2004 10:20:05 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: James Kempf Cc: Mohan Parthasarathy , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F5CDB5.9000308@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <00ba01c468f2$a74aad80$536115ac@dcml.docomolabsusa.com> <00af01c46948$f02f4cd0$861167c0@adithya> <40F4A5C6.9060606@eng.monash.edu.au> <026101c469c9$73790330$536115ac@dcml.docomolabsusa.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 05:19:15.0885 (UTC) FILETIME=[45B515D0:01C46A2B] Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > Greg, > > The draft is currently in revision based on IESG feedback. If you want to > raise an issue about upper layer confirmation, now's the time to do it. If > you do, please give very specific text describing how to handle it and where > in the draft the text should be inserted. Random discussion on the issue > isn't what we need right now. I understand, but haven't read through the latest draft (pre-06) in depth yet. I'll try to get text if there's a good space for it. (the randomness comes easier at first. In fact I only thought of the issue as I was composing the e-mail). Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 15 01:43:01 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11792 for ; Thu, 15 Jul 2004 01:43:00 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6F5glPA024963 for ; Thu, 15 Jul 2004 07:42:48 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 07:42:46 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32375GTQ; Thu, 15 Jul 2004 07:42:46 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6F5gjXA016846; Thu, 15 Jul 2004 07:42:45 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F5g9It010322; Thu, 15 Jul 2004 07:42:09 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6F5g9xu010314; Thu, 15 Jul 2004 07:42:09 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6F5g6It010149 for ; Thu, 15 Jul 2004 07:42:06 +0200 (MET DST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LCHUMD6XRM8WY9P8@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 15 Jul 2004 15:40:29 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CF3D3AB543; Thu, 15 Jul 2004 15:40:28 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id B33B84FB07; Thu, 15 Jul 2004 15:40:28 +1000 (EST) Date: Thu, 15 Jul 2004 15:40:28 +1000 From: Greg Daley Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? To: Jari Arkko Cc: ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F618CC.2010704@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 05:42:46.0950 (UTC) FILETIME=[8EC48460:01C46A2E] Content-Transfer-Encoding: 7BIT Hi Jari, Jari Arkko wrote: > Greg Daley wrote: > >> Where SEND nodes provide backward compatability with >> non-SEND nodes, it may be possible for a non-SEND attacker >> to create a new neighbour cache entry on a victim SEND node >> for a legitimate third party which also uses SEND. >> In order for such an attack to occur, the SEND host >> must have no SEND neighbour cache state for the third >> node, and therefore has no existing data traffic. >> The attacking node sends a solicitation message including >> a Source Link-layer Address option to the >> victim, purporting to be the third party. >> This creates a neighbour cache entry in the STALE state, >> which can be used for up to five seconds before >> invoking neighbour unreachability detection. > > > This is correct. > >> While SEND messaging from the third party will override >> is neighbour cache entry, upper layer confirmation >> for the communication can be used to extend the lifetime >> of the attack. > > > This is true as well. I think the real question is if > we consider this as an attack, given that the third > party did not actually want to communicate with our > victim node. I guess the answer is "yes", because > the victim is still fooled into believing the third > party contacted it. For instance, my server could be > fooled into believing that my laptop contacted it > whereas in reality the laptop did not have a need > to contact the server and the communications actually > came from an attacker. > >> Here is some text to cover the issue: >> >> (not sure about SHOULD NOT or MUST NOT for the second case.) >> >> " >> ... >> >> * Neighbor Solicitations for the purpose of Neighbor >> Unreachabilty Detection (NUD) MUST be sent to that >> neighbor's solicited-nodes multicast address, if the >> entry is not secured with SEND. > > > Ok. > >> * Upper layer confirmations on unsecured neighbor cache entries >> SHOULD NOT update neighbor cache state from STALE to REACHABLE >> on a SEND node. This ensures that if an entry spoofing a valid >> SEND host is created by a non-SEND attacker without being >> solicited, NUD will always be done within 5 seconds of use of >> the entry for data transmission. > > > This sounds OK too, although I do worry about the performance > impact to SEND nodes who are communicating with non-SEND > nodes. They'll be doing NUD all the time. Is this a problem? Perhaps it is too severe. Wireless devices may not like it... If you have received a (real) solicited NA then you've got bidirectional reachability with them, and no-one else has responded. maybe: * Upper layer confirmations on unsecured neighbor cache entries SHOULD NOT update neighbor cache state from STALE to REACHABLE on a SEND node, if the neighbour cache entry has never previously been REACHABLE. This ensures that if an entry spoofing a valid SEND host is created by a non-SEND attacker without being solicited, NUD will be done within 5 seconds of use of the entry for data transmission. The words might sound a bit stilted, but this allows for reachability testing. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 15 06:45:41 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09985 for ; Thu, 15 Jul 2004 06:45:40 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6FAjePA001042 for ; Thu, 15 Jul 2004 12:45:41 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 12:45:40 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32377SXB; Thu, 15 Jul 2004 12:45:40 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6FAjbXA009812; Thu, 15 Jul 2004 12:45:37 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6FAiZIt005149; Thu, 15 Jul 2004 12:44:35 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6FAiZr7005143; Thu, 15 Jul 2004 12:44:35 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6FAiXIt005094 for ; Thu, 15 Jul 2004 12:44:33 +0200 (MET DST) Received: from kolumbus.fi ([80.186.218.97]) by fep07-app.kolumbus.fi with ESMTP id <20040715104433.UGPS3463.fep07-app.kolumbus.fi@kolumbus.fi>; Thu, 15 Jul 2004 13:44:33 +0300 Message-ID: <40F65EDF.2070601@kolumbus.fi> Date: Thu, 15 Jul 2004 13:39:27 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: ietf-send@standards.ericsson.net Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> <40F618CC.2010704@eng.monash.edu.au> In-Reply-To: <40F618CC.2010704@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 10:45:40.0386 (UTC) FILETIME=[DEFAC820:01C46A58] Content-Transfer-Encoding: 7bit Greg Daley wrote: >>> * Upper layer confirmations on unsecured neighbor cache entries >>> SHOULD NOT update neighbor cache state from STALE to REACHABLE >>> on a SEND node. This ensures that if an entry spoofing a valid >>> SEND host is created by a non-SEND attacker without being >>> solicited, NUD will always be done within 5 seconds of use of >>> the entry for data transmission. >> >> This sounds OK too, although I do worry about the performance >> impact to SEND nodes who are communicating with non-SEND >> nodes. They'll be doing NUD all the time. Is this a problem? > > Perhaps it is too severe. Wireless devices may not like it... > > If you have received a (real) solicited NA then you've got > bidirectional reachability with them, and no-one else > has responded. > > maybe: > > * Upper layer confirmations on unsecured neighbor cache entries > SHOULD NOT update neighbor cache state from STALE to REACHABLE > on a SEND node, if the neighbour cache entry has never previously > been REACHABLE. This ensures that if an entry spoofing a valid > SEND host is created by a non-SEND attacker without being > solicited, NUD will be done within 5 seconds of use of > the entry for data transmission. > > The words might sound a bit stilted, but this allows for > reachability testing. This would be OK. Lets make the change. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 15 13:02:39 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04167 for ; Thu, 15 Jul 2004 13:02:38 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6FH2dWR017866 for ; Thu, 15 Jul 2004 19:02:40 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 19:02:39 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4W2N58; Thu, 15 Jul 2004 19:02:39 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6FH2Owg002829; Thu, 15 Jul 2004 19:02:24 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6FH1GIt004596; Thu, 15 Jul 2004 19:01:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6FH1F9e004573; Thu, 15 Jul 2004 19:01:15 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6FH1BIt004301 for ; Thu, 15 Jul 2004 19:01:12 +0200 (MET DST) Message-ID: <00e901c46a8d$6e7c4f30$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , Cc: References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? Date: Thu, 15 Jul 2004 10:01:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 17:02:39.0398 (UTC) FILETIME=[88F61C60:01C46A8D] Content-Transfer-Encoding: 7bit > > * Upper layer confirmations on unsecured neighbor cache entries > > SHOULD NOT update neighbor cache state from STALE to REACHABLE > > on a SEND node. This ensures that if an entry spoofing a valid > > SEND host is created by a non-SEND attacker without being > > solicited, NUD will always be done within 5 seconds of use of > > the entry for data transmission. > If I understand the suggested fix correctly, the receipt of an unsolicited nonSEND NA for a unsecured cache entry would trigger an NS to probe whether the host is at the expected destination. Naturally, the attacker could answer back with an insecured NA, so there is no guarantee that the probe will succeed in detecting the attack. If the host isn't using SEND, then it's subject to ND-spoofing, so the suggested fix will only provide protection if the attacker is attempting to disrupt traffic and not hijack it. So the suggested fix won't provide much protection. I'd suggest adding the following sentence to the end of Greg's bullet: An attacker can naturally reply to the NUD probe with an insecure NA, so the protection provided by this measure only extends to detecting an attempt to disrupt traffic, not hijack it. Secured cache entries won't have this problem after they are established, since an insecure NA for such will be discarded (Section 8, bullet 6). The only real solution is to actually use SEND on the link. :-) > This sounds OK too, although I do worry about the performance > impact to SEND nodes who are communicating with non-SEND > nodes. They'll be doing NUD all the time. Is this a problem? > The problem will only occur if a nonSEND node sends an unsolicited NA to report a link address change. Seems to me that such a link address change typically doesn't happen very often, so the performance should not be a large problem. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 15 13:03:08 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04193 for ; Thu, 15 Jul 2004 13:03:08 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6FH34PA012291 for ; Thu, 15 Jul 2004 19:03:08 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 19:03:03 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321M01PL; Thu, 15 Jul 2004 19:03:03 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6FH32wg002867; Thu, 15 Jul 2004 19:03:02 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6FH2dIt008385; Thu, 15 Jul 2004 19:02:39 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6FH2cDJ008357; Thu, 15 Jul 2004 19:02:38 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6FH2ZIt008267 for ; Thu, 15 Jul 2004 19:02:36 +0200 (MET DST) Message-ID: <00f301c46a8d$a273af40$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Jari Arkko" Cc: References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> <40F618CC.2010704@eng.monash.edu.au> Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? Date: Thu, 15 Jul 2004 10:03:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 17:03:03.0930 (UTC) FILETIME=[979565A0:01C46A8D] Content-Transfer-Encoding: 7bit Yes, this is a little better, but I still think the qualifier on the extent of the protection should be added. jak ----- Original Message ----- From: "Greg Daley" To: "Jari Arkko" Cc: Sent: Wednesday, July 14, 2004 10:40 PM Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? > Hi Jari, > > Jari Arkko wrote: > > Greg Daley wrote: > > > >> Where SEND nodes provide backward compatability with > >> non-SEND nodes, it may be possible for a non-SEND attacker > >> to create a new neighbour cache entry on a victim SEND node > >> for a legitimate third party which also uses SEND. > >> In order for such an attack to occur, the SEND host > >> must have no SEND neighbour cache state for the third > >> node, and therefore has no existing data traffic. > >> The attacking node sends a solicitation message including > >> a Source Link-layer Address option to the > >> victim, purporting to be the third party. > >> This creates a neighbour cache entry in the STALE state, > >> which can be used for up to five seconds before > >> invoking neighbour unreachability detection. > > > > > > This is correct. > > > >> While SEND messaging from the third party will override > >> is neighbour cache entry, upper layer confirmation > >> for the communication can be used to extend the lifetime > >> of the attack. > > > > > > This is true as well. I think the real question is if > > we consider this as an attack, given that the third > > party did not actually want to communicate with our > > victim node. I guess the answer is "yes", because > > the victim is still fooled into believing the third > > party contacted it. For instance, my server could be > > fooled into believing that my laptop contacted it > > whereas in reality the laptop did not have a need > > to contact the server and the communications actually > > came from an attacker. > > > >> Here is some text to cover the issue: > >> > >> (not sure about SHOULD NOT or MUST NOT for the second case.) > >> > >> " > >> ... > >> > >> * Neighbor Solicitations for the purpose of Neighbor > >> Unreachabilty Detection (NUD) MUST be sent to that > >> neighbor's solicited-nodes multicast address, if the > >> entry is not secured with SEND. > > > > > > Ok. > > > >> * Upper layer confirmations on unsecured neighbor cache entries > >> SHOULD NOT update neighbor cache state from STALE to REACHABLE > >> on a SEND node. This ensures that if an entry spoofing a valid > >> SEND host is created by a non-SEND attacker without being > >> solicited, NUD will always be done within 5 seconds of use of > >> the entry for data transmission. > > > > > > This sounds OK too, although I do worry about the performance > > impact to SEND nodes who are communicating with non-SEND > > nodes. They'll be doing NUD all the time. Is this a problem? > > Perhaps it is too severe. Wireless devices may not like it... > > If you have received a (real) solicited NA then you've got > bidirectional reachability with them, and no-one else > has responded. > > maybe: > > * Upper layer confirmations on unsecured neighbor cache entries > SHOULD NOT update neighbor cache state from STALE to REACHABLE > on a SEND node, if the neighbour cache entry has never previously > been REACHABLE. This ensures that if an entry spoofing a valid > SEND host is created by a non-SEND attacker without being > solicited, NUD will be done within 5 seconds of use of > the entry for data transmission. > > The words might sound a bit stilted, but this allows for > reachability testing. > > Greg > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 15 13:12:32 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04840 for ; Thu, 15 Jul 2004 13:12:32 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6FHCYPA013180 for ; Thu, 15 Jul 2004 19:12:34 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jul 2004 19:12:33 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32370LC3; Thu, 15 Jul 2004 19:12:33 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6FHCVwg003444; Thu, 15 Jul 2004 19:12:31 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6FHC0It000199; Thu, 15 Jul 2004 19:12:00 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6FHC04q000180; Thu, 15 Jul 2004 19:12:00 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6FHBvIt000020 for ; Thu, 15 Jul 2004 19:11:58 +0200 (MET DST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6FHBiS31223; Thu, 15 Jul 2004 10:11:44 -0700 X-mProtect: <200407151711> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpwJC1n; Thu, 15 Jul 2004 10:11:43 PDT Message-ID: <40F6BADC.2070504@iprg.nokia.com> Date: Thu, 15 Jul 2004 10:11:56 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: Mohan Parthasarathy , James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <40F59E1A.9050704@iprg.nokia.com> <40F5F543.2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Jul 2004 17:12:33.0734 (UTC) FILETIME=[EB369660:01C46A8E] Content-Transfer-Encoding: 7bit Thanks Greg, Looking at RFC 2461 (and, reversing the order of things a bit) what actually seems more clear to me now is that a SEND RS with a source address other than the unspecified address and an SLLAO will certainly update the router's NCE. So, a node that changes its L2 address can certainly update the NCEs in any routers right away by sending them SEND RSs. (Getting an RA back would provide good evidence that the L2 address change has been registered.) Regards - Fred ftemplin@iprg.nokia.com Greg Daley wrote: > Hi Fred, > > Fred Templin wrote: > >> Hmm... I guess for routers, an unsolicited SEND RA with >> an SLLAO and sent to an IPv6 unicast address will do >> pretty much the same thing - right? I guess I'd better >> go off and take a closer look at the specs now... > > > Yes, the routers will probably do unsolicited RAs > anyway though. > > The difference between the unsolicited NA and the unsolicited > RA is that hosts will probably create a neighbour cache entry > for the unsolicited RA, whereas only existing NCEs will be > updated with the unsolicited NA. > > If we're talking proxyND, the unsolicited NA (override flag set) > should do the trick if there's been a link-layer change caused > by a node moving away, or the proxy being changed. > > Greg > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jul 16 01:44:10 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21988 for ; Fri, 16 Jul 2004 01:44:09 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6G5i8WR004702 for ; Fri, 16 Jul 2004 07:44:08 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 07:44:07 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 321NC464; Fri, 16 Jul 2004 07:44:07 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6G5i2wg003121; Fri, 16 Jul 2004 07:44:02 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6G5gqIt003384; Fri, 16 Jul 2004 07:42:52 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6G5gqjs003370; Fri, 16 Jul 2004 07:42:52 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6G5glIt003006 for ; Fri, 16 Jul 2004 07:42:49 +0200 (MET DST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCJ8WF21FC8Y644S@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Fri, 16 Jul 2004 15:40:15 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5A128AB548; Fri, 16 Jul 2004 15:40:14 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 3903C4FB05; Fri, 16 Jul 2004 15:40:14 +1000 (EST) Date: Fri, 16 Jul 2004 15:40:13 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Fred Templin Cc: Mohan Parthasarathy , James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F76A3D.8090103@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <40F59E1A.9050704@iprg.nokia.com> <40F6BADC.2070504@iprg.nokia.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Jul 2004 05:44:07.0757 (UTC) FILETIME=[E9586FD0:01C46AF7] Content-Transfer-Encoding: 7BIT Hi Fred, Fred Templin wrote: > Thanks Greg, > > Looking at RFC 2461 (and, reversing the order of things a bit) > what actually seems more clear to me now is that a SEND RS > with a source address other than the unspecified address and > an SLLAO will certainly update the router's NCE. > > So, a node that changes its L2 address can certainly update the > NCEs in any routers right away by sending them SEND RSs. > (Getting an RA back would provide good evidence that the > L2 address change has been registered.) This isn't exactly what I had in mind (link address change) but the idea that you can push NC state to routers is indicated in: http://www.ietf.org/internet-drafts/draft-daley-ipv6-preempt-nd-00.txt The main goal there was to provide new NCE's for global addresses when we're expecting off-link data through routers using Mobile IPv6. If the routers already have an NCE for you, then an unsolicited NA also works. This won't work in the Mobile IPv6 case though, since the address is being used for the first time. Greg > Regards - Fred > ftemplin@iprg.nokia.com > > Greg Daley wrote: > >> Hi Fred, >> >> Fred Templin wrote: >> >>> Hmm... I guess for routers, an unsolicited SEND RA with >>> an SLLAO and sent to an IPv6 unicast address will do >>> pretty much the same thing - right? I guess I'd better >>> go off and take a closer look at the specs now... >> >> >> >> Yes, the routers will probably do unsolicited RAs >> anyway though. >> >> The difference between the unsolicited NA and the unsolicited >> RA is that hosts will probably create a neighbour cache entry >> for the unsolicited RA, whereas only existing NCEs will be >> updated with the unsolicited NA. >> >> If we're talking proxyND, the unsolicited NA (override flag set) >> should do the trick if there's been a link-layer change caused >> by a node moving away, or the proxy being changed. >> >> Greg >> >> -------------------------------------------------------------------- >> To unsubscribe from this list, send email with "UNSUBSCRIBE" in the >> body to . >> Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html >> -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jul 16 01:45:59 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22078 for ; Fri, 16 Jul 2004 01:45:58 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6G5juPA020958 for ; Fri, 16 Jul 2004 07:45:56 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 07:45:56 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3238CXGF; Fri, 16 Jul 2004 07:45:56 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6G5jtwg003195; Fri, 16 Jul 2004 07:45:55 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6G5jVIt010575; Fri, 16 Jul 2004 07:45:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6G5jVr3010569; Fri, 16 Jul 2004 07:45:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6G5jSIt010462 for ; Fri, 16 Jul 2004 07:45:29 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LCJ90I85B68WYD23@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Fri, 16 Jul 2004 15:43:34 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 25D0280035; Fri, 16 Jul 2004 15:43:32 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 09F913C00F; Fri, 16 Jul 2004 15:43:32 +1000 (EST) Date: Fri, 16 Jul 2004 15:43:31 +1000 From: Greg Daley Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? To: James Kempf Cc: Jari Arkko , ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40F76B03.8020300@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> <00e901c46a8d$6e7c4f30$536115ac@dcml.docomolabsusa.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Jul 2004 05:45:56.0250 (UTC) FILETIME=[2A0327A0:01C46AF8] Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: >>>* Upper layer confirmations on unsecured neighbor cache entries >>> SHOULD NOT update neighbor cache state from STALE to REACHABLE >>> on a SEND node. This ensures that if an entry spoofing a valid >>> SEND host is created by a non-SEND attacker without being >>> solicited, NUD will always be done within 5 seconds of use of >>> the entry for data transmission. >> > > If I understand the suggested fix correctly, the receipt of an unsolicited > nonSEND NA for a unsecured cache entry would trigger an NS to probe whether > the host is at the expected destination. Naturally, the attacker could > answer back with an insecured NA, so there is no guarantee that the probe > will succeed in detecting the attack. If the host isn't using SEND, then > it's subject to ND-spoofing, so the suggested fix will only provide > protection if the attacker is attempting to disrupt traffic and not hijack > it. Actually, of the unsecured unsolicited NA case, no NC entry is created. The issue is with the NS,RS or RA (with SLLAO), which all create NC entries. The purpose of the multicast NS for NUD on the unsecured NC entries, is to ensure that the real owner of the address responds. This will "trump" any unsecured NC state, and make the unsecured NS,NA,RS,RA messages unable to affect the entry (which is now secured). > So the suggested fix won't provide much protection. I'd suggest adding the > following sentence to the end of Greg's bullet: > > An attacker can naturally reply to the NUD probe with > an insecure NA, so the protection provided by this measure > only extends to detecting an attempt to disrupt traffic, not hijack > it. > > Secured cache entries won't have this problem after they are established, > since an insecure NA for such will be discarded (Section 8, bullet 6). The > only real solution is to actually use SEND on the link. :-) Hijacking an entry is halted by the responding NA to the NUD NS (which is multicast). The initial hijack attempt will be unknown (and may not be preventable since we're accepting non-SEND packets) for up to 5 seconds while the NCE is in DELAY state before sending the NS. > >>This sounds OK too, although I do worry about the performance >>impact to SEND nodes who are communicating with non-SEND >>nodes. They'll be doing NUD all the time. Is this a problem? >> > > > The problem will only occur if a nonSEND node sends an unsolicited NA to > report a link address change. Seems to me that such a link address change > typically doesn't happen very often, so the performance should not be a > large problem. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jul 16 03:38:12 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11951 for ; Fri, 16 Jul 2004 03:38:12 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6G7cCAh014374 for ; Fri, 16 Jul 2004 09:38:12 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 09:38:12 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32RAKNL2; Fri, 16 Jul 2004 09:38:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6G7cBXA025905; Fri, 16 Jul 2004 09:38:11 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6G7bGIt027324; Fri, 16 Jul 2004 09:37:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6G7bGGk027301; Fri, 16 Jul 2004 09:37:16 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep19-app.kolumbus.fi (fep19-0.kolumbus.fi [193.229.0.45]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6G7bDIt027176 for ; Fri, 16 Jul 2004 09:37:13 +0200 (MET DST) Received: from kolumbus.fi ([80.186.218.97]) by fep19-app.kolumbus.fi with ESMTP id <20040716073711.XAXU26758.fep19-app.kolumbus.fi@kolumbus.fi>; Fri, 16 Jul 2004 10:37:11 +0300 Message-ID: <40F78473.1010505@kolumbus.fi> Date: Fri, 16 Jul 2004 10:32:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: greg.daley@eng.monash.edu.au, ietf-send@standards.ericsson.net Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> <00e901c46a8d$6e7c4f30$536115ac@dcml.docomolabsusa.com> In-Reply-To: <00e901c46a8d$6e7c4f30$536115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Jul 2004 07:38:12.0258 (UTC) FILETIME=[D8FC6820:01C46B07] Content-Transfer-Encoding: 7bit James Kempf wrote: >>>* Upper layer confirmations on unsecured neighbor cache entries >>> SHOULD NOT update neighbor cache state from STALE to REACHABLE >>> on a SEND node. This ensures that if an entry spoofing a valid >>> SEND host is created by a non-SEND attacker without being >>> solicited, NUD will always be done within 5 seconds of use of >>> the entry for data transmission. >> > > If I understand the suggested fix correctly, the receipt of an unsolicited > nonSEND NA for a unsecured cache entry would trigger an NS to probe whether > the host is at the expected destination. Naturally, the attacker could > answer back with an insecured NA, so there is no guarantee that the probe > will succeed in detecting the attack. If the host isn't using SEND, then > it's subject to ND-spoofing, so the suggested fix will only provide > protection if the attacker is attempting to disrupt traffic and not hijack > it. > > So the suggested fix won't provide much protection. I'd suggest adding the I think the purpose is to get the real node to respond, which would overried the bogus entry. Of course, the assumption is that the real node *is* on the link and has not lost messages. > following sentence to the end of Greg's bullet: I'll suggest a slightly different additional sentence to the Greg second bullet: * Upper layer confirmations on unsecured neighbor cache entries SHOULD NOT update neighbor cache state from STALE to REACHABLE on a SEND node, if the neighbour cache entry has never previously been REACHABLE. This ensures that if an entry spoofing a valid SEND host is created by a non-SEND attacker without being solicited, NUD will be done within 5 seconds of use of the entry for data transmission. As a result, in mixed mode attackers can take over a Neighbor Cache entry of a SEND node for a longer time only if (a) the SEND node was not communicating with the victim node so that there is no secure entry for it and (b) the SEND node is not currently on the link (or is unable to respond). --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jul 16 11:39:48 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09941 for ; Fri, 16 Jul 2004 11:39:47 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6GFdmAh007845 for ; Fri, 16 Jul 2004 17:39:48 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 17:39:47 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32RANQBD; Fri, 16 Jul 2004 17:39:47 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6GFdiXA010059; Fri, 16 Jul 2004 17:39:44 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6GFcoIt028298; Fri, 16 Jul 2004 17:38:50 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6GFcoOb028292; Fri, 16 Jul 2004 17:38:50 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6GFcmIt028198 for ; Fri, 16 Jul 2004 17:38:49 +0200 (MET DST) Message-ID: <000f01c46b4b$1804bf20$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Cc: "Jari Arkko" , References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> <00e901c46a8d$6e7c4f30$536115ac@dcml.docomolabsusa.com> <40F76B03.8020300@eng.monash.edu.au> Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? Date: Fri, 16 Jul 2004 08:39:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Jul 2004 15:39:47.0891 (UTC) FILETIME=[20201830:01C46B4B] Content-Transfer-Encoding: 7bit OK, I missed the part about the multicast NS. I withdraw the previously proposed text, and agree to Greg's additions as posted. jak ----- Original Message ----- From: "Greg Daley" To: "James Kempf" Cc: "Jari Arkko" ; Sent: Thursday, July 15, 2004 10:43 PM Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? > Hi James, > > James Kempf wrote: > >>>* Upper layer confirmations on unsecured neighbor cache entries > >>> SHOULD NOT update neighbor cache state from STALE to REACHABLE > >>> on a SEND node. This ensures that if an entry spoofing a valid > >>> SEND host is created by a non-SEND attacker without being > >>> solicited, NUD will always be done within 5 seconds of use of > >>> the entry for data transmission. > >> > > > > If I understand the suggested fix correctly, the receipt of an unsolicited > > nonSEND NA for a unsecured cache entry would trigger an NS to probe whether > > the host is at the expected destination. Naturally, the attacker could > > answer back with an insecured NA, so there is no guarantee that the probe > > will succeed in detecting the attack. If the host isn't using SEND, then > > it's subject to ND-spoofing, so the suggested fix will only provide > > protection if the attacker is attempting to disrupt traffic and not hijack > > it. > > Actually, of the unsecured unsolicited NA case, no NC entry is created. > > The issue is with the NS,RS or RA (with SLLAO), which all create > NC entries. > > The purpose of the multicast NS for NUD on the unsecured NC entries, > is to ensure that the real owner of the address responds. > This will "trump" any unsecured NC state, and make the unsecured > NS,NA,RS,RA messages unable to affect the entry (which is now secured). > > > > So the suggested fix won't provide much protection. I'd suggest adding the > > following sentence to the end of Greg's bullet: > > > > An attacker can naturally reply to the NUD probe with > > an insecure NA, so the protection provided by this measure > > only extends to detecting an attempt to disrupt traffic, not hijack > > it. > > > > Secured cache entries won't have this problem after they are established, > > since an insecure NA for such will be discarded (Section 8, bullet 6). The > > only real solution is to actually use SEND on the link. :-) > > Hijacking an entry is halted by the responding NA to the > NUD NS (which is multicast). The initial hijack attempt > will be unknown (and may not be preventable since we're accepting > non-SEND packets) for up to 5 seconds while the NCE is in > DELAY state before sending the NS. > > > > >>This sounds OK too, although I do worry about the performance > >>impact to SEND nodes who are communicating with non-SEND > >>nodes. They'll be doing NUD all the time. Is this a problem? > >> > > > > > > The problem will only occur if a nonSEND node sends an unsolicited NA to > > report a link address change. Seems to me that such a link address change > > typically doesn't happen very often, so the performance should not be a > > large problem. > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jul 16 11:41:30 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10107 for ; Fri, 16 Jul 2004 11:41:29 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6GFfUPA007092 for ; Fri, 16 Jul 2004 17:41:30 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 17:41:29 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3238GT5A; Fri, 16 Jul 2004 17:41:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6GFfSXA010091; Fri, 16 Jul 2004 17:41:28 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6GFfBIt004437; Fri, 16 Jul 2004 17:41:11 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6GFfBqE004427; Fri, 16 Jul 2004 17:41:11 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6GFf9It004349 for ; Fri, 16 Jul 2004 17:41:09 +0200 (MET DST) Message-ID: <002101c46b4b$6bd90340$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" Cc: , References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> <00e901c46a8d$6e7c4f30$536115ac@dcml.docomolabsusa.com> <40F78473.1010505@kolumbus.fi> Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? Date: Fri, 16 Jul 2004 08:41:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Jul 2004 15:41:29.0439 (UTC) FILETIME=[5CA716F0:01C46B4B] Content-Transfer-Encoding: 7bit Yes, that sounds even better. jak ----- Original Message ----- From: "Jari Arkko" To: "James Kempf" Cc: ; Sent: Friday, July 16, 2004 12:32 AM Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? > James Kempf wrote: > >>>* Upper layer confirmations on unsecured neighbor cache entries > >>> SHOULD NOT update neighbor cache state from STALE to REACHABLE > >>> on a SEND node. This ensures that if an entry spoofing a valid > >>> SEND host is created by a non-SEND attacker without being > >>> solicited, NUD will always be done within 5 seconds of use of > >>> the entry for data transmission. > >> > > > > If I understand the suggested fix correctly, the receipt of an unsolicited > > nonSEND NA for a unsecured cache entry would trigger an NS to probe whether > > the host is at the expected destination. Naturally, the attacker could > > answer back with an insecured NA, so there is no guarantee that the probe > > will succeed in detecting the attack. If the host isn't using SEND, then > > it's subject to ND-spoofing, so the suggested fix will only provide > > protection if the attacker is attempting to disrupt traffic and not hijack > > it. > > > > So the suggested fix won't provide much protection. I'd suggest adding the > > I think the purpose is to get the real node to respond, which would > overried the bogus entry. > > Of course, the assumption is that the real node *is* on the link > and has not lost messages. > > > following sentence to the end of Greg's bullet: > > I'll suggest a slightly different additional sentence to the > Greg second bullet: > > * Upper layer confirmations on unsecured neighbor cache entries > SHOULD NOT update neighbor cache state from STALE to REACHABLE > on a SEND node, if the neighbour cache entry has never previously > been REACHABLE. This ensures that if an entry spoofing a valid > SEND host is created by a non-SEND attacker without being > solicited, NUD will be done within 5 seconds of use of > the entry for data transmission. > > As a result, in mixed mode attackers can take over > a Neighbor Cache entry of a SEND node for a longer time > only if (a) the SEND node was not communicating with the victim > node so that there is no secure entry for it and (b) the > SEND node is not currently on the link (or is unable to > respond). > > --Jari > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jul 16 13:35:20 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17777 for ; Fri, 16 Jul 2004 13:35:19 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6GHZIWR025364 for ; Fri, 16 Jul 2004 19:35:19 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 19:35:18 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 32RA3C9Z; Fri, 16 Jul 2004 19:35:18 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6GHZEwg018998; Fri, 16 Jul 2004 19:35:14 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6GHY7It013838; Fri, 16 Jul 2004 19:34:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6GHY6Np013822; Fri, 16 Jul 2004 19:34:06 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6GHY3It013648 for ; Fri, 16 Jul 2004 19:34:04 +0200 (MET DST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6GHXk118848; Fri, 16 Jul 2004 10:33:46 -0700 X-mProtect: <200407161733> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2UUVDo; Fri, 16 Jul 2004 10:33:44 PDT Message-ID: <40F8118A.9020705@iprg.nokia.com> Date: Fri, 16 Jul 2004 10:34:02 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: Mohan Parthasarathy , James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <40F59E1A.9050704@iprg.nokia.com> <40F6BADC.2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Jul 2004 17:35:18.0506 (UTC) FILETIME=[431804A0:01C46B5B] Content-Transfer-Encoding: 7bit Greg, Greg Daley wrote: > This isn't exactly what I had in mind (link address change) > but the idea that you can push NC state to routers is > indicated in: > > http://www.ietf.org/internet-drafts/draft-daley-ipv6-preempt-nd-00.txt OK, but I guess what I'm looking (at least in terms of updating a router's NC state) is sufficiently covered under RFC 2461 along with SEND/CGA extensions. Thanks - Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jul 17 06:13:45 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06307 for ; Sat, 17 Jul 2004 06:13:44 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6HADjWR012231 for ; Sat, 17 Jul 2004 12:13:46 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Jul 2004 12:13:45 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4W4DR8; Sat, 17 Jul 2004 12:13:44 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6HADhXA019125; Sat, 17 Jul 2004 12:13:43 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6HABmIt014126; Sat, 17 Jul 2004 12:11:48 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6HABmDW014107; Sat, 17 Jul 2004 12:11:48 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6HABlIt014058 for ; Sat, 17 Jul 2004 12:11:47 +0200 (MET DST) Received: from mta.imail.kolumbus.fi ([193.229.5.110]) by fep01-app.kolumbus.fi with ESMTP id <20040717101146.ZJRW13175.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> for ; Sat, 17 Jul 2004 13:11:46 +0300 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) X-Originating-IP: [80.186.218.97] From: To: Subject: new ndopts draft revision Date: Sat, 17 Jul 2004 13:11:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040717101146.ZJRW13175.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 17 Jul 2004 10:13:45.0144 (UTC) FILETIME=[BE3B8B80:01C46BE6] Content-Transfer-Encoding: 7bit Dear all, I have submitted a new version of the NDOPT draft to the I-D directories. For the moment you can access the draft and its diff to -05 from the following URLs: http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-06.txt http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-06diff.html This version addresses all issues raised by the IESG (I hope!), the issue from Greg, three off-list comments from Jim Bound, and two small technical modifications from James. Please see the specific issues and their associated diffs at: http://www.arkko.com/publications/send/issues/ --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 18 20:06:59 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13384 for ; Sun, 18 Jul 2004 20:06:58 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6J06wPA006094 for ; Mon, 19 Jul 2004 02:06:58 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Jul 2004 02:06:57 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3238RJQ0; Mon, 19 Jul 2004 02:06:57 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6J06uXA005023; Mon, 19 Jul 2004 02:06:56 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6J05VIt005648; Mon, 19 Jul 2004 02:05:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6J05U3p005629; Mon, 19 Jul 2004 02:05:30 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6J05QIt005505 for ; Mon, 19 Jul 2004 02:05:28 +0200 (MET DST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LCN41QNMIS8Y9432@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 19 Jul 2004 10:04:14 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9F079AB542; Mon, 19 Jul 2004 10:04:08 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 825AC4FB05; Mon, 19 Jul 2004 10:04:08 +1000 (EST) Date: Mon, 19 Jul 2004 10:04:08 +1000 From: Greg Daley Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility To: Fred Templin Cc: Mohan Parthasarathy , James Kempf , Vijay Devarapalli , Jean-Michel COMBES , jari.arkko@kolumbus.fi, ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40FB0FF8.5060709@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3d571d3d7650.3d76503d571d@monash.edu.au> <005601c46793$cbf6f770$6401a8c0@adithya> <40F1CC5E.8090106@eng.monash.edu.au> <011001c4687d$2a7b9780$861167c0@adithya> <40F3476F.6000408@eng.monash.edu.au> <40F59E1A.9050704@iprg.nokia.com> <40F8118A.9020705@iprg.nokia.com> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 19 Jul 2004 00:06:57.0707 (UTC) FILETIME=[4E8907B0:01C46D24] Content-Transfer-Encoding: 7BIT Hi Fred, Fred Templin wrote: > Greg, > > Greg Daley wrote: > >> This isn't exactly what I had in mind (link address change) >> but the idea that you can push NC state to routers is >> indicated in: >> >> http://www.ietf.org/internet-drafts/draft-daley-ipv6-preempt-nd-00.txt > > > > OK, but I guess what I'm looking (at least in terms of updating > a router's NC state) is sufficiently covered under RFC 2461 > along with SEND/CGA extensions. Yes. The draft only describes how the existing behaviour can be made use of. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jul 18 20:11:58 2004 Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13745 for ; Sun, 18 Jul 2004 20:11:58 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6J0BxPA006513 for ; Mon, 19 Jul 2004 02:11:59 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Jul 2004 02:11:58 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4W66T9; Mon, 19 Jul 2004 02:11:57 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6J0Blwg015634; Mon, 19 Jul 2004 02:11:47 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6J0BSIt021756; Mon, 19 Jul 2004 02:11:28 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6J0BRfj021730; Mon, 19 Jul 2004 02:11:27 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6J0BPIt021545 for ; Mon, 19 Jul 2004 02:11:26 +0200 (MET DST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCN48L9EN68WWFLI@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 19 Jul 2004 10:09:41 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A4F5480039; Mon, 19 Jul 2004 10:09:39 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8EFC53C005; Mon, 19 Jul 2004 10:09:39 +1000 (EST) Date: Mon, 19 Jul 2004 10:09:39 +1000 From: Greg Daley Subject: Re: Creating a valid neighbour cache entry with an unsecured NS? To: Jari Arkko Cc: James Kempf , ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <40FB1143.8090003@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <40F5DF4A.2080109@eng.monash.edu.au> <40F60AA1.1070102@kolumbus.fi> <00e901c46a8d$6e7c4f30$536115ac@dcml.docomolabsusa.com> <40F78473.1010505@kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 19 Jul 2004 00:11:58.0693 (UTC) FILETIME=[01EFD950:01C46D25] Content-Transfer-Encoding: 7BIT Hi Jari, Jari Arkko wrote: [chop] > I'll suggest a slightly different additional sentence to the > Greg second bullet: > > * Upper layer confirmations on unsecured neighbor cache entries > SHOULD NOT update neighbor cache state from STALE to REACHABLE > on a SEND node, if the neighbour cache entry has never previously > been REACHABLE. This ensures that if an entry spoofing a valid > SEND host is created by a non-SEND attacker without being > solicited, NUD will be done within 5 seconds of use of > the entry for data transmission. > > As a result, in mixed mode attackers can take over > a Neighbor Cache entry of a SEND node for a longer time > only if (a) the SEND node was not communicating with the victim > node so that there is no secure entry for it and (b) the > SEND node is not currently on the link (or is unable to > respond). Thanks for that, it provides context which wasn't necessarily well explained by me. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jul 21 22:35:17 2004 Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25026 for ; Wed, 21 Jul 2004 22:35:17 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6M2ZHWR017115 for ; Thu, 22 Jul 2004 04:35:18 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Jul 2004 04:35:17 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 3213P2Y3; Thu, 22 Jul 2004 04:35:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6M2ZGXA015891; Thu, 22 Jul 2004 04:35:16 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6M2XsIt008963; Thu, 22 Jul 2004 04:33:54 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6M2Xs93008947; Thu, 22 Jul 2004 04:33:54 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6M2XpIt008881 for ; Thu, 22 Jul 2004 04:33:52 +0200 (MET DST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LCRFWBRYEO8WWLC2@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 22 Jul 2004 12:27:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 74224AB546; Thu, 22 Jul 2004 12:27:19 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 5AA094FB19; Thu, 22 Jul 2004 12:27:19 +1000 (EST) Date: Thu, 22 Jul 2004 12:27:19 +1000 From: Brett Pentland Subject: Some comments on draft-ietf-send-ndopt-06.txt To: ietf-send@standards.ericsson.net Message-id: <40FF2607.1080907@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 22 Jul 2004 02:35:17.0111 (UTC) FILETIME=[863B9070:01C46F94] Content-Transfer-Encoding: 7BIT Hi SEND folks, Sorry to comment so late in the game. I haven't been involved in SEND but I was reading through the draft yesterday and came across a few items that seem worth mentioning. If it's not too late then... * In section 8, p47, the second dot point states: The Neighbor Cache, Prefix List and Default Router list entries MUST have a secured/unsecured flag that indicates whether the message that caused the creation or last update of the entry was secured or unsecured." ... But then the second last sentence of the same point states: ... "The Neighbor Cache SHOULD implement a flag on entries indicating whether the entry is secured." ... The "SHOULD" in this second sentence seems to already be covered by the earlier "MUST", and perhaps should be removed. * In section 5.2.4 Perfomance Considerations, there seems to be a minor inconsistancy. At the end of the second paragraph it states: A. ... "A large number of router solicitations may cause higher demand for performing asymmetric operations, although the base NDP protocol limits the rate at which responses to solicitations can be sent." This is true for multicast RAs - they are limited by MIN_DELAY_BETWEEN_RAS - but unicast RAs are just delayed, not rate-limited. This might be ok if we expect most solicted RAs to be multicast, but the next paragraph then states: B. ... "Typically, solicited advertisements are sent to the unicast address from which the solicitation was sent." ... I'm not sure what the best way to resolve this is. On the one hand it might be simplest to just remove the text after the comma in block A. However, I'm not sure about block B. Is this an observation about typical implementations? RFC2461 (and the bis draft) states in section 6.2.6 that a router may send unicast responses but the usual case will be to multicast (which actually supports the text in block A). Perhaps block B is mainly referring to neighbour advertisements. I guess my suggestion would be to either change block B with: s/solicited advertisements/solicited neighbor advertisements/ or remove the text after the comma in block A. * typo in section 9.2.4, line 5. s/subnet subnet/subnet/ Hope this is useful. Brett. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jul 22 17:35:36 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08912 for ; Thu, 22 Jul 2004 17:35:35 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i6MLZaAh016789 for ; Thu, 22 Jul 2004 23:35:36 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Jul 2004 23:35:36 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PNRRM47P; Thu, 22 Jul 2004 23:35:35 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i6MLZKwg008182; Thu, 22 Jul 2004 23:35:20 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6MLY3It019326; Thu, 22 Jul 2004 23:34:03 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i6MLY32u019317; Thu, 22 Jul 2004 23:34:03 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i6MLY2It019259 for ; Thu, 22 Jul 2004 23:34:02 +0200 (MET DST) Received: from kolumbus.fi ([80.186.218.97]) by fep07-app.kolumbus.fi with ESMTP id <20040722213401.WHHE3463.fep07-app.kolumbus.fi@kolumbus.fi>; Fri, 23 Jul 2004 00:34:01 +0300 Message-ID: <4100318E.9010001@kolumbus.fi> Date: Fri, 23 Jul 2004 00:28:46 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Pentland CC: ietf-send@standards.ericsson.net Subject: Re: Some comments on draft-ietf-send-ndopt-06.txt References: <40FF2607.1080907@eng.monash.edu.au> In-Reply-To: <40FF2607.1080907@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 22 Jul 2004 21:35:36.0121 (UTC) FILETIME=[D323FA90:01C47033] Content-Transfer-Encoding: 7bit Brett, Thanks for your comments! Inline: > The "SHOULD" in this second sentence seems to already be covered by the > earlier "MUST", and perhaps should be removed. Agreed. Thanks for catching this. > * In section 5.2.4 Perfomance Considerations, there seems to be a minor > inconsistancy. > > At the end of the second paragraph it states: > > A. ... "A large number of router > solicitations may cause higher demand for performing asymmetric > operations, although the base NDP protocol limits the rate at which > responses to solicitations can be sent." > > This is true for multicast RAs - they are limited by > MIN_DELAY_BETWEEN_RAS - but unicast RAs are just delayed, not > rate-limited. This might be ok if we expect most solicted RAs to be > multicast, but the next paragraph then states: > > B. ... "Typically, solicited advertisements are sent to the unicast > address from which the solicitation was sent." ... > > I'm not sure what the best way to resolve this is. On the one hand it > might be simplest to just remove the text after the comma in block A. > However, I'm not sure about block B. Is this an observation about > typical implementations? RFC2461 (and the bis draft) > states in section 6.2.6 that a router may send unicast responses but the > usual case will be to multicast (which actually supports the text in > block A). Perhaps block B is mainly referring to neighbour > advertisements. > > I guess my suggestion would be to either change block B with: > > s/solicited advertisements/solicited neighbor advertisements/ > > or remove the text after the comma in block A. I'd prefer the former. > * typo in section 9.2.4, line 5. > > s/subnet subnet/subnet/ Oops. Thanks. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------