From jari.arkko@lmf.ericsson.se Sun Feb 2 21:55:09 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16966 for ; Sun, 2 Feb 2003 21:55:08 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h132wNKV023724; Mon, 3 Feb 2003 03:58:23 +0100 (MET) 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.2655.55) id DW0CQDZJ; Mon, 3 Feb 2003 03:58:23 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h132wKI20493; Mon, 3 Feb 2003 03:58:21 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id DAA27023; Mon, 3 Feb 2003 03:57:45 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id DAA27019 for ; Mon, 3 Feb 2003 03:57:43 +0100 (MET) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KS055EAKTY8WYSS8@vaxc.cc.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 03 Feb 2003 13:57:34 +1100 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8C0FE12C00C; Mon, 03 Feb 2003 13:57:29 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 9BE7212C006; Mon, 03 Feb 2003 13:57:17 +1100 (EST) Date: Mon, 03 Feb 2003 13:57:09 +1100 From: Greg Daley Subject: Re: WG Last call on draft-ietf-send-psreq-01 To: ietf-send@standards.ericsson.net Cc: pekka.nikander@nomadiclab.com, kempf@docomolabs-usa.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3E3DDA85.9040703@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 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Sorry about the threading, I've not got a copy of this email, except on the archives. James & Pekka, I'm sure that this is not a very important issue, but the last paragraph of section 2 has an error regarding the number of solicited nodes addresses. The number of solicited nodes addresses as shown by RFC2373 and draft-ietf-ipngwg-addr-arch-v3-11.txt is 2^24 or 16777216 addresses. Unfortunately, RFC2461 makes the same mistake as this draft, and believes there are 2^32 addresses (section 3.1). I'm pretty sure this is incorrect. Could this be amended please (the draft, not 2461 ;) ? Greg Daley -------------------------------------------------------------------- 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 Feb 3 20:56:57 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27201 for ; Mon, 3 Feb 2003 20:56:56 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h141xxKV006257; Tue, 4 Feb 2003 02:59:59 +0100 (MET) 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.2655.55) id D7MVJV99; Tue, 4 Feb 2003 02:59:59 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h141xw212113; Tue, 4 Feb 2003 02:59:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id CAA29497; Tue, 4 Feb 2003 02:59:22 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id CAA29493 for ; Tue, 4 Feb 2003 02:59:20 +0100 (MET) Date: Mon, 03 Feb 2003 17:58:52 -0800 Subject: Re: WG Last call on draft-ietf-send-psreq-01 From: Alper Yegin To: SEND WG Message-ID: In-Reply-To: <011c01c2c305$6e79e410$5c6015ac@T23KEMPF> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Here are some comments/questions based on my review... My understanding is that, there are two areas that needs to be worked out. First one is how to secure ND using IPsec when all the required SAs are already manually configured. I'd think the details will be worked out in the SEND WG. Secondly, if there are no pre-configured SAs, the methods to generate them (i.e., bootstraping) needs to be defined. I think at this point PANA may be used as a building block, but the details about how to turn a newly generated trust relation (e.g., a shared secret) into the required IPsec Sas need to be worked out. Is that a fair understanding of the scope of the work? If so, I think this should be clarified in the document. Section 3.1: "However, none of the currently standardized automatic key distribution mechanisms work right out-of-the-box. For further details, see [10]." It'd be good to expand on this statement. Especially what is missing with the current mechanisms, and if and how SEND will fix them. As I understand, there is not separate requirements draft, therefore setting the scope of the work in this document is needed. Section 3.2: "The link layer authentication protocol MAY allow the client nodes and the access router to create a security association. Notice that there exists authentication protocols, e.g., variants of EAP, that do not create secure keying material and/or do not allow the client to authenticate the network." L2 authentication protocol may create a trust relation between the client and the L2 access device, which is not generally same as the access router. "Even if the underlying link layer is aware of all the nodes' link layer addresses, and is able to check that no source addresses were falsified, there may still be vulnerabilities." I'm not sure if L2 access device checking source IP address to prevent such atttacks are practical. Are there any such solutions? "That is, the router would check ICMPv6 packet contents, and filter packets that contain information which does not match the network topology." This approach has limitations, because not in all networks an access router is a MitM to inter-host communication (e.g., multi-access links). Section 4.1.1: "In the case just the operator is trusted, the nodes may rely on the operator to certify the address bindings for other local nodes." Are there existing solutions like that, or is this just a speculation that one can develop such a solution? If the draft is going to talk about solutions, it should clarify their status (available, possible, etc...) Section 4.2.1: "However, the threat can be partially mitigated through a number of means, for example, by configuring the nodes to prefer existing routers over new ones." But this itself is very limiting, as now you cannot introduce a new router to the network. (I'm not sure if visiting these possible approaches in this draft is a good idea, because at times they open up such additonal questions. These require more analysis that can be done later.) Section 4.2.6: "2. The attacker implements a bogus DHCPv6 server or relay and the 'M' and/or 'O' flag is set, indicating that stateful address configuration and/or stateful configuration of other parameters should be done. The attacker is then in a position to answer the stateful configuration queries of a legitimate host with its own bogus replies." The draft should point out if "secure" dhcp can be a solution. Section 4.3.1: "In a way, this problem is fairly similar to the TCP SYN flooding problem. Rate limitating Neighbor Solicitations, restricting the amount of state reserved for unresolved soliciations, and clever cache management may be applied." I'm not sure this solves the problem, because this still starves the legitimate users. I think this discussions is not appropriate for this draft. It's too much solution oriented. Section 4.4: "+ The threat is present and at least one solution is known" This gives the impression that there is a fully-working standard solution to the problems. But I think what we really mean is that there are some candidate proposals that require further analysis. alper On 1/23/03 9:32 AM, "James Kempf" wrote: > WG Last Call on draft-ietf-send-psreq-01.txt starts today and runs for two > weeks, until Feb. 6. This draft is intended to be a comprehensive security > analysis of threats to Neighbor Discovery as it currently exists today in RFCs > 2641 and 2642, according to three different trust models that group current > network deployments into three different equivalence classes. As such, it > functions as a requirements template for the SEND design team. > > It is *extremely important* that this draft be read and commented on by the WG > prior to submission to the IESG. Please make an effort to review the draft > within the Last Call period, and submit any comments to the mailing list or > the > editor (Pekka). > > Text, HTML and XML versions of the draft > are available at the interim web page: > > http://www.tml.hut.fi/~pnr/SEND/ > > The HTML version is directly available at: > > http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-01.html > > The draft was submitted to the IETF drafts respository today and should show > up > there shortly. > > 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 Feb 3 21:57:08 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28053 for ; Mon, 3 Feb 2003 21:57:08 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1430CKV011007; Tue, 4 Feb 2003 04:00:12 +0100 (MET) 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.2655.55) id DW0CYL2V; Tue, 4 Feb 2003 04:00:12 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1430BI09225; Tue, 4 Feb 2003 04:00:11 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id DAA06263; Tue, 4 Feb 2003 03:59:42 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id DAA06258 for ; Tue, 4 Feb 2003 03:59:40 +0100 (MET) Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h142xbL12982 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 3 Feb 2003 21:59:38 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h142xZr7005691 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 3 Feb 2003 21:59:37 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h142xZr9005687 for ; Mon, 3 Feb 2003 21:59:35 -0500 Message-Id: <200302040259.h142xZr9005687@marajade.sandelman.ottawa.on.ca> To: SEND WG Subject: Re: WG Last call on draft-ietf-send-psreq-01 In-reply-to: Your message of "Mon, 03 Feb 2003 17:58:52 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Feb 2003 21:59:34 -0500 From: Michael Richardson Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Alper" == Alper Yegin writes: Alper> My understanding is that, there are two areas that needs to be Alper> worked out. First one is how to secure ND using IPsec when all the Alper> required SAs are already manually configured. I'd think the details Alper> will be worked out in the SEND WG. Secondly, if there are no I think that I missed something (which is very likely, since I've been skimming). The ND is a broadcast. How can you have a shared secret among a group and still consider it a secret? Or is this just to talk to the/a router? So, yes, I think that this is a problem. Alper> pre-configured SAs, the methods to generate them (i.e., bootstraping) Alper> needs to be defined. I think at this point PANA may be used as a building Alper> block, but the details about how to turn a newly generated trust relation Alper> (e.g., a shared secret) into the required IPsec Sas need to be worked out. Alper> Is that a fair understanding of the scope of the work? If so, I think this Alper> should be clarified in the document. This second part - turning something you got from PANA into a IPsec level keying material is either just a question of convention (i.e. "use bytes 0-15 as the AES key, and bytes 16-35 as the SHA1 key"), or a matter of some entropy expansion (assuming PANA doesn't give you enough bits, but a reasonable amount of entropy). I guess I should go read more. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPj8slYqHRg3pndX9AQFwsgP9EC7iU4w7ShqAZ4fK1kw1ouLaW5ICLxFE HI5Skv3CMwAfwNnkozixTpLlDHgrqBAvHAXv+vgOC/GPwg+3D2b/iq1YM3UMDAhZ 8x/kMmuZIpxkmyFADUCUIz6DmKqg5eJ9p4t0L2/5T5pVU/zcFvnKOpyp3tXJ3LQN n6L2a0a5G2U= =IvDU -----END PGP SIGNATURE----- -------------------------------------------------------------------- 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 Feb 4 01:32:48 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02157 for ; Tue, 4 Feb 2003 01:32:47 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h146ZlKV000276; Tue, 4 Feb 2003 07:35:47 +0100 (MET) 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.2655.55) id D7MVK4G5; Tue, 4 Feb 2003 07:35:47 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h146Zk217642; Tue, 4 Feb 2003 07:35:46 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id HAA13649; Tue, 4 Feb 2003 07:35:17 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id HAA13644 for ; Tue, 4 Feb 2003 07:35:16 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h146ZBw28185; Tue, 4 Feb 2003 08:35:12 +0200 Date: Tue, 4 Feb 2003 08:35:11 +0200 (EET) From: Pekka Savola To: Alper Yegin cc: SEND WG Subject: Re: WG Last call on draft-ietf-send-psreq-01 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk On Mon, 3 Feb 2003, Alper Yegin wrote: > Section 3.1: > "However, none of the currently standardized > automatic key distribution mechanisms work right out-of-the-box. For > further details, see [10]." > > It'd be good to expand on this statement. Especially what is missing > with the current mechanisms, and if and how SEND will fix them. > As I understand, there is not separate requirements draft, therefore > setting the scope of the work in this document is needed. Personally, I'm not sure how much one should go on about solutions, but either way works for me. > Section 3.2: > "The link layer authentication protocol MAY allow the > client nodes and the access router to create a security association. > Notice that there exists authentication protocols, e.g., variants of > EAP, that do not create secure keying material and/or do not allow > the client to authenticate the network." > > L2 authentication protocol may create a trust relation between the client > and the L2 access device, which is not generally same as the access > router. "L2 access device" could be ambiguous, I think. Perhaps that should be expanded a bit. Consider these cases: - node connected to a router - node connected to an ethernet switch connected to a router (including any L2 bridging mechanisms, such as a WLAN access point working in bridged mode) - node connected to a hub connected to an ethernet switch, ... - ... Are all of the first ones in these lists L2 access devices? > "That is, the router would check ICMPv6 packet contents, and > filter packets that contain information which does not match the > network topology." > > This approach has limitations, because not in all networks an > access router is a MitM to inter-host communication (e.g., multi-access > links). In most, it's not, but if such a mechanism is adopted, it might be possible to emulate a virtual link like that. > Section 4.1.1: > "In the case just the operator is trusted, > the nodes may rely on the operator to certify the address bindings > for other local nodes." > > Are there existing solutions like that, or is this just a speculation > that one can develop such a solution? If the draft is going to talk > about solutions, it should clarify their status (available, possible, > etc...) I'm not sure I think expansion on solutions here is a good idea. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Feb 4 11:43:46 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28162 for ; Tue, 4 Feb 2003 11:43:45 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14GjnAv002817; Tue, 4 Feb 2003 17:45:49 +0100 (MET) 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.2655.55) id DW0C92TT; Tue, 4 Feb 2003 17:45:49 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h14Gjm209893; Tue, 4 Feb 2003 17:45:48 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id RAA01123; Tue, 4 Feb 2003 17:45:16 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id RAA01010 for ; Tue, 4 Feb 2003 17:45:14 +0100 (MET) Message-ID: <004201c2cc6c$930f8f80$1d6015ac@T23KEMPF> From: "James Kempf" To: "Alper Yegin" , "SEND WG" References: Subject: Re: WG Last call on draft-ietf-send-psreq-01 Date: Tue, 4 Feb 2003 08:43:40 -0800 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 Content-Transfer-Encoding: 7bit Alper, Please look at the charter for SEND. There is no intent to do anything with manual SA configuration or key sharing. The intent is to use a reserved IPsec identifier for a public key cryptographic algorithm that can be used to verify the AH headers. The protocol work is focussing on extensions to the ND/RD protocols to allow authorization of credentials for authenticating NA and RA messages. Also, some work on backwards compatibility with existing ND. The exact relation with PANA and DHCP is under discussion. The ADs suggested we co-ordinate with the chairs. We've been discussing an algorithm for credential authorization based on well-known and highly deployed credential distribution techniques, such as are used with SSL, that might be useful for securing DHCP as well. We are not sure what the relationship with PANA might be, but we are certainly open to discussion with the chairs. jak ----- Original Message ----- From: "Alper Yegin" To: "SEND WG" Sent: Monday, February 03, 2003 5:58 PM Subject: Re: WG Last call on draft-ietf-send-psreq-01 > Hello, > > Here are some comments/questions based on my review... > > My understanding is that, there are two areas that needs to be > worked out. First one is how to secure ND using IPsec when all the > required SAs are already manually configured. I'd think the details > will be worked out in the SEND WG. Secondly, if there are no > pre-configured SAs, the methods to generate them (i.e., bootstraping) > needs to be defined. I think at this point PANA may be used as a building > block, but the details about how to turn a newly generated trust relation > (e.g., a shared secret) into the required IPsec Sas need to be worked out. > Is that a fair understanding of the scope of the work? If so, I think this > should be clarified in the document. > > Section 3.1: > "However, none of the currently standardized > automatic key distribution mechanisms work right out-of-the-box. For > further details, see [10]." > > It'd be good to expand on this statement. Especially what is missing > with the current mechanisms, and if and how SEND will fix them. > As I understand, there is not separate requirements draft, therefore > setting the scope of the work in this document is needed. > > Section 3.2: > "The link layer authentication protocol MAY allow the > client nodes and the access router to create a security association. > Notice that there exists authentication protocols, e.g., variants of > EAP, that do not create secure keying material and/or do not allow > the client to authenticate the network." > > L2 authentication protocol may create a trust relation between the client > and the L2 access device, which is not generally same as the access > router. > > "Even if the underlying link layer is aware of all the nodes' link > layer addresses, and is able to check that no source addresses were > falsified, there may still be vulnerabilities." > > I'm not sure if L2 access device checking source IP address to > prevent such atttacks are practical. Are there any such solutions? > > "That is, the router would check ICMPv6 packet contents, and > filter packets that contain information which does not match the > network topology." > > This approach has limitations, because not in all networks an > access router is a MitM to inter-host communication (e.g., multi-access > links). > > Section 4.1.1: > "In the case just the operator is trusted, > the nodes may rely on the operator to certify the address bindings > for other local nodes." > > Are there existing solutions like that, or is this just a speculation > that one can develop such a solution? If the draft is going to talk > about solutions, it should clarify their status (available, possible, > etc...) > > Section 4.2.1: > "However, the threat can be partially > mitigated through a number of means, for example, by configuring the > nodes to prefer existing routers over new ones." > > But this itself is very limiting, as now you cannot introduce a new router > to the network. (I'm not sure if visiting these possible approaches in > this draft is a good idea, because at times they open up such additonal > questions. These require more analysis that can be done later.) > > Section 4.2.6: > "2. The attacker implements a bogus DHCPv6 server or relay and the > 'M' and/or 'O' flag is set, indicating that stateful address > configuration and/or stateful configuration of other parameters > should be done. The attacker is then in a position to answer the > stateful configuration queries of a legitimate host with its own > bogus replies." > > The draft should point out if "secure" dhcp can be a solution. > > Section 4.3.1: > "In a way, this problem is fairly similar to the TCP SYN flooding > problem. Rate limitating Neighbor Solicitations, restricting the > amount of state reserved for unresolved soliciations, and clever > cache management may be applied." > > I'm not sure this solves the problem, because this still starves the > legitimate users. I think this discussions is not appropriate for this > draft. It's too much solution oriented. > > Section 4.4: > > "+ The threat is present and at least one solution is known" > > This gives the impression that there is a fully-working standard > solution to the problems. But I think what we really mean is that > there are some candidate proposals that require further analysis. > > > alper > > > > > On 1/23/03 9:32 AM, "James Kempf" wrote: > > > WG Last Call on draft-ietf-send-psreq-01.txt starts today and runs for two > > weeks, until Feb. 6. This draft is intended to be a comprehensive security > > analysis of threats to Neighbor Discovery as it currently exists today in RFCs > > 2641 and 2642, according to three different trust models that group current > > network deployments into three different equivalence classes. As such, it > > functions as a requirements template for the SEND design team. > > > > It is *extremely important* that this draft be read and commented on by the WG > > prior to submission to the IESG. Please make an effort to review the draft > > within the Last Call period, and submit any comments to the mailing list or > > the > > editor (Pekka). > > > > Text, HTML and XML versions of the draft > > are available at the interim web page: > > > > http://www.tml.hut.fi/~pnr/SEND/ > > > > The HTML version is directly available at: > > > > http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-01.html > > > > The draft was submitted to the IETF drafts respository today and should show > > up > > there shortly. > > > > 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 Tue Feb 4 13:19:15 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00450 for ; Tue, 4 Feb 2003 13:19:14 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14IMLAv014945; Tue, 4 Feb 2003 19:22:21 +0100 (MET) 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.2655.55) id D7MVPVW9; Tue, 4 Feb 2003 19:22:20 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h14IMK212104; Tue, 4 Feb 2003 19:22:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id TAA13433; Tue, 4 Feb 2003 19:21:57 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id TAA13429 for ; Tue, 4 Feb 2003 19:21:55 +0100 (MET) Date: Tue, 04 Feb 2003 10:21:26 -0800 Subject: Re: WG Last call on draft-ietf-send-psreq-01 From: Alper Yegin To: Michael Richardson , SEND WG Message-ID: In-Reply-To: <200302040259.h142xZr9005687@marajade.sandelman.ottawa.on.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > Alper> My understanding is that, there are two areas that needs to be > Alper> worked out. First one is how to secure ND using IPsec when all the > Alper> required SAs are already manually configured. I'd think the details > Alper> will be worked out in the SEND WG. Secondly, if there are no > > I think that I missed something (which is very likely, since I've been > skimming). The ND is a broadcast. How can you have a shared secret among a > group and still consider it a secret? Symmetric keys or asymmetirc keys might be used. I think first question is, if you have the right keying material in the right place, how do you use it. Second one is, how do you get the keying material there... (I think shared secret among a closed group is still a secret :) > > Or is this just to talk to the/a router? > > So, yes, I think that this is a problem. > > Alper> pre-configured SAs, the methods to generate them (i.e., bootstraping) > Alper> needs to be defined. I think at this point PANA may be used as a > building > Alper> block, but the details about how to turn a newly generated trust > relation > Alper> (e.g., a shared secret) into the required IPsec Sas need to be worked > out. > Alper> Is that a fair understanding of the scope of the work? If so, I think > this > Alper> should be clarified in the document. > > This second part - turning something you got from PANA into a IPsec level > keying material is either just a question of convention (i.e. "use bytes 0-15 > as the AES key, and bytes 16-35 as the SHA1 key"), or a matter of some > entropy expansion (assuming PANA doesn't give you enough bits, but a > reasonable amount of entropy). At least some guidlines are needed. A secret delivered/derived by the authentication method might have to be used with IKE to create the SAs. alper > > I guess I should go read more. > > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); > [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPj8slYqHRg3pndX9AQFwsgP9EC7iU4w7ShqAZ4fK1kw1ouLaW5ICLxFE > HI5Skv3CMwAfwNnkozixTpLlDHgrqBAvHAXv+vgOC/GPwg+3D2b/iq1YM3UMDAhZ > 8x/kMmuZIpxkmyFADUCUIz6DmKqg5eJ9p4t0L2/5T5pVU/zcFvnKOpyp3tXJ3LQN > n6L2a0a5G2U= > =IvDU > -----END PGP SIGNATURE----- > -------------------------------------------------------------------- > 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 Feb 4 13:25:04 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00593 for ; Tue, 4 Feb 2003 13:25:04 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14IS6KV008514; Tue, 4 Feb 2003 19:28:06 +0100 (MET) 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.2655.55) id D7MVPWZS; Tue, 4 Feb 2003 19:28:04 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h14IS3212302; Tue, 4 Feb 2003 19:28:03 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id TAA13694; Tue, 4 Feb 2003 19:27:57 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id TAA13690 for ; Tue, 4 Feb 2003 19:27:56 +0100 (MET) Date: Tue, 04 Feb 2003 10:27:23 -0800 Subject: Re: WG Last call on draft-ietf-send-psreq-01 From: Alper Yegin To: Pekka Savola CC: SEND WG Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit >> Section 3.2: >> "The link layer authentication protocol MAY allow the >> client nodes and the access router to create a security association. >> Notice that there exists authentication protocols, e.g., variants of >> EAP, that do not create secure keying material and/or do not allow >> the client to authenticate the network." >> >> L2 authentication protocol may create a trust relation between the client >> and the L2 access device, which is not generally same as the access >> router. > > "L2 access device" could be ambiguous, I think. Perhaps that should be > expanded a bit. > > Consider these cases: > > - node connected to a router > - node connected to an ethernet switch connected to a router > (including any L2 bridging mechanisms, such as a WLAN access point > working in bridged mode) > - node connected to a hub connected to an ethernet switch, ... > - ... > > Are all of the first ones in these lists L2 access devices? Except the last one.. L2 access device and the first hop router may or may not be co-located, as you illustrated above. >> Section 4.1.1: >> "In the case just the operator is trusted, >> the nodes may rely on the operator to certify the address bindings >> for other local nodes." >> >> Are there existing solutions like that, or is this just a speculation >> that one can develop such a solution? If the draft is going to talk >> about solutions, it should clarify their status (available, possible, >> etc...) > > I'm not sure I think expansion on solutions here is a good idea. > What I mean is, if the draft is going to mention solutions, it should also give some idea about whether they are standard solutions (preferably with a reference), ad-hoc solutions, or possible solutions one might develop (pending lots of details being worked out). Or else, we cannot make a good assesment of what level of attention should be given to each problem... alper -------------------------------------------------------------------- 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 Feb 4 13:51:21 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01180 for ; Tue, 4 Feb 2003 13:51:20 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14IsWKV011345; Tue, 4 Feb 2003 19:54:32 +0100 (MET) 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.2655.55) id D7MVP5H2; Tue, 4 Feb 2003 19:54:32 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h14IsVI09091; Tue, 4 Feb 2003 19:54:31 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id TAA16980; Tue, 4 Feb 2003 19:54:16 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id TAA16972 for ; Tue, 4 Feb 2003 19:54:13 +0100 (MET) Date: Tue, 04 Feb 2003 10:52:31 -0800 Subject: Re: WG Last call on draft-ietf-send-psreq-01 From: Alper Yegin To: James Kempf , SEND WG Message-ID: In-Reply-To: <004201c2cc6c$930f8f80$1d6015ac@T23KEMPF> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James, > Please look at the charter for SEND. There is no intent to do anything with > manual SA configuration or key sharing. The intent is to use a reserved IPsec > identifier for a public key cryptographic algorithm that can be used to verify > the AH headers. The protocol work is focussing on extensions to the ND/RD > protocols to allow authorization of credentials for authenticating NA and RA > messages. Also, some work on backwards compatibility with existing ND. I didn't mean to imply symmetric cryptography actually. Symmetric or public, once we have the right keying material in the right places, the details on how they will be used to secure ND is needed. And I think specifying a reserved IPsec id etc. is a part of this. The other component is, how do we get the keying material to the right places. Second item in the charter specifically mentions a key distribution protocol.. > > The exact relation with PANA and DHCP is under discussion. The ADs suggested > we > co-ordinate with the chairs. We've been discussing an algorithm for credential > authorization based on well-known and highly deployed credential distribution > techniques, such as are used with SSL, that might be useful for securing DHCP > as > well. We are not sure what the relationship with PANA might be, but we are > certainly open to discussion with the chairs. In order to "assure authenticatable distribution of public keys" in the access network, you somehow need to rely on a trust relation between the node and the access network. That relation can be potentially created by PANA when the client requests access to the network. alper > > jak > > ----- Original Message ----- > From: "Alper Yegin" > To: "SEND WG" > Sent: Monday, February 03, 2003 5:58 PM > Subject: Re: WG Last call on draft-ietf-send-psreq-01 > > >> Hello, >> >> Here are some comments/questions based on my review... >> >> My understanding is that, there are two areas that needs to be >> worked out. First one is how to secure ND using IPsec when all the >> required SAs are already manually configured. I'd think the details >> will be worked out in the SEND WG. Secondly, if there are no >> pre-configured SAs, the methods to generate them (i.e., bootstraping) >> needs to be defined. I think at this point PANA may be used as a building >> block, but the details about how to turn a newly generated trust relation >> (e.g., a shared secret) into the required IPsec Sas need to be worked out. >> Is that a fair understanding of the scope of the work? If so, I think this >> should be clarified in the document. >> >> Section 3.1: >> "However, none of the currently standardized >> automatic key distribution mechanisms work right out-of-the-box. For >> further details, see [10]." >> >> It'd be good to expand on this statement. Especially what is missing >> with the current mechanisms, and if and how SEND will fix them. >> As I understand, there is not separate requirements draft, therefore >> setting the scope of the work in this document is needed. >> >> Section 3.2: >> "The link layer authentication protocol MAY allow the >> client nodes and the access router to create a security association. >> Notice that there exists authentication protocols, e.g., variants of >> EAP, that do not create secure keying material and/or do not allow >> the client to authenticate the network." >> >> L2 authentication protocol may create a trust relation between the client >> and the L2 access device, which is not generally same as the access >> router. >> >> "Even if the underlying link layer is aware of all the nodes' link >> layer addresses, and is able to check that no source addresses were >> falsified, there may still be vulnerabilities." >> >> I'm not sure if L2 access device checking source IP address to >> prevent such atttacks are practical. Are there any such solutions? >> >> "That is, the router would check ICMPv6 packet contents, and >> filter packets that contain information which does not match the >> network topology." >> >> This approach has limitations, because not in all networks an >> access router is a MitM to inter-host communication (e.g., multi-access >> links). >> >> Section 4.1.1: >> "In the case just the operator is trusted, >> the nodes may rely on the operator to certify the address bindings >> for other local nodes." >> >> Are there existing solutions like that, or is this just a speculation >> that one can develop such a solution? If the draft is going to talk >> about solutions, it should clarify their status (available, possible, >> etc...) >> >> Section 4.2.1: >> "However, the threat can be partially >> mitigated through a number of means, for example, by configuring the >> nodes to prefer existing routers over new ones." >> >> But this itself is very limiting, as now you cannot introduce a new router >> to the network. (I'm not sure if visiting these possible approaches in >> this draft is a good idea, because at times they open up such additonal >> questions. These require more analysis that can be done later.) >> >> Section 4.2.6: >> "2. The attacker implements a bogus DHCPv6 server or relay and the >> 'M' and/or 'O' flag is set, indicating that stateful address >> configuration and/or stateful configuration of other parameters >> should be done. The attacker is then in a position to answer the >> stateful configuration queries of a legitimate host with its own >> bogus replies." >> >> The draft should point out if "secure" dhcp can be a solution. >> >> Section 4.3.1: >> "In a way, this problem is fairly similar to the TCP SYN flooding >> problem. Rate limitating Neighbor Solicitations, restricting the >> amount of state reserved for unresolved soliciations, and clever >> cache management may be applied." >> >> I'm not sure this solves the problem, because this still starves the >> legitimate users. I think this discussions is not appropriate for this >> draft. It's too much solution oriented. >> >> Section 4.4: >> >> "+ The threat is present and at least one solution is known" >> >> This gives the impression that there is a fully-working standard >> solution to the problems. But I think what we really mean is that >> there are some candidate proposals that require further analysis. >> >> >> alper >> >> >> >> >> On 1/23/03 9:32 AM, "James Kempf" wrote: >> >>> WG Last Call on draft-ietf-send-psreq-01.txt starts today and runs for two >>> weeks, until Feb. 6. This draft is intended to be a comprehensive security >>> analysis of threats to Neighbor Discovery as it currently exists today in > RFCs >>> 2641 and 2642, according to three different trust models that group current >>> network deployments into three different equivalence classes. As such, it >>> functions as a requirements template for the SEND design team. >>> >>> It is *extremely important* that this draft be read and commented on by the > WG >>> prior to submission to the IESG. Please make an effort to review the draft >>> within the Last Call period, and submit any comments to the mailing list or >>> the >>> editor (Pekka). >>> >>> Text, HTML and XML versions of the draft >>> are available at the interim web page: >>> >>> http://www.tml.hut.fi/~pnr/SEND/ >>> >>> The HTML version is directly available at: >>> >>> http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-01.html >>> >>> The draft was submitted to the IETF drafts respository today and should show >>> up >>> there shortly. >>> >>> 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Feb 6 23:41:08 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16679 for ; Thu, 6 Feb 2003 23:41:07 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h174iHAv001407; Fri, 7 Feb 2003 05:44:17 +0100 (MET) 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.2655.55) id DW0DS0C4; Fri, 7 Feb 2003 05:44:17 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h174iHI19319; Fri, 7 Feb 2003 05:44:17 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id FAA28290; Fri, 7 Feb 2003 05:43:39 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from serwer.marx.pl ([213.25.18.123]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with SMTP id FAA28286 for ; Fri, 7 Feb 2003 05:43:38 +0100 (MET) Received: from 127.0.0.2 by serwer.marx.pl (MarX-X SMTPD); id s20030207032934.1281; Fri, 07 Feb 2003 03:29:36 Message-ID: <41480-2200325722930330@mta.888.888.888.CA> To: "secured servers" From: "" Subject: =?windows-1252?Q?=BB=BB=BB=BB_Bulk_Friendly_=AB=AB=AB=AB?= Date: Thu, 6 Feb 2003 21:29:30 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id FAA28287 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit ______________________________________ Foreign Bulk Friendly smtp servers ! Your own secure smtp account ! agent@matglobal.net?subject=securedsmtp ______________________________________ What Media says about Bulk Emails.. " A goldmine for those who can take advantage of bulk email programs " - The New York Times " We have received 30 sales in emailing out only 1,000 letters " - Insurance Company " Email is an incredible lead generation tool " - Crains Magazine " We have spent a fortune in banner adverstiment and it still doesn't come close to the response that we receive with Bulk Email " - Website Owner -------------------------------------------------------------------- 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 Feb 7 07:55:39 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07942 for ; Fri, 7 Feb 2003 07:55:39 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h17CwaKV019424; Fri, 7 Feb 2003 13:58:36 +0100 (MET) 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.2655.55) id D7MWF7NC; Fri, 7 Feb 2003 13:58:35 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h17CwZ209252; Fri, 7 Feb 2003 13:58:35 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id NAA12641; Fri, 7 Feb 2003 13:58:10 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from retort.sout.netline.net.uk (retort.sout.netline.net.uk [213.40.66.77]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id NAA12637; Fri, 7 Feb 2003 13:58:09 +0100 (MET) Received: from [212.111.172.77] (helo=comp2) by retort.sout.netline.net.uk with esmtp (Exim 4.04) id 18h83p-0005fC-00; Fri, 07 Feb 2003 12:56:53 +0000 Message-ID: <41181-22003257125212830@comp2> To: "new" From: "Euromatech" Subject: Euromatech's Training Seminars Date: Fri, 7 Feb 2003 12:52:12 -00 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_94915C5ABAF209EF376268C8" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =20 =20 EUROMATECH TRAINING SEMINARS =20 Dear Colleague, Iam writing to ask for your permission to include your address on our mail= ing list, and to introduce our Company (Euromatech) and the Services we pr= ovide =2E We run around 500 Training Seminars per year in places such as Dubai, Lond= on, Kuala Lupmur, Paris and Amestrdam and cover subject areas such as Mana= gement, Finance, Engineering and Marketing=2E=20 Details of all of our Seminars can be found by visiting our web site www=2E= euromatech=2Ecom and if you wish to receive regular free updates (Weekly e= -mail announcements) on our Seminars to please reply to this message with = the word SUBSCRIBE in the subject line and if you already recieve such ann= ouncemets to please ignore this e=2Email Thank you and kind regards Susan http://www=2Eeuromatech=2Ecom info@euromatech=2Ecom If for any reason you do not wish to receive anymore e-mail announcements,= please reply with the word DELETE in the subject line=2E =20 =20 =20 =20 =20 ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Untitled Document =20 =20 =20 =20 =20 =20
     
  =20
=20

EUROMATECH=20 TRAINING SEMINARS


=20

Dear=20 Colleague,

Iam = writing=20 to ask for your permission to include your address on our ma= iling=20 list, and to introduce our Company (Euromatech) and the Serv= ices=20 we provide =2E

We r= un around=20 500 Training Seminars per year in places such as Dubai, L= ondon,=20 Kuala Lupmur, Paris and Amestrdam and cover subje= ct areas=20 such as Management, Finance, Engineering and Marketing=2E

Deta= ils of all=20 of our Seminars can be found by visiting our web site www=2Eeuromatech=2Ecom=20 and if you wish to receive regular free updates (Weekly e-ma= il announcements)=20 on our Seminars to please reply to this message with the wor= d SUBSCRIBE=20 in the subject line and if you already recieve such announce= mets=20 to please ignore this e=2Email

Than= k you and=20 kind regards

Susa= n
http://www=2Eeurom= atech=2Ecom
info@euromatech=2Ec= om

If f= or any reason=20 you do not wish to receive anymore e-mail announcements, ple= ase=20 reply with the word DELETE in the subject line=2E

=

 
   
   
   
     
------=_NextPart_84815C5ABAF209EF376268C8-- ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: image/gif; name="LOGO_sml.gif" Content-Transfer-Encoding: base64 Content-Description: LOGO_sml.gif Content-Id: <32507101-220032571246146701966@comp2> Content-Transfer-Encoding: base64 R0lGODlhfQAtAOYAAAAAhcLCwFxcXJmZme/v/CAgoGNjwuTk4Zyc1llZuUBArggIlcfH64yMjISE zZmZzHh4d9PT0a2t3u7u6Q8PlC8vpcbG5wAAmd7e8bW1tfb28GZmZrW14P///5SU1XJyxlJSuebm +Boan6WlpSkppYSEhaam2dbW79vb2Lq64szMzEpKtrq6uQAAme7u+Ds7p4yMzl9fuHp6x62trd/f 9pmZmc7O6vf3/3Nzc/f39xISoQgInCoqqhkZo2ZmZkJCs+/v742N01JSujw8sba242hovXx8ywAA jaWl3Obm5vz89mtrxN7e3hAQnjExrc/P7Tk5rZ+f21pavcXFxenp7CEhpnt7e7295b29vdbW1mJi vf4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAUUAFsALAAAAAB9AC0AAAf/gB2Cg4SFhoeIiYqLjI2Oj5CRkpOQNzeUmJmaHTcuIRhPDFccElEI HjCpqqkeHkgcKRYWJxghBIpKuUqbvJouGBYcCA4GQj9QPD06yzsXzs/Q0TvTTU09PEMgUh8wSCk2 IZeGOeS7veeGLk8SMEsrTj3N0fP09fbzTdhCMghXGOKDyOVAt8mFDSRGQPDQce+ZvAvTnEWUKG8i RIcPH9brAcVAECL/CAkk+IiADQQGnDCkN62iS4wUX0KM2JJiTJsS5+2ossKIBAwiyZFEFILIByhN GipdyrSpvSogPNgAOHJoCAkGeDjdyrVrwyZDHEwVlAMIEHO8bMjQ6rWt27dN/1ZECSFIg1lNNzgk SHpz5s2aM2VanAiYME3DfQ27bFa44rMqDk6QnQCEEocVLFlmzFhPI0ydnnFKC+03p+hoVWQAzUGF ysBHT6SQfku7dtsqQS4BOVC5kYceR2wLH+52xZMOOVBQWeRCy4XgmTeLHvz5IrQjwTVix875dOfP jR1Wv9ADCfIIB9AWCrHiSBMPEpDIl0BfVhVoiHGGD3wBCoIUKQQRDQiwSAACRo79YAER8jUoAQNS lKaYftL5tQMCHVAxxQGIaIFdFXQRcosgDkAnnASEGAAdDwBxYKI0kiFCwH3E7cBBB1kE0BshHkDT A1AdEPACBQvI0IEJAFgnnv9psyl5gQ5XDBICXyZIWYA9QgjyRIwdPHFcB0sc0dI0PSylkWc80JBD Biq8JkgIbD2TgiA0uCfDBUclYMMJJ3CwQw97nrDEFSfMEsITJtAI0QcMYGCDA0kdYeQgRgDgBCES 4CfBE5hdsEQHIYhgxCBL6HDJCV4+gUEtLnTaQxAn0ICEECSUt6cFTniwpQ0HPuNAByqMwOEgmZaG IqgLGNDBD9gpKwgH1VRJwwtVdkDDjR2ckJQOFhRyQhWSEhJCAeYN0mNECghygxNPGuHEER4MIsMR K8jgRIxI1NsBEkc4QQOo3YI6BJAYkFBtB706M8QNBwwwhZs9RnNsBxjcEiH/RDFC4QwUHSAAwA+C wHCBODzAy8kKVQApwRG/iltIxM5oMQgH0cQryJ3OHDFqByTosEICK1Ag2bhHOKuAzGACUIEgK/tI AxANZDDBIAjMM/EJFnMXowLYgRwFvYJEIYUgSCzQgwugNlH0ICIY6QLag9AgDswXpHBFlB1w/UwQ 8pr4wc0ShPBclh246IwHJ4iA9BVLYHgkaiFMUMIISQxigWfHhrBAER1otUyMQ3TdwdcrFOICFEfw MAjqVYwYVgcwOEtxBUBW7cylCixduInldjDvM38Hae1zO5+A3xHBF2JCNKVnAYGwg9yQsDN407BA EyDQG8IPX3J9xBD7gn1k//AEkNBEiA4AsEOMPMQLwwJw3xlisRdEASqQHQzxTO8f+C3ICg5IwQWa MDZBeAg7SflUB4IgggQIYnnQQNEINjCDynVAAx1gAEPkEaMbKMAZK6CLArBlgiYsAEMlKh3sLvAv 3wHAZi7gAQ/QZoEjmMcDAOAbAXrQA3E8wRkFIAADTGCCL63sCD3gkp98JQiuUWAFBeugA2LgARrs QIEfAADH9gUNKdwACDiAAAumdkEMRkEi9iPE2960gxWIgwC3CEEVKDAnir1HECeogAgCNggM8ABp IYBCDx6HLRKRoFsmwM7EPjDDQlhgARcoAJDUEi8X9CdEg7gCCQhWgGOd7v92dBmBABrQpkEkYSAe WMACrsCAVjLABrA8QQiW4AwFSCBWJ4ABuKrwhBB8AgoFeMIv2rMDI9gAFA7QwREQEAIX0CBMUuDB DohAg7dh4ANSoAENrlANQvEpCiKIgizfdgIHLIBeoWAALVZFywtUQVcnkIBsnBCoFPAACXyyAdeg AJQACAACFSSEBpiAQQmQ4EU+wsc8ePiQKnjGMz1w6Dx0UAWJmqYvzuBhmbby0M1gRwp0mcIGNjCA CLhJEFRQQeUw4Bz8VMilTZqOZkIzmJhetEKAsU5NnVEFx2VgpA7bESEOMAUUME1/xEkqbWz6jCYU AShAECUOBhCAJKhnqAH/CMDUboAAjSn1q0ptggECpgIICGCqU7CqIoCgghlMAYM3MBBfwErXtpBA BjFiwgAEsIESzCACQk1EDpiQAbf25gnuGs10uiMhnDoWPIylzkWd9AwdCGEugkDBAEZqhQFggQkn ZURKMzCCDDBBEAQgggyGMNfFJkYmjYXsa2dLoSXxNCoxAsIUGjBSCAwgAxGgwlUbkYMktHUAI5gC GW/AgCCAwKJ1BWsTnLAECbSwAygYgRU4+9vghjYSrIlABgYwALdaMEhXgEECeNDa6LqlB0NYgjjF oYEszGC7G8BBA0aAhSy4phdlYcIUZjCABnSXjEGKpwOkAA+muneAVfhB/xGCcAW5DeIAARgABEaK gxL8VgVMOMtQNECFLAy4wPtlk1rVhYErRMEB7oBCz+r6JycMIQEfgI8N4FYXFGBhBCXAQW9TDOIk BHYoF6QCClTwYxQTOcTquUEITnAFCSAABh/QghCEsIIhOIEHFdXoMnTAw4ryAAo/WMEKpLAEIwQB CURo1IgIMQEUTGEEDbCCkMPo4RlgQQXKwSCSFVGWJDCByQRugKIN/NsAgHgCw40eHH2pzVVZuha2 IABADKGBJNiZBSMYQJDzi4MOG9jPgObNdwe9iEIzwcQsmEGoG1CCWtfawCOYQQYy4OgsZIEJSQg2 EDRA7GJrYAITOAAKUJoQgSlggQWkLXAJrKDnUuPACiXAtZ+n8Gsjr5rVkiAHFZQdARUEoLChRvG0 bc3udtua2vC2AgSsDQF4Z5u8uc4AFqYQARQcwMgiBvegywKEYL86CyqYgrOhTdoRODzd5I04vh+u 6wywIKtTUIGvmfBvswhF4CAXLDnMAgQqBNvgTEi5ylcO7GAjmzICqUrIZz6JmNv85jR/RCAAADs= ------=_NextPart_94915C5ABAF209EF376268C8-- -------------------------------------------------------------------- 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 Feb 7 13:27:21 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17345 for ; Fri, 7 Feb 2003 13:27:21 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h17IUWAv017264; Fri, 7 Feb 2003 19:30:32 +0100 (MET) 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.2655.55) id DW0DZBZ5; Fri, 7 Feb 2003 19:30:32 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h17IUV218418; Fri, 7 Feb 2003 19:30:31 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id TAA23295; Fri, 7 Feb 2003 19:30:03 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id TAA23171 for ; Fri, 7 Feb 2003 19:30:01 +0100 (MET) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 7 Feb 2003 10:29:59 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Feb 2003 10:29:59 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 7 Feb 2003 10:30:05 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 7 Feb 2003 10:29:59 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3760.0); Fri, 7 Feb 2003 10:29:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last call on draft-ietf-send-psreq-01 Date: Fri, 7 Feb 2003 10:29:58 -0800 Message-ID: Thread-Topic: WG Last call on draft-ietf-send-psreq-01 Thread-Index: AcLJF1+C+goUM7RCSEehkruSHw9TJwFvpsKA From: "Dave Thaler" To: "Pekka Nikander" , "SEND WG" X-OriginalArrivalTime: 07 Feb 2003 18:29:59.0593 (UTC) FILETIME=[EBE76990:01C2CED6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id TAA23253 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit I've reviewed the document, and most of my comments relate to typos/grammar. Section 1: The purpose of this document is to define the types of networks the Secure IPv6 Neighbor Discovery mechanisms are expected to work, ----- "networks" -> "networks in which" number of threats is are discussed in the light of these trust ----- "is are" -> "are" 2: situation could induce administration hardships when events such as ----- "administration" -> "administrative" 3.1:layer is cryptographically secured to the extend needed, no other ----- "extend" -> "extent" a WLAN with 802.11i RNS/EAS may be considered secure enough, ----- don't assume people know what that is. Expand acronyms and add informative reference. (802.1x could also use an informative reference) Also, in section 3.2 the name appears as "RNS/EAP" whereas here it's EAS. I assume EAS is a typo. some or all of the threats outlined in Section 4. In such case some ----- "In such case" -> "In this case" or "In such a case" 3.2:network, e.g., a WLAN in a hotel, air port, or cafe, has a different ----- "air port" -> "airport" under one administrative domain, and the client nodes each fall under its own administrative domain. ----- "its" -> "their" or else "the client nodes each fall" -> "each client node falls" deployment, the link layer MAY take care of the mutual authentication. The link layer authentication protocol MAY allow the ----- "MAY" -> "may" in both places (this document isn't the link-layer protocol specification) Notice that there exists authentication protocols, e.g., variants of ----- "Notice" -> "Note", "exists" -> "exist" 4.1.1 messages to created bindings between IP addresses and MAC addresses. ----- "created" -> "create" (e.g. CGA) to authorize address bindings. ----- "e.g. " -> "e.g.," 4.1.2 The node first waits for a small random delay, and then sends a ----- RFC 2461 does not specify any random delay in NUD. 4.1.3 This threat involves Neighbor Solicitation/Advertisement. ---- append "messages"? (same comment in all other sections with "This threat involves...") sure that no node may allocated more than a few (hundreds of) ----- "may" -> "has". However, I think this suggestion should be removed, as there may be situations where allocating a large number is desirable (e.g. creating a separate address per TCP connection, or when running an ND proxy). In my opinion, the WG should not suggest that ISPs bound how many addresses a legitimate host can have. 4.2.4 rebooting, or the same prefix is advertised with a zero lifetime. ----- "or the" -> "or after the" This attack can be extended into a redirect attack if the tacker ----- "tacker" -> "attacker" 4.2.5 DNS based on the bogus constructed address. DNS update causes the ----- add informative reference for DNS update other IP address in the AAAA RRset, which may be correct. ----- "address in the AAAA RRset" -> "addresses registered in DNS". (omitting AAAA since it could fall back to IPv4 addresses too) There is also a related possibility of advertising the a target ----- "the a" -> "a" 4.2.7? ----- another pure ND threat is that a node may spoof messages that cause a reply (e.g., echo requests), sending them unicast to a target node. This results in a DoS attack on the target's neighbor cache just like in 4.3.1 but here the target is a host rather than a router. This is sort of mentioned at the in 4.3.1, but it should really have its own subsection under 4.2. 4.3.1 problem. Rate limitating Neighbor Solicitations, restricting the ------ "limitating" -> "limiting" 4.4 new address via DynDNS is not considered an ND security issue ------ be consistent. Here the term DynDNS is used where as in 4.2.5 it was DNS update. 6 identifying the Neighbor Discovery DOS attack. We would also like to ------ "DOS" -> "DoS" Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for ... Thanks to Alper E. Yegin, Pekka Savola and Bill Sommerfeld for their ------ be consistent with Alper's name -Dave -------------------------------------------------------------------- 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 Feb 9 15:58:08 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06226 for ; Sun, 9 Feb 2003 15:58:07 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h19L1CKV013394; Sun, 9 Feb 2003 22:01:12 +0100 (MET) 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.2655.55) id DY542R7P; Sun, 9 Feb 2003 22:01:11 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h19L1AK21345; Sun, 9 Feb 2003 22:01:10 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id WAA17422; Sun, 9 Feb 2003 22:00:16 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail1.chek.com (barney.synacor.com [208.197.227.8]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with SMTP id WAA17380 for ; Sun, 9 Feb 2003 22:00:15 +0100 (MET) Received: (qmail 27259 invoked by uid 0); 8 Feb 2003 23:13:33 -0000 Received: from machiavelli.synacor.com (10.10.6.30) by mailrelay2.synacor.com with SMTP; 8 Feb 2003 23:13:33 -0000 Received: (qmail 1808 invoked by uid 99); 8 Feb 2003 23:13:32 -0000 Date: 8 Feb 2003 23:13:32 -0000 Message-ID: <20030208231332.1807.qmail@machiavelli.synacor.com> From: "david okafor" To: david13_okafor@ny.com X-Originating-IP: [80.247.142.118] Subject: URGENT BUSINESS PROPOSAL Mime-version: 1.0 X-MASSMAIL: 1.0 X-MASSMAIL: precedence.bulk Content-Type: multipart/alternative; boundary="=====================_889472414==_" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk --=====================_889472414==_ Content-Type: text/plain Content-Transfer-Encoding: 8bit PETROLEUM (SPECIAL) TRUST FUND LAGOS-NIGERIA CONFIDENTIAL REQUEST FOR URGENT BUSINESS PROPOSAL From the Desk of: Dr.David Okafor Dear Sir, This letter may come to you as a surprise since it is coming from someone you have not met before. However, we decided to contact you based on a satisfactory information we had about you. I am a Medical Doctor currently working with the Petroleum Trust Fund (PTF). I and some of my close and trusted colleagues need your assistance in the transfer of US$21.8 million into any reliable Account you may nominate overseas. This fund was generated from over-invoicing of contracts executed by the PTF under our control and supervision. This fund is now ready to be remitted into any Account we put forward for that purpose. What we want from you is a good and reliable company or personal Account into which we shall transfer this fund. Details should include the following: 1. Name of Company, Address & Your Private Telephone & Fax Number. 2. Name of Bank & Address of Bank . 3. Account Number 4. Beneficiary Name Upon receipt of your company & bank particulars, an application shall be made in your name to the Central Bank of Nigeria for the approval of the remittance of the funds which shall be by SWIFT (Telegraphic transfer) copies of the approval and other relevant documents shall be faxed to you for your perusal.please treat as strictly confidential for obvious reasons. The fund will be shared as follows: 1. 17% for your assistance 2. 80% for myself & my Colleagues 3. 3% for contingency expenses We wish to assure you that your involvement should you decide to assist us, will be well protected, and also, this business, proposal is 100% risk free as the remittance will be made through the legal procedures. Note: your discussions regarding this transaction should be limited because we are still in government service. We intend to retire peacefully at the end of this transaction. Let honesty and trust be our watchword throughout this transaction and your prompt reply will be highly appreciated. Thank you for your anticipated cooperation while we look forward to a mutually benefiting business relationship with you. Best Regards. Dr.David Okafor 234-9-2721942{Fax} --=====================_889472414==_ Content-Type: text/html Content-Transfer-Encoding: 8bit
PETROLEUM (SPECIAL) TRUST FUND

LAGOS-NIGERIA

CONFIDENTIAL

REQUEST FOR URGENT BUSINESS PROPOSAL

From the Desk of: Dr.David Okafor

Dear Sir,
This letter may come to you as a surprise since it is coming from someone you have not met before. However, we decided to contact you based on a satisfactory information we had about you.
I am a Medical Doctor currently working with the Petroleum Trust Fund (PTF). I and some of my close and trusted colleagues need your
assistance in the transfer of US$21.8 million into any reliable Account you may nominate overseas.
This fund was generated from over-invoicing of contracts executed by the PTF under our control and supervision. This fund is now ready to be remitted into any Account we put forward for that purpose. What we want
from you is a good and reliable company or personal Account into which we shall transfer this fund. Details should include the following:
1. Name of Company, Address & Your Private Telephone & Fax Number.
2. Name of Bank & Address of Bank .
3. Account Number
4. Beneficiary Name
Upon receipt of your company & bank particulars, an application shall be made in your name to the Central Bank of Nigeria for the approval of the remittance of the funds which shall be by SWIFT (Telegraphic
transfer) copies of the approval and other relevant documents shall be faxed to you for your perusal.please treat as strictly confidential for obvious reasons. The fund will be shared as follows:
1. 17% for your assistance
2. 80% for myself & my Colleagues
3. 3% for contingency expenses
We wish to assure you that your involvement should you decide to assist us, will be well protected, and also, this business, proposal is 100%
risk free as the remittance will be made through the legal procedures.
Note: your discussions regarding this transaction should be limited because we are still in government service. We intend to retire peacefully at the end of this transaction. Let honesty and trust be our watchword throughout this transaction and your prompt reply will be highly appreciated.
Thank you for your anticipated cooperation while we look forward to a mutually benefiting business relationship with you.
Best Regards.

Dr.David Okafor
234-9-2721942{Fax}



--=====================_889472414==_-- -------------------------------------------------------------------- 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 Feb 12 04:04:46 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26696 for ; Wed, 12 Feb 2003 04:04:45 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1C97vKW005206; Wed, 12 Feb 2003 10:07:57 +0100 (MET) 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.2655.55) id 1X35YD10; Wed, 12 Feb 2003 10:07:54 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1C97sK18438; Wed, 12 Feb 2003 10:07:54 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id KAA28892; Wed, 12 Feb 2003 10:07:25 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from unknown (cr2006818591.cable.net.co [200.68.185.91]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with SMTP id KAA28867; Wed, 12 Feb 2003 10:07:12 +0100 (MET) From: Subject: Toner Cartridges For Printer, Copier And Fax Machines. Date: mar, 11 feb 2003 16:06:59 Message-Id: <56.819715.82629@unknown> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk GT TONER SUPPLIES Laser printer and computer supplies 1

GT TONER SUPPLIES
Laser printer and computer supplies
1-888-662-2256
1-866-237-7397

 

Save up to 40% from retail price on laser printer toner cartridges,
copier and fax cartridges

CHECK OUT OUR GREAT PRICES AT THE BOTTOM !

If you received this email on error, please reply to gtts002@cable.net.co with subject: REMOVE... sorry for the inconvenience.

Please forward to the person responsible for purchasing your laser printer supplies

  • Order by phone: Toll free 1-866-237-7397   Toll free 1-888-662-2256

  • Order by email:  gtts002@cable.net.co  subject: ORDER

University and/or School purchase orders WELCOME. (no credit approval required)
Pay by check, c.o.d, or purchase order (net 30 days).

WE ACCEPT ALL MAJOR CREDIT CARDS!

New! HP 4500/4550 series color cartridges in stock!

Our cartridge prices are as follows:
(please order by item number)

Item                Hewlett Packard                   Price

1 -- 92274A Toner Cartridge for LaserJet 4L, 4ML, 4P, 4MP ------------------------$47.50
2 -- C4092A Black Toner Cartridge for LaserJet 1100A, ASE, 3200SE-----------------$45.50
2A - C7115A Toner Cartridge For HP LaserJet 1000, 1200, 3330 ---------------------$55.50
2B - C7115X High Capacity Toner Cartridge for HP LaserJet 1000, 1200, 3330 -------$65.50
3 -- 92295A Toner Cartridge for LaserJet II, IID, III, IIID ----------------------$49.50
4 -- 92275A Toner Cartridge for LaserJet IIP, IIP+, IIIP -------------------------$55.50
5 -- C3903A Toner Cartridge for LaserJet 5P, 5MP, 6P, 6Pse, 6MP, 6Pxi ------------$46.50
6 -- C3909A Toner Cartridge for LaserJet 5Si, 5SiMX, 5Si Copier, 8000 ------------$92.50
7 -- C4096A Toner Cartridge for LaserJet 2100, 2200DSE, 2200DTN ------------------$72.50
8 - C4182X UltraPrecise High Capacity Toner Cartridge for LaserJet 8100 Series---$125.50
9 -- C3906A Toner Cartridge for LaserJet 5L, 5L Xtra, 6Lse, 6L, 6Lxi, 3100se------$42.50
9A - C3906A Toner Cartridge for LaserJet 3100, 3150 ------------------------------$42.50
10 - C3900A Black Toner Cartridge for HP LaserJet 4MV, 4V ------------------------$89.50
11 - C4127A Black Toner Cartridge for LaserJet 4000SE, 4000N, 4000T, 4000TN ------$76.50
11A- C8061A Black Laser Toner for HP LaserJet 4100, 4100N ------------------------$76.50
11B- C8061X High Capacity Toner Cartridge for LJ4100, 4100N ----------------------$85.50
11C- C4127X High Capacity Black Cartridge for LaserJet 4000SE,4000N,4000T,4000TN -$84.50
12 - 92291A Toner Cartridge for LaserJet IIISi, 4Si, 4SiMX -----------------------$57.50
13 - 92298A Toner Cartridge for LaserJet 4, 4 Plus, 4M, 4M Plus, 5, 5se, 5M, 5N --$46.50
14 - C4129X High Capacity Black Toner Cartridge for LaserJet 5000N ---------------$97.50
15 - LASERFAX 500, 700 (FX1) -----------------------------------------------------$49.00
16 - LASERFAX 5000, 7000 (FX2) ---------------------------------------------------$54.00
17 - LASERFAX (FX3) --------------------------------------------------------------$49.00
18 - LASERFAX (FX4) --------------------------------------------------------------$49.00

Item            Hewlett Packard - Color                   Price

C1 -- C4194a Toner Cartridge, Yellow (color lj 4500/4550 series)------------------ $ 89.50
C2 -- C4193a Toner Cartridge, Magenta (color lj 4500/4550 series)----------------- $ 89.50
C3 -- C4192a toner cartridge, cyan (color lj 4500/4550 series)-------------------- $ 89.50
C4 -- c4191a toner cartridge, black (color lj 4500/4550 series)------------------- $ 74.50

Item                    Lexmark                         Price

19 - 1380520 High Yield Black Laser Toner for 4019, 4019E, 4028, 4029, 6, 10, 10L -- $109.50
20 - 1382150 High Yield Toner for 3112, 3116, 4039-10+, 4049- Model 12L,16R, Optra - $109.50
21 - 69G8256 Laser Cartridge for Optra E, E+, EP, ES, 4026, 4026 (6A,6B,6D,6E)  ---- $ 49.00
22 - 13T0101 High Yield Toner Cartridge for Lexmark Optra E310, E312, E312L -------- $ 89.00
23 - 1382625 High-Yield Laser Toner Cartridge for Lexmark Optra S (4059) ----------- $129.50
24 - 12A5745 High Yield Laser Toner for Lexmark Optra T610, 612, 614 (4069) -------- $165.00

Item                Epson                     Price

25 ---- S051009 Toner Cartridge for Epson EPL7000, 7500, 8000+ - $115.50
25A --- S051009 LP-3000 PS 7000 -------------------------------- $115.50
26 ---- AS051011 Imaging Cartridge for ActionLaser-1000, 1500 -- $ 99.50
26A --- AS051011 EPL-5000, EPL-5100, EPL-5200 ------------------ $ 99.50

Item            Panasonic                Price

27 ------Nec series 2 models 90 and 95 ---------------------- $109.50

Item                     Apple                                Price

28 ---- 2473G/A Laser Toner for LaserWriter Pro 600, 630, LaserWriter 16/600 PS - $ 57.50
29 ---- 1960G/A Laser Toner for Apple LaserWriter Select, 300, 310, 360 --------- $ 71.50
30 ---- M0089LL/A Toner Cartridge for Laserwriter 300, 320 (74A) ---------------- $ 52.50
31 ---- M6002 Toner Cartridge for Laserwriter IINT, IINTX, IISC, IIF, IIG (95A) - $ 47.50
31A --- M0089LL/A Toner Cartridge for Laserwriter LS, NT, NTR, SC (75A) --------- $ 55.50
32 ---- M4683G/A Laser Toner for LaserWriter 12, 640PS -------------------------- $ 85.50

Item                Canon                           Price

33 --- Fax CFX-L3500, CFX-4000 CFX-L4500, CFX-L4500IE & IF FX3 ----------- $ 49.50
33A -- L-250, L-260i, L-300 FX3 ------------------------------------------ $ 49.50
33B -- LASER CLASS 2060, 2060P, 4000 FX3 --------------------------------- $ 49.50
34 --- LASER CLASS 5000, 5500, 7000, 7100, 7500, 6000 FX2 ---------------- $ 49.50
34A ---LBP-200V, LBP-8 II, IIR, IIIT, IIIR EP-S--------------------------- $ 49.50
35 --- FAX 5000 FX2 ------------------------------------------------------ $ 49.50
36 --- LASER CLASS 8500, 9000, 9000L, 9000MS, 9500, 9500 MS, 9500 S FX4 -- $ 49.50
36A -- Fax L700,720,760,770,775,777,780,785,790, & L3300 FX1 ------------- $ 49.50
36B -- L-800, L-900 FX4 -------------------------------------------------- $ 49.50
37 --- A30R Toner Cartridge for PC-6, 6RE, 7, 11, 12 --------------------- $ 59.50
38 --- E-40 Toner Cartridge for PC-720, 740, 770, 790,795, 920, 950, 980 - $ 85.50
38A -- E-20 Toner Cartridge for PC-310, 325, 330, 330L, 400, 420, 430 ---- $ 85.50

Item   Xerox    Price

39 ---- 6R900 75A ---- $ 55.50
40 ---- 6R903 98A ---- $ 46.50
41 ---- 6R902 95A ---- $ 49.50
42 ---- 6R901 91A ---- $ 65.50
43 ---- 6R908 06A ---- $ 42.50
44 ---- 6R899 74A ---- $ 47.50
45 ---- 6R928 96A ---- $ 72.50
46 ---- 6R926 27X ---- $ 84.50
47 ---- 6R906 09A ---- $ 92.50
48 ---- 6R907 4MV ---- $ 89.50
49 ---- 6R905 03A ---- $ 46.50

call toll free 1-866-237-7397

30 Day unlimited warranty included on all products
GT Toner Supplies guarantees these cartridges to be free from defects in workmanship and material.

We look forward in doing business with you.

Customer  Satisfaction guaranteed !

If you are ordering by e-mail (subject:order) or c.o.d. please fill out an order
form with the following information:              

phone number
company name
first and last name
street address
city, state zip code         Order Now call toll free 1-866-237-7397

If you are ordering by purchase order please fill out an order form
with the following information:           

purchase order number
phone number
company or school name
shipping address and billing address
city, state zip code         Order Now call toll free 1-866-237-7397

All trade marks and brand names listed above are property of the respective
holders and used for descriptive purposes only.

 -------------------------------------------------------------------- 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 Feb 12 08:40:49 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02327 for ; Wed, 12 Feb 2003 08:40:49 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CDi9KV025451; Wed, 12 Feb 2003 14:44:09 +0100 (MET) 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.2655.55) id 1XQVS0FT; Wed, 12 Feb 2003 14:44:08 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1CDi8K28781; Wed, 12 Feb 2003 14:44:08 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id OAA03147; Wed, 12 Feb 2003 14:43:34 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id OAA03143 for ; Wed, 12 Feb 2003 14:43:33 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6ADF41C; Wed, 12 Feb 2003 15:52:03 +0200 (EET) Message-ID: <3E4A4F79.1040304@nomadiclab.com> Date: Wed, 12 Feb 2003 15:43:21 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPV6 WG Cc: SEND WG Subject: Reason for the explicit link-layer address options in ND? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On the behalf of the SEND DT, I'd like to get a clarification to the current ND design from those who were around back when RFC2461 and RFC2462 were written. Specifically, we'd like the know the exact reasons why RFC2461 uses separate source/target link layer address options instead of relying on the actual source link layer addresses used in the link layer frame? Furthermore, why are the actual link layer addresses used in the link layer frame completely ignored, and not checked to match with the options? Is this just a layering question, an attempt to avoid layer violations? Or were there behind other goals, like allowing proxy ND? The reason why I am asking this is that the current situation makes security design tricky. That is, the Secure ND part of SEND (as opposed to Secure RD) is all about creating a secure binding between an IP address and a link layer address. The WG decided to pursue the idea of using public key based AH to secure the NA (and NS) messages. That requires that the hosts learn the public keys of the other hosts on the local link. Basically, there are two know methods for distributing the public keys: Using certificates and relying on a (local) CA, or using Cryptographically Generated Addresses (CGA). Now, for zero-config operation, we would like to use the CGA ideas. Furthermore, there is a possible attack against link local addresses, and that attack can be partially dwarfed if we bind both the link layer address and the public key to the IP address in CGA. Under the current design, the CGA processing at the AH layer becomes very tricky, if we attempt to include the link layer address into the CGA process. --Pekka Nikander -------------------------------------------------------------------- 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 Feb 12 09:27:55 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03546 for ; Wed, 12 Feb 2003 09:27:54 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CEVDKV010146; Wed, 12 Feb 2003 15:31:13 +0100 (MET) 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.2655.55) id 1XQVTLTV; Wed, 12 Feb 2003 15:31:12 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1CEVC229364; Wed, 12 Feb 2003 15:31:12 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id PAA10184; Wed, 12 Feb 2003 15:30:55 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id PAA10179 for ; Wed, 12 Feb 2003 15:30:53 +0100 (MET) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 81E7F902E; Wed, 12 Feb 2003 09:30:52 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 09:30:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reason for the explicit link-layer address options in ND? Date: Wed, 12 Feb 2003 09:30:51 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> Thread-Topic: Reason for the explicit link-layer address options in ND? Thread-Index: AcLSnUu7enGrxmChQgmQ6/1J2n4lRwAAmKqA From: "Bound, Jim" To: "Pekka Nikander" , "IPV6 WG" Cc: "SEND WG" X-OriginalArrivalTime: 12 Feb 2003 14:30:52.0421 (UTC) FILETIME=[58637350:01C2D2A3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id PAA10180 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Hi Pekka, I can give you one answer and recall the discussion very well in Cambridge MA well at an early interim IPng WG meeting (~1995) and this is where we agreed to solicited node mulitcast archictecture principle, as a note too. For Neighbor Discovery (ND) RFC 2461: IPv4 and OSI too and many other previous implementations of a Internet like network paradigm relied on address resoluton and node discovery at the link layer of the network stack in conjunction with peeking at the link layer (e.g. ARP, ES-IS, Novell IPX). With IPv6 the ICMP Layer, Router Redirects, and ARP-Like funcitons were brought up to be part of the IP layer processing, which is one of the clear advantages of IPv6 IMO that we often don't tout (though steve brings this point out in his masters and other talks). There is an architecture and implementation reason. Architecturally this affords ND to be part of the IP(v6) layer and part of the extensibility of that architecture as required (e.g. new ICMP types, Routing Options, Destination Options). This can be seen from the DNS Discovery deliberation and suggestion to use new ICMP type for finding ones DNS server on a stateless network. It can be seen in Next Header chain. With ARP or ES-IS this was not possible. In those archictectures the address resolution and node discovery are disjoint from the actual "virtual" layer 3 processing. From implementation perspective it supports the principle of cohesiveness when building the network subsystem. What this means is that the code points for IP processing are now integral to the ND methods and concepts like NUD and prefix assimilation from ND are now part of the IP stack code base. NUD and prefix assimilation (just two examples as a note) are part of ND architecture and support that principle. The "implementors" of IPv6 and SIP (initial predecessor to IPv6 and IPng choice) learned the implementation advantages of ND methods and its place in the IPv6 architecture over implementations they had done for ARP and ES-IS. So it was a win for the Architecture, Implemenation, and combined the best from multiple methods previously done for address resolution, node discovery, and router redirects. The last win was only possible by integrating into the the IP layer. IPv6 Stateless Autoconfiguration RFC 2462. This just adhered to the base packet types of ND and then added the processes. The reason the link layer addresses are options was to permit extensibility for ND and Autoconfig to be extensible to the win list above of which address resolution and node discovery were only part. Another reason is support future models for proxy and passing link-layer addresses to those node (e.g. Mobile IPv6 HA proxy). Another reason was to support the use of the Override bit which can be part of address resolution and node discovery during first phase when link-layer addresses are not shared or to inform implementation this is temporary do not update your NUD cache. The reason for not peeking at the link layer in ND or Autoconfig is separation of function within the IP architecture. There is no requirement for this in previous models like ARP and ES-IS. If you look at public domain network kernel implementations of BSD or Linux derivations you will see the Ether (*) routines exist and for multiple adapter types. Also you might want to look at the various IPv6 over Foo specs that deal with how to deal with different link layer types. The check with the link-layer is a link layer function not an IP layer issue. In fact it is done on most implementations before the packet comes off the interrupt queue to hit the IP layer. Lastly if there is a bug here it would be caught in the NUD state machine and time out. Regards, /jim >-----Original Message----- >From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >Sent: Wednesday, February 12, 2003 8:43 AM >To: IPV6 WG >Cc: SEND WG >Subject: Reason for the explicit link-layer address options in ND? > > >On the behalf of the SEND DT, I'd like to get >a clarification to the current ND design from >those who were around back when RFC2461 and >RFC2462 were written. > >Specifically, we'd like the know the exact >reasons why RFC2461 uses separate source/target link >layer address options instead of relying on the >actual source link layer addresses used in the >link layer frame? Furthermore, why are the actual >link layer addresses used in the link layer frame >completely ignored, and not checked to match with >the options? > >Is this just a layering question, an attempt to >avoid layer violations? Or were there behind >other goals, like allowing proxy ND? > >The reason why I am asking this is that the current >situation makes security design tricky. That is, >the Secure ND part of SEND (as opposed to Secure RD) >is all about creating a secure binding between an IP >address and a link layer address. > >The WG decided to pursue the idea of using public >key based AH to secure the NA (and NS) messages. >That requires that the hosts learn the public keys >of the other hosts on the local link. Basically, >there are two know methods for distributing the >public keys: Using certificates and relying on >a (local) CA, or using Cryptographically Generated >Addresses (CGA). > >Now, for zero-config operation, we would like to >use the CGA ideas. Furthermore, there is a possible >attack against link local addresses, and that attack >can be partially dwarfed if we bind both the link >layer address and the public key to the IP address >in CGA. > >Under the current design, the CGA processing at the >AH layer becomes very tricky, if we attempt to include >the link layer address into the CGA process. > >--Pekka Nikander > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.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 Wed Feb 12 09:58:30 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05217 for ; Wed, 12 Feb 2003 09:58:29 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CF0cKV020256; Wed, 12 Feb 2003 16:00:38 +0100 (MET) 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.2655.55) id 1XT3YK7Y; Wed, 12 Feb 2003 16:00:38 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1CF0aK01249; Wed, 12 Feb 2003 16:00:36 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id QAA12812; Wed, 12 Feb 2003 16:00:12 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id QAA12771 for ; Wed, 12 Feb 2003 16:00:11 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1CF07h01018; Wed, 12 Feb 2003 16:00:07 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h1CEwIof095565; Wed, 12 Feb 2003 15:58:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302121458.h1CEwIof095565@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? In-reply-to: Your message of Wed, 12 Feb 2003 15:43:21 +0200. <3E4A4F79.1040304@nomadiclab.com> Date: Wed, 12 Feb 2003 15:58:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk In your previous mail you wrote: Is this just a layering question, an attempt to avoid layer violations? Or were there behind other goals, like allowing proxy ND? => both reasons. In the same kind of design ideas, it is forbidden to mix unicast and multicast between layers, i.e., if the IPv6 destination is unicast, the link-layer destination MUST be unicast, and same with multicast in place of unicast. The reason why I am asking this is that the current situation makes security design tricky. That is, the Secure ND part of SEND (as opposed to Secure RD) is all about creating a secure binding between an IP address and a link layer address. => this problem is the same than creating a secure binding between a DNS name and an IP address (i.e., the DNSSEC one). The WG decided to pursue the idea of using public key based AH to secure the NA (and NS) messages. That requires that the hosts learn the public keys of the other hosts on the local link. Basically, there are two know methods for distributing the public keys: Using certificates and relying on a (local) CA, or using Cryptographically Generated Addresses (CGA). => I stronly disagree: CGAs are very different: they don't provide authentication, only ownership. And there is a third way, Key-Based Addresses (KBA), i.e., the opposite of CGAs. Now, for zero-config operation, we would like to use the CGA ideas. Furthermore, there is a possible attack against link local addresses, and that attack can be partially dwarfed if we bind both the link layer address and the public key to the IP address in CGA. Under the current design, the CGA processing at the AH layer becomes very tricky, if we attempt to include the link layer address into the CGA process. => I don't understand your problem: with public keys you can sign NAs so secure the IPv6 to link-layer address binding. To secure the reverse binding we can reuse inverse ND (RFC 3122). So the only issue (:-) is the public key distribution... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Feb 12 12:11:01 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09042 for ; Wed, 12 Feb 2003 12:11:00 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CHEEAv009632; Wed, 12 Feb 2003 18:14:14 +0100 (MET) 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.2655.55) id 1XQV4VBC; Wed, 12 Feb 2003 18:14:14 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1CHEAK11903; Wed, 12 Feb 2003 18:14:10 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id SAA29054; Wed, 12 Feb 2003 18:13:51 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id SAA29049 for ; Wed, 12 Feb 2003 18:13:49 +0100 (MET) Message-ID: <00e301c2d2b9$d91c2bc0$846015ac@T23KEMPF> From: "James Kempf" To: "Bound, Jim" , "Pekka Nikander" , "IPV6 WG" Cc: "SEND WG" References: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> Subject: Re: Reason for the explicit link-layer address options in ND? Date: Wed, 12 Feb 2003 09:11:55 -0800 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 Content-Transfer-Encoding: 7bit But isn't there a simple attack in which the attacker sends an NA message out with the victim's link layer address in the option but its own address on the frame? Naturally, if the link layer allows the attacker to send out frames under a false address, it could fully spoof the victim as well. jak ----- Original Message ----- From: "Bound, Jim" To: "Pekka Nikander" ; "IPV6 WG" Cc: "SEND WG" Sent: Wednesday, February 12, 2003 6:30 AM Subject: RE: Reason for the explicit link-layer address options in ND? > Hi Pekka, > > I can give you one answer and recall the discussion very well in > Cambridge MA well at an early interim IPng WG meeting (~1995) and this > is where we agreed to solicited node mulitcast archictecture principle, > as a note too. > > For Neighbor Discovery (ND) RFC 2461: > IPv4 and OSI too and many other previous implementations of a Internet > like network paradigm relied on address resoluton and node discovery at > the link layer of the network stack in conjunction with peeking at the > link layer (e.g. ARP, ES-IS, Novell IPX). With IPv6 the ICMP Layer, > Router Redirects, and ARP-Like funcitons were brought up to be part of > the IP layer processing, which is one of the clear advantages of IPv6 > IMO that we often don't tout (though steve brings this point out in his > masters and other talks). There is an architecture and implementation > reason. > > Architecturally this affords ND to be part of the IP(v6) layer and part > of the extensibility of that architecture as required (e.g. new ICMP > types, Routing Options, Destination Options). This can be seen from the > DNS Discovery deliberation and suggestion to use new ICMP type for > finding ones DNS server on a stateless network. It can be seen in Next > Header chain. With ARP or ES-IS this was not possible. In those > archictectures the address resolution and node discovery are disjoint > from the actual "virtual" layer 3 processing. > > >From implementation perspective it supports the principle of > cohesiveness when building the network subsystem. What this means is > that the code points for IP processing are now integral to the ND > methods and concepts like NUD and prefix assimilation from ND are now > part of the IP stack code base. NUD and prefix assimilation (just two > examples as a note) are part of ND architecture and support that > principle. The "implementors" of IPv6 and SIP (initial predecessor to > IPv6 and IPng choice) learned the implementation advantages of ND > methods and its place in the IPv6 architecture over implementations they > had done for ARP and ES-IS. > > So it was a win for the Architecture, Implemenation, and combined the > best from multiple methods previously done for address resolution, node > discovery, and router redirects. The last win was only possible by > integrating into the the IP layer. > > IPv6 Stateless Autoconfiguration RFC 2462. > This just adhered to the base packet types of ND and then added the > processes. > > The reason the link layer addresses are options was to permit > extensibility for ND and Autoconfig to be extensible to the win list > above of which address resolution and node discovery were only part. > Another reason is support future models for proxy and passing link-layer > addresses to those node (e.g. Mobile IPv6 HA proxy). Another reason was > to support the use of the Override bit which can be part of address > resolution and node discovery during first phase when link-layer > addresses are not shared or to inform implementation this is temporary > do not update your NUD cache. > > The reason for not peeking at the link layer in ND or Autoconfig is > separation of function within the IP architecture. There is no > requirement for this in previous models like ARP and ES-IS. If you look > at public domain network kernel implementations of BSD or Linux > derivations you will see the Ether (*) routines exist and for multiple > adapter types. Also you might want to look at the various IPv6 over Foo > specs that deal with how to deal with different link layer types. The > check with the link-layer is a link layer function not an IP layer > issue. In fact it is done on most implementations before the packet > comes off the interrupt queue to hit the IP layer. > > Lastly if there is a bug here it would be caught in the NUD state > machine and time out. > > Regards, > /jim > > > > > >-----Original Message----- > >From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > >Sent: Wednesday, February 12, 2003 8:43 AM > >To: IPV6 WG > >Cc: SEND WG > >Subject: Reason for the explicit link-layer address options in ND? > > > > > >On the behalf of the SEND DT, I'd like to get > >a clarification to the current ND design from > >those who were around back when RFC2461 and > >RFC2462 were written. > > > >Specifically, we'd like the know the exact > >reasons why RFC2461 uses separate source/target link > >layer address options instead of relying on the > >actual source link layer addresses used in the > >link layer frame? Furthermore, why are the actual > >link layer addresses used in the link layer frame > >completely ignored, and not checked to match with > >the options? > > > >Is this just a layering question, an attempt to > >avoid layer violations? Or were there behind > >other goals, like allowing proxy ND? > > > >The reason why I am asking this is that the current > >situation makes security design tricky. That is, > >the Secure ND part of SEND (as opposed to Secure RD) > >is all about creating a secure binding between an IP > >address and a link layer address. > > > >The WG decided to pursue the idea of using public > >key based AH to secure the NA (and NS) messages. > >That requires that the hosts learn the public keys > >of the other hosts on the local link. Basically, > >there are two know methods for distributing the > >public keys: Using certificates and relying on > >a (local) CA, or using Cryptographically Generated > >Addresses (CGA). > > > >Now, for zero-config operation, we would like to > >use the CGA ideas. Furthermore, there is a possible > >attack against link local addresses, and that attack > >can be partially dwarfed if we bind both the link > >layer address and the public key to the IP address > >in CGA. > > > >Under the current design, the CGA processing at the > >AH layer becomes very tricky, if we attempt to include > >the link layer address into the CGA process. > > > >--Pekka Nikander > > > > > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > 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 Feb 12 12:32:46 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09619 for ; Wed, 12 Feb 2003 12:32:45 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CHZuAv012484; Wed, 12 Feb 2003 18:35:56 +0100 (MET) 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.2655.55) id 1XQV4Y8W; Wed, 12 Feb 2003 18:35:56 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1CHZuK12382; Wed, 12 Feb 2003 18:35:56 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id SAA02468; Wed, 12 Feb 2003 18:35:37 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id SAA02464 for ; Wed, 12 Feb 2003 18:35:36 +0100 (MET) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8627489B1; Wed, 12 Feb 2003 12:35:35 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 12:35:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reason for the explicit link-layer address options in ND? Date: Wed, 12 Feb 2003 12:35:34 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED8@tayexc13.americas.cpqcorp.net> Thread-Topic: Reason for the explicit link-layer address options in ND? Thread-Index: AcLSuhpS0mGHyhQiQc+SmibvXvgJtAAAcV+g From: "Bound, Jim" To: "James Kempf" , "Pekka Nikander" , "IPV6 WG" Cc: "SEND WG" X-OriginalArrivalTime: 12 Feb 2003 17:35:35.0471 (UTC) FILETIME=[2666ABF0:01C2D2BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id SAA02465 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit >But isn't there a simple attack in which the attacker sends an >NA message out with the victim's link layer address in the >option but its own address on the frame? Naturally, if the >link layer allows the attacker to send out frames under a >false address, it could fully spoof the victim as well. Yes but it will be found out with first packet to that node because it will not be delivered and time out and removed from the cache of the victim worst case. Best case the disconnect between Ehterlike (*) and IP layer will catch it immediately. But it is a clear DOS and can happen in ARP, ES-IS, et al. I would argue if this is a problem then IPsec can be used before ICMP in ND. And this has been implemented by some. I would think most SA verification code happens at the IP layer when the packet is received by routine like ip_input (v4 or v6) and IPsec mandates all packets be checked for SA. Now a bad person could still do this with IPsec if they got the key, received authorization from the authority etc. But there will be no perfect security ever IMO. The other point is except for the mobile nodes roaming the link is secure at layer -0 (the link in the building and your not allowed in the building without an identification per the armed guards). But for public links this is an issue and for wireless nodes but that is the work for SEND to do is my belief. I think you need to look at using IPsec as one method. But redefining the ND or Addrconf architecture should not be in the SEND charter. Regards, /jim -------------------------------------------------------------------- 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 Feb 12 12:51:02 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10026 for ; Wed, 12 Feb 2003 12:51:01 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CHsOAv014792; Wed, 12 Feb 2003 18:54:24 +0100 (MET) 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.2655.55) id 1XQV46X0; Wed, 12 Feb 2003 18:54:24 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1CHsOK12873; Wed, 12 Feb 2003 18:54:24 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id SAA04171; Wed, 12 Feb 2003 18:54:07 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id SAA04167 for ; Wed, 12 Feb 2003 18:54:05 +0100 (MET) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA22090; Wed, 12 Feb 2003 09:54:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1CHs2o02435; Wed, 12 Feb 2003 09:54:02 -0800 X-mProtect: <200302121754> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdo4SYwW; Wed, 12 Feb 2003 09:54:00 PST Message-ID: <3E4A8AB9.4000406@iprg.nokia.com> Date: Wed, 12 Feb 2003 09:56:09 -0800 From: "Fred L. 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: Francis Dupont CC: Pekka Nikander , IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? References: <200302121458.h1CEwIof095565@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > Is this just a layering question, an attempt to > avoid layer violations? Or were there behind > other goals, like allowing proxy ND? > > => both reasons. In the same kind of design ideas, it is > forbidden to mix unicast and multicast between layers, i.e., > if the IPv6 destination is unicast, the link-layer destination > MUST be unicast, and same with multicast in place of unicast. Can you point me to the text that forbids this? I was under the impression that multicast emulation mechanisms (e.g. MARS, etc.) use unicast link-layer destination addresses when the IPv6 destination is multicast. The whole point of multicast emulation is to propagate network-layer multicasts over unicast-only link layers - not true? 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 Wed Feb 12 15:09:30 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14380 for ; Wed, 12 Feb 2003 15:09:29 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CKC6KV015355; Wed, 12 Feb 2003 21:12:06 +0100 (MET) 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.2655.55) id 1XQVVMX0; Wed, 12 Feb 2003 21:12:06 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1CKC5K16190; Wed, 12 Feb 2003 21:12:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id VAA19726; Wed, 12 Feb 2003 21:11:41 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from p2.piuha.net ([131.160.192.2]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id VAA19721 for ; Wed, 12 Feb 2003 21:11:40 +0100 (MET) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4F40E6A907; Wed, 12 Feb 2003 22:11:35 +0200 (EET) Message-ID: <3E4AAA64.60802@kolumbus.fi> Date: Wed, 12 Feb 2003 22:11:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: James Kempf , Pekka Nikander , IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? References: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED8@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Bound, Jim wrote: > But it is a clear DOS and can happen in ARP, ES-IS, et al. I would > argue if this is a problem then IPsec can be used before ICMP in ND. > And this has been implemented by some. I would think most SA > verification code happens at the IP layer when the packet is received by > routine like ip_input (v4 or v6) and IPsec mandates all packets be > checked for SA. Yes, though you run into a couple of practical problems when you actually try to do this, namely problems getting IKE to run before you can send UDP packets, and the relatively large number of manual SAs if manual keying is used (2*n+2 SAs per node where n is the number of interface ids on the network, or something like that). > The other point is except for the mobile nodes roaming the link is > secure at layer -0 (the link in the building and your not allowed in the > building without an identification per the armed guards). But for > public links this is an issue and for wireless nodes but that is the > work for SEND to do is my belief. I think you need to look at using > IPsec as one method. But redefining the ND or Addrconf architecture > should not be in the SEND charter. Exactly, so that's why SEND is actually trying to use IPsec and Pekka is asking clarifications on why certain things are like they are in ND. We are working on the problems mentioned above. Work still remains, as you can see one of the issues we are thinking about is the relevance of link layer addresses and what checks are necessary or possible. 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 Feb 12 16:42:50 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16653 for ; Wed, 12 Feb 2003 16:42:49 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CLjiAv004947; Wed, 12 Feb 2003 22:45:44 +0100 (MET) 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.2655.55) id 1XSZZQRX; Wed, 12 Feb 2003 22:45:44 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1CLjh216505; Wed, 12 Feb 2003 22:45:43 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id WAA00717; Wed, 12 Feb 2003 22:45:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id WAA00626 for ; Wed, 12 Feb 2003 22:45:18 +0100 (MET) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 12 Feb 2003 13:45:12 -0800 Reply-To: From: "Tony Hain" To: "'Fred L. Templin'" , "'Francis Dupont'" Cc: "'Pekka Nikander'" , "'IPV6 WG'" , "'SEND WG'" Subject: RE: Reason for the explicit link-layer address options in ND? Date: Wed, 12 Feb 2003 13:45:02 -0800 Message-ID: <01e801c2d2df$fffaed50$b8a623c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <3E4A8AB9.4000406@iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id WAA00683 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit There is an explicit unjustified one-liner in 1812 (pg 34): A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address. While it is clearly the intent of the security do-gooders to avoid arp cache pollution as a dos tool, there is a vast difference between 'SHOULD NOT do this without explicit intent', and 'MUST NOT do this'. As you point out there are cases where multicast over unicast makes sense, and there are cases where IP-anycast over multicast link layer make sense for load sharing. Unfortunately, the line above ends up as the basis for declarations that the types have to match. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Fred L. Templin > Sent: Wednesday, February 12, 2003 9:56 AM > To: Francis Dupont > Cc: Pekka Nikander; IPV6 WG; SEND WG > Subject: Re: Reason for the explicit link-layer address options in ND? > > > Francis Dupont wrote: > > In your previous mail you wrote: > > > > Is this just a layering question, an attempt to > > avoid layer violations? Or were there behind > > other goals, like allowing proxy ND? > > > > => both reasons. In the same kind of design ideas, it is > forbidden to > > mix unicast and multicast between layers, i.e., if the IPv6 > > destination is unicast, the link-layer destination MUST be unicast, > > and same with multicast in place of unicast. > > Can you point me to the text that forbids this? I was under > the impression that multicast emulation mechanisms (e.g. > MARS, etc.) use unicast link-layer destination addresses when > the IPv6 destination is multicast. The whole point of > multicast emulation is to propagate network-layer multicasts > over unicast-only link layers - not true? > > Thanks, > > Fred > ftemplin@iprg.nokia.com > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.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 Thu Feb 13 01:00:16 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25385 for ; Thu, 13 Feb 2003 01:00:15 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1D63LKV003838; Thu, 13 Feb 2003 07:03:21 +0100 (MET) 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.2655.55) id 1X350FN8; Thu, 13 Feb 2003 07:03:20 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1D63KK28054; Thu, 13 Feb 2003 07:03:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id HAA11649; Thu, 13 Feb 2003 07:02:48 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id HAA11644 for ; Thu, 13 Feb 2003 07:02:47 +0100 (MET) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C689360D0; Thu, 13 Feb 2003 01:02:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 01:02:45 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reason for the explicit link-layer address options in ND? X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 01:02:45 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06DD@tayexc13.americas.cpqcorp.net> Thread-Topic: Reason for the explicit link-layer address options in ND? Thread-Index: AcLS0vZvHDnFRzSNRdirGAaY3VTo/gAUhLZA From: "Bound, Jim" To: "Jari Arkko" Cc: "James Kempf" , "Pekka Nikander" , "IPV6 WG" , "SEND WG" X-OriginalArrivalTime: 13 Feb 2003 06:02:45.0771 (UTC) FILETIME=[875795B0:01C2D325] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id HAA11645 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Jari, > > > But it is a clear DOS and can happen in ARP, ES-IS, et al. I would > > argue if this is a problem then IPsec can be used before > ICMP in ND. > > And this has been implemented by some. I would think most SA > > verification code happens at the IP layer when the packet > is received > > by routine like ip_input (v4 or v6) and IPsec mandates all > packets be > > checked for SA. > > Yes, though you run into a couple of practical problems when > you actually try to do this, namely problems getting IKE to > run before you can send UDP packets, and the relatively large > number of manual SAs if manual keying is used (2*n+2 SAs per > node where n is the number of interface ids on the network, > or something like that). The IKE UDP issue is only an implementation issue the spec works. We have known this about manual keying since the beginnning. IPsec will work and with IKE. > > > The other point is except for the mobile nodes roaming the link is > > secure at layer -0 (the link in the building and your not > allowed in > > the building without an identification per the armed > guards). But for > > public links this is an issue and for wireless nodes but > that is the > > work for SEND to do is my belief. I think you need to look > at using > > IPsec as one method. But redefining the ND or Addrconf architecture > > should not be in the SEND charter. > > Exactly, so that's why SEND is actually trying to use IPsec > and Pekka is asking clarifications on why certain things are > like they are in ND. We are working on the problems mentioned > above. Work still remains, as you can see one of the issues > we are thinking about is the relevance of link layer > addresses and what checks are necessary or possible. Clarification is good. Was the spec not clear? /jim -------------------------------------------------------------------- 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 Feb 13 05:43:52 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08958 for ; Thu, 13 Feb 2003 05:43:52 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1DAl9Av019660; Thu, 13 Feb 2003 11:47:09 +0100 (MET) 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.2655.55) id 1X36BVBL; Thu, 13 Feb 2003 11:47:08 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1DAl7K06420; Thu, 13 Feb 2003 11:47:07 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id LAA18691; Thu, 13 Feb 2003 11:46:32 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from p2.piuha.net ([131.160.192.2]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id LAA18687 for ; Thu, 13 Feb 2003 11:46:31 +0100 (MET) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BD25E6A906; Thu, 13 Feb 2003 12:46:23 +0200 (EET) Message-ID: <3E4B776B.4060708@kolumbus.fi> Date: Thu, 13 Feb 2003 12:46:03 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: James Kempf , Pekka Nikander , IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? References: <9C422444DE99BC46B3AD3C6EAFC9711B034C06DD@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Jim, > The IKE UDP issue is only an implementation issue the spec works. We > have known this about manual keying since the beginnning. IPsec will > work and with IKE. Yes, the manual keying issue is mostly implementation, or rather configuration. But the IKE issue is more fundamental than just implementation. For one, Neighbor Discovery uses multicast extensively and IKE of course only handles unicast. So from the start we can't really use dynamic keying for all of ND. Furthermore, even if you would ignore multicast, some chicken-and-egg problems remain. For instance, assume that we need to talk to a peer, and do address resolution first. If all unicast traffic between the two peers is expected to be secured, this would imply that a solicited NA would have to be secured as well. But in order to secure the NA, we would need IKE to send IP packets to the peer, which in turn would require us to see the NA first, right? So it doesn't really work as of now. >>Exactly, so that's why SEND is actually trying to use IPsec >>and Pekka is asking clarifications on why certain things are >>like they are in ND. We are working on the problems mentioned >>above. Work still remains, as you can see one of the issues >>we are thinking about is the relevance of link layer >>addresses and what checks are necessary or possible. > > > Clarification is good. Was the spec not clear? I think we now have gotten more information on the role of the link-layer addresses in ND and why they are not checked. Thanks. I'm personally leaning towards leaving link-layer address checks away from SEND. 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 Feb 13 05:49:57 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09015 for ; Thu, 13 Feb 2003 05:49:57 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1DAr5Av021559; Thu, 13 Feb 2003 11:53:05 +0100 (MET) 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.2655.55) id 1XT39LL7; Thu, 13 Feb 2003 11:53:05 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1DAr5K07702; Thu, 13 Feb 2003 11:53:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id LAA18955; Thu, 13 Feb 2003 11:52:56 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id LAA18951 for ; Thu, 13 Feb 2003 11:52:55 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 53B281C; Thu, 13 Feb 2003 13:01:34 +0200 (EET) Message-ID: <3E4B7905.9080706@nomadiclab.com> Date: Thu, 13 Feb 2003 12:52:53 +0200 From: Pekka Nikander Reply-To: SEND WG , Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPV6 WG , SEND WG , Jim.Bound@hp.com, Francis.Dupont@enst-bretagne.fr Subject: Summary: Reason for the explicit link-layer address options in ND? References: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Thanks, Jim and Francis, for your timely answers to my question. Yes, like Jari pointed out, we are working on using IPsec for SEND, and we need to understand ND better to make it *right*. However, that discussion belongs to the very silent SEND mailing list, and should be continued only there, IMHO. (I've inserted Reply-To: headers to facilitate that...) Now, the ND specs as such are clear. No problem with that. It is just that the design rationale behind the specs in not written anywhere (as usual), and that was the reason for asking my question. We are not attempting to redefine or even revise the ND architecture, we are attempting to understand it fully so that we can design proper security for it. Now, if I read correctly what you Jim and Francis are saying, there seems to be a number of reasons for the design. Please correct me if I get this wrong; I am rewriting what I read to see if I understand it correctly. 1. Architecture It was deemed architecturally good to place ND at the IP/ICMP layer rather than below it. The main benefits from this are the following: - allows extension headers to be used - allows IPsec protection for ND - allows using routing and destination options 2. Implementation Early implementation experience showed that as a consequence of the design, implementation becomes simpler. In particular, NUD and prefix assimilation become part of the IP layer. I have one further question about that: what do you mean with prefix assimilation? I didn't find the term in RFC2461 or RFC2462. The reasons for the link layer address options were the following: 3. Extensibility (with extension headers etc). This seems to be a direct consequence of the architectural design decision. 4. Support for future functionality like proxy ND Again, this seems to follow the architectural principle layed out above. 5. Better support for the Override bit Now, I have a question about the Override bit. I didn't quite understand how it could be used for "node discovery during first phase when link-layer addresses are not shared". What did you mean with that, Jim? Finally, the reasons for not peeking at the actual link layer addresses used in the link layer frame can be summarized as follows: 6. Separation of function This again follows the architectural principle. Especially, it was viewed that checking the link-layer addresses is a link layer function, and it should be separate from the IP layer. Is that all or am I missing something? Or is there something above that doesn't belong there? Now, if you want to discuss how security fits in this all, may I suggest that we do it on the SEND list? (Personally I have trouble in keeping track with the IPv6 list volume, as I have also other things to do but participate to the IETF work.) --Pekka Nikander -------------------------------------------------------------------- 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 Feb 13 06:15:19 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09349 for ; Thu, 13 Feb 2003 06:15:18 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1DBIZAv027937; Thu, 13 Feb 2003 12:18:35 +0100 (MET) 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.2655.55) id 1XSZ8V2T; Thu, 13 Feb 2003 12:18:35 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1DBIYK08484; Thu, 13 Feb 2003 12:18:34 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id MAA23106; Thu, 13 Feb 2003 12:18:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id MAA23102 for ; Thu, 13 Feb 2003 12:18:19 +0100 (MET) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 0A6FF1C; Thu, 13 Feb 2003 13:26:59 +0200 (EET) Message-ID: <3E4B7EFA.9040508@nomadiclab.com> Date: Thu, 13 Feb 2003 13:18:18 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: SEND WG Subject: Notes about CGA in SEND (was Re: Reason for the explicit link-layer address options in ND?) References: <200302121458.h1CEwIof095565@givry.rennes.enst-bretagne.fr> In-Reply-To: <200302121458.h1CEwIof095565@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Francis, [I've removed IPV6 WG from CC since this discussion belongs to SEND, IMHO.] > The WG decided to pursue the idea of using public > key based AH to secure the NA (and NS) messages. > That requires that the hosts learn the public keys > of the other hosts on the local link. Basically, > there are two know methods for distributing the > public keys: Using certificates and relying on > a (local) CA, or using Cryptographically Generated > Addresses (CGA). > > => I stronly disagree: CGAs are very different: they > don't provide authentication, only ownership. > And there is a third way, Key-Based Addresses (KBA), > i.e., the opposite of CGAs. Sorry about forgetting ABK/KBA; they require some sort of a central agency, so I tempt to classify them with the cert/CA based solution. Anyway, it should be mentioned for completeness. Thanks for the correction. Now, what comes to the difference between CGA and certs, there is indeed a difference, but it is more subtle than what you seem to imply. - When certificates are used, the nodes trust on an external party (the local CA) to tell what nodes are trustworthy and what nodes are not. Furthermore, iff the certificates contain an IP address, the certificates also provide authorization over IP address usage. Likewise, iff the certificates contain a link layer address, they provide authorization over ll address usage. But, of course, usually the certificates do not contain either, for obvious practical reasons. - When CGA is used, the nodes do not trust on any external party but rely on the computational difficulty of creating another set of that matches with a given set. In both cases the goal is to have a reasonable bases to believe that a given mapping is valid. In the first case, the resulting belief is based on trust on the local CA and possibly also on trust on the nodes. In the second case, the resulting belief is based on assumptions on computational complexity. > Under the current design, the CGA processing at the > AH layer becomes very tricky, if we attempt to include > the link layer address into the CGA process. > > => I don't understand your problem: with public keys you > can sign NAs so secure the IPv6 to link-layer address binding. > To secure the reverse binding we can reuse inverse ND (RFC 3122). > So the only issue (:-) is the public key distribution... Signing the NA is certainly enough if you have a resonable bases to rely on the honesty and competence of the key holder. If you are using certificates, you may have. However, if you are using CGA, you don't. You just have some unknown party having a public key and claiming a binding between an IP address and link layer address. Now, since creating a suitable key that matches a given IP address is a hard problem in CGA, it *may* be enough to just sign the NA, and rely on the signature for the link layer address. Personally, I tend to believe that it is currently secure enough for global addresses, since in that case the CGA input includes the routing prefix. Furthermore, including the link layer address into the CGA input parameters would be bad for privacy. However, the situation is different for link layer addresses. Firstly, there are no privacy problem since the link layer addresses are visible at the local link anyway. Secondly, we *do* have a (slight) security problem since the link local routing prefix is always the same. Consequently, there appears to be an almost practical precomputation attack where an attacker creates a table of precomputed pairs. The amount of memory needed for such a table is fairly large today (in the order of 2^66..2^72 bytes), but the attack is clearly becoming feasible within the next 20 years. Thus, one possible way of defeating the link local pre-computed table attack is to include the link layer address into the CGA input parameters. That would force the attacker to use a pre-determined link layer address, thereby reducing the attractivity of the attack. It should be noted that including the link layer address into the CGA input parameters does not completely stop the pre-computation attack, since in an attack situation the recipient would receive two different but valid NAs: one would be sent by the actual node, and the other one from the pre-computed table. Without any other prior knowledge, the recipient would not be able to make a difference between these two, thereby creating confusion between which node is the right one. In practise, however, it might be easier to isolate the attacker since it would be forced to use the pre-determined link layer address(es). Does this matter? I don't know. We are still discussing this in the DT. Opinions from the WG are very welcome. --Pekka Nikander -------------------------------------------------------------------- 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 Feb 13 08:03:20 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11264 for ; Thu, 13 Feb 2003 08:03:20 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1DD5uAv026434; Thu, 13 Feb 2003 14:05:56 +0100 (MET) 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.2655.55) id 1XT30JSS; Thu, 13 Feb 2003 14:05:56 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1DD5pK12383; Thu, 13 Feb 2003 14:05:52 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id OAA06247; Thu, 13 Feb 2003 14:04:31 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id OAA06242 for ; Thu, 13 Feb 2003 14:04:30 +0100 (MET) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 04A3088CF; Thu, 13 Feb 2003 08:04:29 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 08:04:28 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Summary: Reason for the explicit link-layer address options in ND? X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 08:04:28 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE0@tayexc13.americas.cpqcorp.net> Thread-Topic: Summary: Reason for the explicit link-layer address options in ND? Thread-Index: AcLTThKvTgZ6ugIFSYegV1gMMQZRvAADqEKQ From: "Bound, Jim" To: "SEND WG" , "Pekka Nikander" , "IPV6 WG" , X-OriginalArrivalTime: 13 Feb 2003 13:04:28.0935 (UTC) FILETIME=[71340170:01C2D360] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id OAA06244 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Hi Pekka, > Thanks, Jim and Francis, for your timely answers to my > question. Yes, like Jari pointed out, we are working on > using IPsec for SEND, and we need to understand ND better to > make it *right*. However, that discussion belongs to the > very silent SEND mailing list, and should be continued only > there, IMHO. (I've inserted Reply-To: headers to facilitate that...) I am fine with the strategy. > > Now, the ND specs as such are clear. No problem with > that. It is just that the design rationale behind the > specs in not written anywhere (as usual), and that was > the reason for asking my question. We are not attempting > to redefine or even revise the ND architecture, we are > attempting to understand it fully so that we can design > proper security for it. OK. I just get nervous lately esp with researchers who want to help make IPv6 better. I have an issue when a person shows up at the hospital with a headache and the hospital takes the patient to a room for open heart surgery. Glad that is not the case. Also I asked the question also to yet again show in our community taking time to put rationale appendices in completed standards specs is a wise thing to do as the IEEE does. Oh well I must try. > > Now, if I read correctly what you Jim and Francis are saying, > there seems to be a number of reasons for the design. Please > correct me if I get this wrong; I am rewriting what I read to > see if I understand it correctly. > > 1. Architecture > > It was deemed architecturally good to place ND > at the IP/ICMP layer rather than below it. The > main benefits from this are the following: > > - allows extension headers to be used > - allows IPsec protection for ND > - allows using routing and destination options These are attributes yes. To get them all a detailed investigation of ND would need to be done. Do these work for now? > > 2. Implementation > > Early implementation experience showed that as > a consequence of the design, implementation becomes > simpler. In particular, NUD and prefix assimilation > become part of the IP layer. > > I have one further question about that: what do > you mean with prefix assimilation? I didn't find > the term in RFC2461 or RFC2462. Sorry I knew that when I wrote it and did it anyway, sorry again. In ND a node can receive prefixes for autoconfiguration and to be used to note prefixes on that link or just one or just both. L bit says this prefix can be used for onlink determination and A bit says this prefix can be used for addrconf. The ability to have this knowledge about prefixes permits the verification of other nodes on the network. So if a rogue prefix appears a hint can be provided it is not on link valid from the L bit. But the code to work prefix vs link-layer is two separate functions that can be then joined for verification and assimilation to support ND caches and the NUD state machine. Does that help? > > > The reasons for the link layer address options were > the following: > > 3. Extensibility (with extension headers etc). > > This seems to be a direct consequence of the > architectural design decision. Specifically with ICMP and new types. If a new ICMP SEND type were needed you would not have to reinvent the link-layer packets "hopefully". > > 4. Support for future functionality like proxy ND > > Again, this seems to follow the architectural > principle layed out above. > > 5. Better support for the Override bit > > Now, I have a question about the Override bit. > I didn't quite understand how it could be used > for "node discovery during first phase when > link-layer addresses are not shared". > > What did you mean with that, Jim? The override bit if on says don't replace this link-layer with existing link-layer or if not set do replace it. Throughout 2461 this bit is used to control state and cache replacement. This is very powerful and a real advantage of ND over its predecessors. Also in SEND I would look to see if there are conditions that can be set with the override bit for initial security benefits. > > Finally, the reasons for not peeking at the actual > link layer addresses used in the link layer frame can > be summarized as follows: > > 6. Separation of function > > This again follows the architectural principle. > Especially, it was viewed that checking the > link-layer addresses is a link layer function, > and it should be separate from the IP layer. > > Is that all or am I missing something? Or is there > something above that doesn't belong there? Yes this is the only reason. But see the IPv6 over foo specs. > > Now, if you want to discuss how security fits in this > all, may I suggest that we do it on the SEND list? > (Personally I have trouble in keeping track with > the IPv6 list volume, as I have also other things > to do but participate to the IETF work.) I This makes sense. I don't have the time to take SEND on. But if you have direct questions and send them I will go look within a reasonable time frame. I implemented parts of ND and all of Addrconf so know them well from that but that was some time ago too and even an implementor has to go recheck specs. Also we did identify this potential security issue in the spec under considerations briefly speaking of it as MAC spoofing. If SEND puts out spec saying in additon to whats in ND implementations should also do X I see that as goodness. Just don't want to see 2461 altered unless something is broken in ND itself is my input to our processes. Regards, /jim > > --Pekka Nikander > > -------------------------------------------------------------------- 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 Feb 13 08:12:24 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11519 for ; Thu, 13 Feb 2003 08:12:23 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1DDFlKV024217; Thu, 13 Feb 2003 14:15:47 +0100 (MET) 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.2655.55) id 1XT30LRW; Thu, 13 Feb 2003 14:15:47 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1DDFlK13969; Thu, 13 Feb 2003 14:15:47 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id OAA07995; Thu, 13 Feb 2003 14:15:36 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id OAA07972 for ; Thu, 13 Feb 2003 14:15:34 +0100 (MET) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 84DB975F6; Thu, 13 Feb 2003 08:15:32 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 08:15:32 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reason for the explicit link-layer address options in ND? X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 08:15:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE1@tayexc13.americas.cpqcorp.net> Thread-Topic: Reason for the explicit link-layer address options in ND? Thread-Index: AcLTTTM5AshzMngCS2+XiK43DOE4DAAE3Ivw From: "Bound, Jim" To: "Jari Arkko" Cc: "James Kempf" , "Pekka Nikander" , "IPV6 WG" , "SEND WG" X-OriginalArrivalTime: 13 Feb 2003 13:15:32.0420 (UTC) FILETIME=[FCABC840:01C2D361] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id OAA07981 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Jari, > But the IKE issue is more fundamental than just > implementation. For one, Neighbor Discovery uses multicast > extensively and IKE of course only handles unicast. So from > the start we can't really use dynamic keying for all of ND. > Furthermore, even if you would ignore multicast, some > chicken-and-egg problems remain. For instance, assume that we > need to talk to a peer, and do address resolution first. If > all unicast traffic between the two peers is expected to be > secured, this would imply that a solicited NA would have to > be secured as well. But in order to secure the NA, we would > need IKE to send IP packets to the peer, which in turn would > require us to see the NA first, right? So it doesn't really > work as of now. I believe the multicast keying problem for link-local is resolvable but that is an IPsec discussion right? Agreed for multicast past the link. OK. In this sense your right I thought you were concerned about the IKE process to get keys. Which is valid but I believe they can be preconfigured before the node is on the network too. In fact a model that I believe will become more prevalent over time esp handhelds. Yes the NA in normal environment is required but not all. Once the node has a link-local address it could be congfigured at boot time to load a key. We do this today in industry for licenses etc. When the IPv6 node is booting and does DAD to get link-local address verified it then goes and gets its key. The key can then be used for the NA and NS processes. The hole that is open widest to an attack is DAD. That would be very hard to fix. As I said we will never have perfect security any more than other aspects of life. I would argue you SEND should see what it can do to extend security to the mobile node and the link it enters via ND at the point of getting a link-local adddress. If that is more secure it will reduce many other attacks. Regards, /jim -------------------------------------------------------------------- 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 Feb 13 12:14:31 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18745 for ; Thu, 13 Feb 2003 12:14:30 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1DHHdAv026168; Thu, 13 Feb 2003 18:17:39 +0100 (MET) 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.2655.55) id 1XQV7VHD; Thu, 13 Feb 2003 18:17:39 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1DHHcK22436; Thu, 13 Feb 2003 18:17:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id SAA07778; Thu, 13 Feb 2003 18:17:18 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id SAA07774 for ; Thu, 13 Feb 2003 18:17:16 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1DHHDh02084; Thu, 13 Feb 2003 18:17:13 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h1DHFHof099887; Thu, 13 Feb 2003 18:15:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302131715.h1DHFHof099887@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Fred L. Templin" cc: Pekka Nikander , IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? In-reply-to: Your message of Wed, 12 Feb 2003 09:56:09 PST. <3E4A8AB9.4000406@iprg.nokia.com> Date: Thu, 13 Feb 2003 18:15:17 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk In your previous mail you wrote: Francis Dupont wrote: > In your previous mail you wrote: > > Is this just a layering question, an attempt to > avoid layer violations? Or were there behind > other goals, like allowing proxy ND? > > => both reasons. In the same kind of design ideas, it is > forbidden to mix unicast and multicast between layers, i.e., > if the IPv6 destination is unicast, the link-layer destination > MUST be unicast, and same with multicast in place of unicast. Can you point me to the text that forbids this? => RFC 1122 3.3.6 but I recognize this needs to be clarify for IPv6. I was under the impression that multicast emulation mechanisms (e.g. MARS, etc.) use unicast link-layer destination addresses when the IPv6 destination is multicast. => in the case of MARS for ATM there is no real link-layer addresses for the point-to-multipoint virtual circuits. Even if MCS are used in fact we can argue the link-layer address is a set of addresses with possible indirection. The whole point of multicast emulation is to propagate network-layer multicasts over unicast-only link layers - not true? => yes but the special mark for link-layer broadcast/multicast packets is still needed. Regards Francis.Dupont@enst-bretagne.fr PS: the exact quote is (see also TCP/IP illustrated V2 page 1101): When a host sends a datagram to a link-layer broadcast address, the IP destination address MUST be a legal IP broadcast or IP multicast address. A host SHOULD silently discard a datagram that is received via a link-layer broadcast (see Section 2.4) but does not specify an IP multicast or broadcast destination address. -------------------------------------------------------------------- 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 Feb 14 09:05:30 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23000 for ; Fri, 14 Feb 2003 09:05:29 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1EE8aKV021627; Fri, 14 Feb 2003 15:08:36 +0100 (MET) 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.2655.55) id 18WQQC7W; Fri, 14 Feb 2003 15:08:36 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1EE8a224582; Fri, 14 Feb 2003 15:08:36 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id PAA20610; Fri, 14 Feb 2003 15:07:51 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx.laposte.net (mx.laposte.net [213.30.181.7]) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id PAA20603 for ; Fri, 14 Feb 2003 15:07:49 +0100 (MET) Received: from gbl-dhcp-198-248.europe.research.sun.com (194.2.198.248) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3E493E5200078B30; Fri, 14 Feb 2003 15:07:17 +0100 From: Julien Laganier To: Pekka Nikander Subject: Notes about CGA in SEND (was Re: Reason for the explicit link-layer address options in ND?) Date: Fri, 14 Feb 2003 15:04:47 +0100 User-Agent: KMail/1.5 Cc: gab@sun.com, SEND WG References: <200302121458.h1CEwIof095565@givry.rennes.enst-bretagne.fr> <3E4B7EFA.9040508@nomadiclab.com> In-Reply-To: <3E4B7EFA.9040508@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200302141504.47543.julien.laganier@laposte.net> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, What you wrote below triggered some questions in my mind. I must admit that I am not sure that I've caught well all implications... My questions are included in the text. I am also wondering if another scheme (gabriel and I called it CLE) would permit to reduce as well the easyness of precomputation attacks. WG's inputs on CLE are welcomed. Pekka Nikander wrote : > > However, the situation is different for link layer > addresses. Firstly, there are no privacy problem since > the link layer addresses are visible at the local link > anyway. Secondly, we *do* have a (slight) security problem > since the link local routing prefix is always the same. > Consequently, there appears to be an almost practical > precomputation attack where an attacker creates a table > of precomputed pairs. > The amount of memory needed for such a table is fairly > large today (in the order of 2^66..2^72 bytes), but the > attack is clearly becoming feasible within the next 20 > years. > > Thus, one possible way of defeating the link local > pre-computed table attack is to include the link layer > address into the CGA input parameters. That would force > the attacker to use a pre-determined link layer address, > thereby reducing the attractivity of the attack. Alice has a (link-local) IP addr L and (MAC) link-layer addr a, where Pekka's assuming a is predetermined (perhaps by IEEE EUI info): (1) L = h(PK,a) The goal of the NA is convincing folks to cache the mapping (2) link-local IP addr L @ link-layer a So presumably you would only enter (2) into your cache if you were able to verify (1). An attacker not using link-layer addr a would not be able to do this as easily as if (1) were simply L=h(PK). > It should be noted that including the link layer address > into the CGA input parameters does not completely stop > the pre-computation attack, since in an attack situation > the recipient would receive two different but valid NAs: > one would be sent by the actual node, and the other one > from the pre-computed table. Without any other prior > knowledge, the recipient would not be able to make a > difference between these two, thereby creating confusion > between which node is the right one. In practise, however, > it might be easier to isolate the attacker since it would > be forced to use the pre-determined link layer address(es). Yes, so an attacker can persevere in usurping link-layer address a by doing this: (3) L' = h(PK', a) and using that to send an NA: (4) link-local IP addr L' @ link-layer a Since (2) and (4) are equally consistent, you as a recipient wouldn't know which to believe, but at least forcing the attacker to use "a" makes it more traceable. Another way to reduce precomputed attacks could be to define the link layer address as a CGA as well, using as input the same PK that the one used to generate the link local IP address. Thus, both IP and LL addresses are bound to a given PK. We've called that Cryptographic Layering Enforcement (CLE): (7) L = h_top(PK), a = h_bottom(PK) With an NA producing a mapping as in (2) verifiable as per the above. With (4) you're fixing only one element (either L or a), whereas in (7) we're fixing both elements. If an attacker wishes to produce a valid mapping with (7) using bogus PK', it has two events to reproduce: (8) P(a) = probability that he'll find a collision with PK' such that a = h_bottom(PK') (9) P(L) = probability that he'll find a collision with PK' such that L = h_top(PK') In CLE, our assumption is that (8) and (9) are indeed independent events. Someone who knows about hash functions can tell us better... Assuming they're independent events, then the probability of finding a valid (7) is then: (10) P(a&L) = P(a)P(L) So we've made the attacker's task much much harder. Furthermore, if we then define another application of CLE, like for example, Mobile IP, we could define the care-of address: (11) C = h_middle(PK) and the objective of the binding update is to establish the mapping: (12) L @ C (Where L should be replaced by "G" a global-unicast address.) Then the probability of establishing such a mapping for an attacker using trial and error is: (13) P(L&C) = P(L)P(C) and we've made the task much harder. We could even think that for an attack to succeed completely, the attacker would have to beat the following odds: (14) P(a&L&C) = P(a)P(L)P(C) Assuming the hash function in question produces bottom, middle and top bits independently of each other, we're making the task even harder. True, such a mapping as (13) is really 2 mappings produced by NA and BU, and both may not be available to most observers, but if at least some systems see this, they can detect and signal fishiness. Nevertheless, current implementations of either (10) or (13) can be considered secure. Also, quoting RFC 2373, IP Version 6 Addressing Architecture : --->" | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ "<-- I am wondering if making a CGA link local address by concatenating a reduced link-local prefix (fe80) with 118 bits extracted from the secure hash output would make sense? That would certainly reduce the easyness of PK-jar attacks... But it's not currently allowed by [ADDRARCH] where all 54 bits between IID and LL prefix are set to zero. Thanks, --julien -------------------------------------------------------------------- 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 Feb 14 11:47:56 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26668 for ; Fri, 14 Feb 2003 11:47:39 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1EGmcAv000871; Fri, 14 Feb 2003 17:48:38 +0100 (MET) 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.2655.55) id 18WY14MH; Fri, 14 Feb 2003 17:48:38 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1EGmc228833; Fri, 14 Feb 2003 17:48:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) id RAA10412; Fri, 14 Feb 2003 17:48:08 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.9.1/8.9.1/uc-1.0) with ESMTP id RAA10408 for ; Fri, 14 Feb 2003 17:48:06 +0100 (MET) Message-ID: <00ce01c2d448$9991d3c0$846015ac@T23KEMPF> From: "James Kempf" To: "Julien Laganier" , "Pekka Nikander" Cc: , "SEND WG" References: <200302121458.h1CEwIof095565@givry.rennes.enst-bretagne.fr> <3E4B7EFA.9040508@nomadiclab.com> <200302141504.47543.julien.laganier@laposte.net> Subject: Re: Notes about CGA in SEND (was Re: Reason for the explicit link-layer address options in ND?) Date: Fri, 14 Feb 2003 08:46:19 -0800 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 Content-Transfer-Encoding: 7bit Making the link layer address a CGA too makes sense, but is not always possible. I don't think it would be for ATM for example. Regarding using 118 bits, the latest v6 AddrArch document is fairly strict about the 64 bit boundary for global unicast, though the current wording doesn't make it a requirement. I've actually thought about this too, but more along the lines of having the router use a hash of the fqdn for the domain or its own fqdn as a way to tie the identifier for a X.509 certificate to an address without putting the address in the certificate. jak ----- Original Message ----- From: "Julien Laganier" To: "Pekka Nikander" Cc: ; "SEND WG" Sent: Friday, February 14, 2003 6:04 AM Subject: Notes about CGA in SEND (was Re: Reason for the explicit link-layer address options in ND?) > Hi Pekka, > > What you wrote below triggered some questions in my mind. > > I must admit that I am not sure that I've caught well all implications... > My questions are included in the text. > > I am also wondering if another scheme (gabriel and I called it CLE) > would permit to reduce as well the easyness of precomputation attacks. > WG's inputs on CLE are welcomed. > > Pekka Nikander wrote : > > > > However, the situation is different for link layer > > addresses. Firstly, there are no privacy problem since > > the link layer addresses are visible at the local link > > anyway. Secondly, we *do* have a (slight) security problem > > since the link local routing prefix is always the same. > > Consequently, there appears to be an almost practical > > precomputation attack where an attacker creates a table > > of precomputed pairs. > > The amount of memory needed for such a table is fairly > > large today (in the order of 2^66..2^72 bytes), but the > > attack is clearly becoming feasible within the next 20 > > years. > > > > Thus, one possible way of defeating the link local > > pre-computed table attack is to include the link layer > > address into the CGA input parameters. That would force > > the attacker to use a pre-determined link layer address, > > thereby reducing the attractivity of the attack. > > Alice has a (link-local) IP addr L and (MAC) link-layer addr a, > where Pekka's assuming a is predetermined (perhaps by IEEE EUI info): > > (1) L = h(PK,a) > > The goal of the NA is convincing folks to cache the mapping > > (2) link-local IP addr L @ link-layer a > > So presumably you would only enter (2) into your cache if you were > able to verify (1). > > An attacker not using link-layer addr a would not be able to do this > as easily as if (1) were simply L=h(PK). > > > It should be noted that including the link layer address > > into the CGA input parameters does not completely stop > > the pre-computation attack, since in an attack situation > > the recipient would receive two different but valid NAs: > > one would be sent by the actual node, and the other one > > from the pre-computed table. Without any other prior > > knowledge, the recipient would not be able to make a > > difference between these two, thereby creating confusion > > between which node is the right one. In practise, however, > > it might be easier to isolate the attacker since it would > > be forced to use the pre-determined link layer address(es). > > Yes, so an attacker can persevere in usurping link-layer address > a by doing this: > > (3) L' = h(PK', a) > > and using that to send an NA: > > (4) link-local IP addr L' @ link-layer a > > Since (2) and (4) are equally consistent, you as a recipient wouldn't > know which to believe, but at least forcing the attacker to use "a" > makes it more traceable. > > Another way to reduce precomputed attacks could be to define the link layer > address as a CGA as well, using as input the same PK that the one used to > generate the link local IP address. Thus, both IP and LL addresses are bound > to a given PK. We've called that Cryptographic Layering Enforcement (CLE): > > (7) L = h_top(PK), a = h_bottom(PK) > > With an NA producing a mapping as in (2) verifiable as per the above. > With (4) you're fixing only one element (either L or a), whereas in (7) we're > fixing both elements. If an attacker wishes to produce a valid mapping > with (7) using bogus PK', it has two events to reproduce: > > (8) P(a) = probability that he'll find a collision > with PK' such that a = h_bottom(PK') > > (9) P(L) = probability that he'll find a collision > with PK' such that L = h_top(PK') > > In CLE, our assumption is that (8) and (9) are indeed independent > events. Someone who knows about hash functions can tell us better... > > Assuming they're independent events, then the probability of > finding a valid (7) is then: > > (10) P(a&L) = P(a)P(L) > > So we've made the attacker's task much much harder. > Furthermore, if we then define another application of CLE, > like for example, Mobile IP, we could define the care-of > address: > > (11) C = h_middle(PK) > > and the objective of the binding update is to establish the mapping: > > (12) L @ C > > (Where L should be replaced by "G" a global-unicast address.) > Then the probability of establishing such a mapping for an attacker > using trial and error is: > > (13) P(L&C) = P(L)P(C) > > and we've made the task much harder. We could even think that for an > attack to succeed completely, the attacker would have to beat the > following odds: > > (14) P(a&L&C) = P(a)P(L)P(C) > > Assuming the hash function in question produces bottom, middle and > top bits independently of each other, we're making the task even > harder. True, such a mapping as (13) is really 2 mappings produced > by NA and BU, and both may not be available to most observers, but > if at least some systems see this, they can detect and signal > fishiness. > > Nevertheless, current implementations of either (10) or (13) can be > considered secure. > > Also, quoting RFC 2373, IP Version 6 Addressing Architecture : > > --->" > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ > "<-- > > I am wondering if making a CGA link local address by concatenating a > reduced link-local prefix (fe80) with 118 bits extracted from the secure > hash output would make sense? That would certainly reduce the easyness > of PK-jar attacks... But it's not currently allowed by [ADDRARCH] where all > 54 bits between IID and LL prefix are set to zero. > > Thanks, > > --julien > -------------------------------------------------------------------- > 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 Feb 21 01:52:21 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11094 for ; Fri, 21 Feb 2003 01:52:21 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1L6sjAv018966; Fri, 21 Feb 2003 07:54:45 +0100 (MET) 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.2655.55) id FD4G2NXJ; Fri, 21 Feb 2003 07:54:45 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1L6si214731; Fri, 21 Feb 2003 07:54:44 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) id HAA28813; Fri, 21 Feb 2003 07:53:58 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id HAA28809 for ; Fri, 21 Feb 2003 07:53:56 +0100 (MET) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04096; Thu, 20 Feb 2003 23:53:48 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1L6rhP00363; Fri, 21 Feb 2003 07:53:43 +0100 (MET) Date: Thu, 20 Feb 2003 23:47:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Summary: Reason for the explicit link-layer address options in ND? To: SEND WG , Pekka Nikander Cc: IPV6 WG , Jim.Bound@hp.com, Francis.Dupont@enst-bretagne.fr In-Reply-To: "Your message with ID" <3E4B7905.9080706@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-send@prdxweb.sw.ericsson.se Precedence: bulk > Finally, the reasons for not peeking at the actual > link layer addresses used in the link layer frame can > be summarized as follows: > > 6. Separation of function > > This again follows the architectural principle. > Especially, it was viewed that checking the > link-layer addresses is a link layer function, > and it should be separate from the IP layer. > > Is that all or am I missing something? Or is there > something above that doesn't belong there? I recall there was also a feeling that since ARP provides the same separation (ARP doesn't use the addresses in the link-layer frame) it would be a bit too creative to remove it. I think the separation in ARP has, if not helped, given more flexibility e.g. when bridging between different 802 media with different bit order in the header (e.g. Ethernet to Token ring or FDDI). Also, I think it might have helped for media that doesn't have actual link-layer addresses but instead just a local DLCI - where the DLCIs each end sees is different. In that case there isn't an address in the datalink header you can use. Erik -------------------------------------------------------------------- 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 Feb 24 09:51:07 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15620 for ; Mon, 24 Feb 2003 09:51:05 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1OEsUKV008855; Mon, 24 Feb 2003 15:54:30 +0100 (MET) 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.2655.55) id FDVNHC3J; Mon, 24 Feb 2003 15:54:29 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1OEsTK19646; Mon, 24 Feb 2003 15:54:29 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) id PAA12446; Mon, 24 Feb 2003 15:53:49 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.clinicasanborja.com.pe (mail.clinicasanborja.com.pe [216.244.152.250]) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id PAA12442 for ; Mon, 24 Feb 2003 15:53:47 +0100 (MET) From: fa.carmley@yahoo.com Received: from mx1.mail.yahoo.com ( [216.244.152.250]) by mail.clinicasanborja.com.pe (8.9.3/8.9.3) with ESMTP id JAA04577; Mon, 24 Feb 2003 09:48:24 -0500 Message-ID: <0000344976c4$00005b2b$00001de9@mx1.mail.yahoo.com> To: Subject: Re: Finding Similarities19513 Date: Mon, 24 Feb 2003 09:51:45 -1700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Reply-To: fa.carmley@yahoo.com Sender: owner-ietf-send@prdxweb.sw.ericsson.se Precedence: bulk Content-Transfer-Encoding: 7bit Reliable income... Get a 5-6 figure annual income, earning $2,000-$12,000 monthly, working Part-Time/Full-Time. Read further and request more info... Enjoy: ---5-6 figure first year earning potential ---$10,000 monthly or more possible ---New marketing system from successful 8 year old company you can operate from anywhere. ---Make $1,000-$3,000 per sale. ---Pre-sold customers call you direct. Customers pay you direct. ---Residual income ---Spectacular benefits ---A fun business Say good-bye to: ---Long workdays ---Miserable commutes ---Corporate politics ---Employee hassles ---Franchise red tape ---Network marketing non-sense ---Inventory to purchase and store ---Periodic purchase requirements ---Cold-calling, expensive advertising, pressure selling ---Big Start-up costs What does it take to succeed? ---Standard home office equipment: telephone, fax, computer ---Work ---Being reasonably well-organized ---Big business mind-set ---Focus ---Belief in yourself and your potential So break free now--- Learn more today! Respond to: brenda.blake@talk21.com say "Provide Data" ! -------------------------------------------------------------------- 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 Feb 24 11:10:45 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17764 for ; Mon, 24 Feb 2003 11:10:44 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1OGE2Av001214; Mon, 24 Feb 2003 17:14:02 +0100 (MET) 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.2655.55) id FD4G8DKM; Mon, 24 Feb 2003 17:14:02 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1OGDx200368; Mon, 24 Feb 2003 17:13:59 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) id RAA22015; Mon, 24 Feb 2003 17:13:37 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id RAA22010 for ; Mon, 24 Feb 2003 17:13:35 +0100 (MET) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 24 Feb 2003 08:13:12 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Feb 2003 08:13:33 -0800 Received: from RED-MSG-09.redmond.corp.microsoft.com ([157.54.12.7]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Mon, 24 Feb 2003 08:13:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: CGA draft and paper Date: Mon, 24 Feb 2003 08:13:25 -0800 Message-ID: Thread-Topic: CGA draft and paper Thread-Index: AcLZdiJVcERgdKZGQ2abww8GxyVxewCpy5NQ From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 24 Feb 2003 16:13:36.0312 (UTC) FILETIME=[AF4F9380:01C2DC1F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prdxweb.sw.ericsson.se id RAA22011 Sender: owner-ietf-send@prdxweb.sw.ericsson.se Precedence: bulk Content-Transfer-Encoding: 8bit I have posted a draft on Cryptographically Generated Addresses (CGA) on my web page: http://research.microsoft.com/users/tuomaura/CGA/draft-aura-cga-pre00.tx t Unfortunately, I managed to miss the submission deadline for San Francisco, so the draft will only be on this web site for now. A related (still unpublished) paper with some more background info is also available: http://research.microsoft.com/users/tuomaura/CGA/aura-cga-unpublished.pd f Tuomas -------------------------------------------------------------------- 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 Feb 24 11:51:28 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18855 for ; Mon, 24 Feb 2003 11:51:27 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1OGswKV008913; Mon, 24 Feb 2003 17:54:58 +0100 (MET) 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.2655.55) id FDVJ0996; Mon, 24 Feb 2003 17:54:58 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1OGsw201416; Mon, 24 Feb 2003 17:54:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) id RAA27133; Mon, 24 Feb 2003 17:54:45 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id RAA27115 for ; Mon, 24 Feb 2003 17:54:44 +0100 (MET) Message-ID: <009c01c2dc25$3705c1a0$846015ac@T23KEMPF> From: "James Kempf" To: Subject: SEND Protocol Draft Now Available Date: Mon, 24 Feb 2003 08:53:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@prdxweb.sw.ericsson.se Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The first version of the SEND protocol draft is complete and has been sent to the Internet Drafts editor. Prior to it appearing at the ID web site, you can find it at the following URLs: http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.txt http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.html We would like to get some discussion of the draft on the list prior to the meeting, with the intent of generating a list of issues, and perhaps some resolutions, for the meeting. 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 Feb 24 20:00:00 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01925 for ; Mon, 24 Feb 2003 19:59:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1P13FKV004544; Tue, 25 Feb 2003 02:03:15 +0100 (MET) 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.2655.55) id FD4G0J0P; Tue, 25 Feb 2003 02:03:14 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1P13E218775; Tue, 25 Feb 2003 02:03:14 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) id CAA01323; Tue, 25 Feb 2003 02:02:49 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id CAA01319 for ; Tue, 25 Feb 2003 02:02:47 +0100 (MET) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KSUOI828P29BVUFF@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Tue, 25 Feb 2003 10:35:18 +1100 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 8E77120009; Tue, 25 Feb 2003 10:35:17 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 6475A20008; Tue, 25 Feb 2003 10:35:12 +1100 (EST) Date: Tue, 25 Feb 2003 10:35:12 +1100 From: Greg Daley Subject: Re: SEND Protocol Draft Now Available To: James Kempf Cc: ietf-send@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <3E5AAC30.6040800@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: <009c01c2dc25$3705c1a0$846015ac@T23KEMPF> Sender: owner-ietf-send@prdxweb.sw.ericsson.se Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, Just going through the draft now. I have a query: in section 6.6 paragraph 2, is the text referring to a Router Advertisement or a Delegation Chain Advertisement? I'm still reading, just wanted clarification.. Greg James Kempf wrote: > Folks, > > The first version of the SEND protocol draft is complete and has been sent to > the Internet Drafts editor. Prior to it appearing at the ID web site, you can > find it at the following URLs: > > http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.txt > http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.html > > We would like to get some discussion of the draft on the list prior to the > meeting, with the intent of generating a list of issues, and perhaps some > resolutions, for the meeting. > > 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 Tue Feb 25 12:35:36 2003 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07857 for ; Tue, 25 Feb 2003 12:35:35 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PHbYYe001909; Tue, 25 Feb 2003 18:37:34 +0100 (MET) 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.2655.55) id FDVK2343; Tue, 25 Feb 2003 18:37:34 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1PHbYK06265; Tue, 25 Feb 2003 18:37:34 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) id SAA19525; Tue, 25 Feb 2003 18:37:06 +0100 (MET) 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 prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id SAA19521 for ; Tue, 25 Feb 2003 18:37:04 +0100 (MET) Message-ID: <015201c2dcf4$45e5bc50$846015ac@T23KEMPF> From: "James Kempf" To: Cc: References: <009c01c2dc25$3705c1a0$846015ac@T23KEMPF> <3E5AAC30.6040800@eng.monash.edu.au> Subject: Re: SEND Protocol Draft Now Available Date: Tue, 25 Feb 2003 09:34:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@prdxweb.sw.ericsson.se Precedence: bulk Content-Transfer-Encoding: 7bit Hi Greg, Is this the text you mean: A host MUST silently discard any received Router Advertisement messages that do not satisfy all of the following validity checks: If so, I think it should be pretty clear. jak ----- Original Message ----- From: "Greg Daley" To: "James Kempf" Cc: Sent: Monday, February 24, 2003 3:35 PM Subject: Re: SEND Protocol Draft Now Available > Hi James, > > Just going through the draft now. > > I have a query: > > in section 6.6 paragraph 2, is the text referring > to a Router Advertisement or a Delegation Chain > Advertisement? > > I'm still reading, just wanted clarification.. > > Greg > > James Kempf wrote: > > Folks, > > > > The first version of the SEND protocol draft is complete and has been sent to > > the Internet Drafts editor. Prior to it appearing at the ID web site, you can > > find it at the following URLs: > > > > http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.txt > > http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.html > > > > We would like to get some discussion of the draft on the list prior to the > > meeting, with the intent of generating a list of issues, and perhaps some > > resolutions, for the meeting. > > > > 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 Wed Feb 26 11:56:43 2003 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15760 for ; Wed, 26 Feb 2003 11:56:42 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QH05nS024650; Wed, 26 Feb 2003 18:00:05 +0100 (MET) 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.2655.55) id FD4HPRR3; Wed, 26 Feb 2003 18:00:05 +0100 Received: from prdxweb.sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.10.0/8.10.0/extranet-1.1) with ESMTP id h1QH05227055; Wed, 26 Feb 2003 18:00:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) id RAA18848; Wed, 26 Feb 2003 17:59:33 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from albatross.wise.edt.ericsson.se ([193.180.251.49]) by prdxweb.sw.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id RAA18844 for ; Wed, 26 Feb 2003 17:59:32 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QGxHnS024501; Wed, 26 Feb 2003 17:59:17 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Feb 2003 17:59:17 +0100 Message-ID: From: "Jari Arkko (LMF)" To: "'ietf-send@standards.ericsson.net'" , "'greg.daley@eng.monash.edu.au'" , "'kempf@docomolabs-usa.com'" Subject: Re: SEND Protocol Draft Now Available Date: Wed, 26 Feb 2003 17:59:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@prdxweb.sw.ericsson.se Precedence: bulk Greg Daley wrote: > Just going through the draft now. > > I have a query: > > in section 6.6 paragraph 2, is the text referring > to a Router Advertisement or a Delegation Chain > Advertisement? Oops you caught me copying the rules from RFC 2461 ;-) It should say DCA. Thanks, Jari P.S. I hope you don't receive any duplicates. This is the third time I try to post this message. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------