From jari.arkko@lmf.ericsson.se Wed Oct 1 05:48:19 2003 Received: from albatross-ext.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 FAA05687 for ; Wed, 1 Oct 2003 05:48:18 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h919jplN027116; Wed, 1 Oct 2003 11:45:51 +0200 (MEST) 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 T6YN1PYL; Wed, 1 Oct 2003 11:48:43 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h919joxa020806; Wed, 1 Oct 2003 11:45:50 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h919hVme021799; Wed, 1 Oct 2003 11:43:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h919hVUI021798; Wed, 1 Oct 2003 11:43:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h919hTme021788 for ; Wed, 1 Oct 2003 11:43:30 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 04BF41C; Wed, 1 Oct 2003 12:56:48 +0300 (EEST) Message-ID: <3F7AA1C7.2030805@nomadiclab.com> Date: Wed, 01 Oct 2003 12:43:35 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: Jonathan Wood , SEND WG , Francis Dupont Subject: Re: Issue 22: Part 2: Timestamp Delta time References: <3F6ADBE9.6010209@ericsson.com> <3F6C58FF.3060102@kolumbus.fi> In-Reply-To: <3F6C58FF.3060102@kolumbus.fi> 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 [Resending to the list, apparently the list failed on me again. Sorry if you see this multiple times.] Jari Arkko wrote: > I agree with Jon that it seems like it is still possible > to fill the cache. The point is that attackers can come up > with new (perhaps precomputed) CGA addresses, and the timestamp > cache needs to be per source in multicast messages. Tuomas' > CGA generation formula does prevent the attack if Sec > 0, > but we may not be able to rely on that, or can we? > > But there seems to be two ways to deal with unbounded > caches, like the ones that exist for tracking something > related to a the source address of a packet. > > 1. Throw out entries. > 2. Reduce the allowed clock difference. > > In the past, I have assumed we are doing #2. Though I can't > claim I have thought it through fully. Here's what #2 would > do: if there is no lack of space, accept all messages and store > all cache entries that have used a timestamp within Delta. If > you can store only half of the entries that would be required > for this, reduce Delta to half and remove those entries that > were furthest away from the node's own time. If the attacker > is sending you a constant stream of messages from new source > addresses with exactly the right time, reduce Delta to 0. > At this point, you can still communicate with legitimate peers, > but only if they have exactly the same clock as you do. When > new space becomes available, Delta can again be increased. > > Does this work? You tell me... I think that we basically have two distinct attack scenarios: 1. There are a number of hosts on a link, and someone launches an attack. The goal here is clearly make sure that the hosts can continue to communicate even if the attack is going on. 2. There is an attack going on, and a new host arrives to the link. The goal here is to make it possible for the new host to become attached to the network, inspite of the attack. From this point of view, it is clearly better to be very selective in how to throw out entries. Reducing Delta is very discriminative against those hosts that have a large clock difference, while an attacker can reduce its clock difference into arbitrarily small. Throwing out old entries just because their clock difference is large seems like a bad approach. In my opinion, the exact algorithm for expiring cache entries in the case of a full cache is clearly a local policy issue, and should not be specified in the document. However, it might be a good idea to give some guidance for implementors. It also looks like that all the previous ideas of reducing Delta are really bad, since the attacker can easily select its own Delta, and make it whatever small. A better idea seems to be to have a separate cache space for new entries and old entries, and under an attack more eagerly drop new cache entries than old ones. One could track traffic, and only allow those new entries that receive genuine traffic to be converted into old cache entries. It also looks like a good idea to consider the sec parameter when forcing cache entries out, and let those entries with a larger sec a higher chance of staying in. --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 Oct 1 05:48:32 2003 Received: from penguin-ext.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 FAA05716 for ; Wed, 1 Oct 2003 05:48:31 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h919kAN1003735; Wed, 1 Oct 2003 11:46:14 +0200 (MEST) 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 T6YM0MXC; Wed, 1 Oct 2003 11:47:04 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h919k1xR007042; Wed, 1 Oct 2003 11:46:01 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h919hlme021819; Wed, 1 Oct 2003 11:43:47 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h919hlqN021818; Wed, 1 Oct 2003 11:43:47 +0200 (MET DST) 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 sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h919hkme021814 for ; Wed, 1 Oct 2003 11:43:46 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6A7B11C for ; Wed, 1 Oct 2003 12:57:04 +0300 (EEST) Message-ID: <3F7AA1D8.6090809@nomadiclab.com> Date: Wed, 01 Oct 2003 12:43:52 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Issue 11: Timestamp processing issues, nonce vs. timestamp 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 [Resending to the list, apparently the list failed on me again. Sorry if you see this multiple times.] Since we decided to move to the ND options based approach, issue 11 seems to boil down to the following: 1. Always process nonces from solicitated messages first, and if the nonce and signatures are verified OK, do create a cache entry even if the clock difference is larger than delta. 2. If timestamp checking is enabled for all inbound NSs, nodes with bad clocks can't get our address. So, a sensible rule might be that "in case of invalid timestamp in a received NS, still respond to the message, but don't create a neighbor cache entry". Both of these look doable with the new Issue 22 new method of handling separately Delta and clock drift. Hence, should we adopt the approach above? --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 Oct 1 06:34:29 2003 Received: from penguin-ext.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 FAA05690 for ; Wed, 1 Oct 2003 05:48:19 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h919kAN1003736; Wed, 1 Oct 2003 11:46:14 +0200 (MEST) 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 T6YN1P6F; Wed, 1 Oct 2003 11:49:03 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h919juxR007032; Wed, 1 Oct 2003 11:45:56 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h919i8me021854; Wed, 1 Oct 2003 11:44:08 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h919i7G3021853; Wed, 1 Oct 2003 11:44:07 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h919i7me021849 for ; Wed, 1 Oct 2003 11:44:07 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 56C711C; Wed, 1 Oct 2003 12:57:25 +0300 (EEST) Message-ID: <3F7AA1EC.4070601@nomadiclab.com> Date: Wed, 01 Oct 2003 12:44:12 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jonwood@speakeasy.net Cc: Jari Arkko , SEND WG , Francis Dupont Subject: Re: Issue 22: Part 2: Timestamp Delta time References: In-Reply-To: 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 [Resending to the list, apparently the list failed on me again. Sorry if you see this multiple times.] [Reordered quotes to make answering easier] > I think it is becoming apparent that a method that will fully prevent > replay attacks will be very complex to implement and administer. I don't believe it is possible to fully prevent reply attacks, given all the other requirements we have. Hence, the real question is to find out what is reasonable effort and what is clearly too little. Furthermore, as I wrote ... >> In my opinion, the exact algorithm for expiring cache entries >> in the case of a full cache is clearly a local policy issue,... ... we probably do not want to specify too much in the doc. More like hints and concerns than a recommendation for a full blown algorithm. >> ... seems to be to have a separate cache space for new entries and >> old entries, and under an attack more eagerly drop new cache >> entries than old ones. One could track traffic, and only allow >> those new entries that receive genuine traffic to be converted >> into old cache entries. >> >> It also looks like a good idea to consider the sec parameter >> when forcing cache entries out, and let those entries with >> a larger sec a higher chance of staying in. > While such a scheme would make attacks harder, it would not > fully prevent them. For example, an attacker could send a little > traffic (i.e. a ping or TCP syn) after each NS to trick the victim into > promoting its cache entry to the old cache. Right. The whole point is to make the effort required by an attacker higher. If an attacker has to generate a number of keys with sec > 0, change its MAC address, send not only unsoliciated messages but also trigger solications and answer them, and also send some regular traffic, it needs to do quite a lot of work. That reduces the "appeal" of the cache filling attacks, probably leading a potential attacker to try to find a weaker spot somewhere else. > Perhaps we should drop the cache idea altogether, and just use > timestamp delta checking? The security provided, while not perfect, > could still be reasonably good (depending on the local policy). It > would also be very simple for locals admins to understand and tweak. I think having Delta and cache dropping separately seem like a good idea. It clearly improves resiliance in many situations. For example, it even allows hosts with a large clock difference to communicate if they somehow are able to create cache entries through solicited (nonce carrying) packets. On the other hand, I think we can leave all these concerns as SHOULD, and leave the implementation the freedom to ignore them and just use e.g. Delta, if really needed. --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 Oct 1 11:24:36 2003 Received: from albatross-ext.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 LAA18594 for ; Wed, 1 Oct 2003 11:24:35 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h91FMRlN017615; Wed, 1 Oct 2003 17:22:27 +0200 (MEST) 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 T6Y2BJF4; Wed, 1 Oct 2003 17:23:38 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h91FMQxa000063; Wed, 1 Oct 2003 17:22:26 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h91FLcme027326; Wed, 1 Oct 2003 17:21:38 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h91FLco7027325; Wed, 1 Oct 2003 17:21:38 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h91FLame027287 for ; Wed, 1 Oct 2003 17:21:37 +0200 (MET DST) Message-ID: <007701c3882f$b8f39f00$956015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" References: <3F7AA1D8.6090809@nomadiclab.com> Subject: Re: Issue 11: Timestamp processing issues, nonce vs. timestamp Date: Wed, 1 Oct 2003 08:21:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Agree. jak \ ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Sent: Wednesday, October 01, 2003 2:43 AM Subject: Issue 11: Timestamp processing issues, nonce vs. timestamp > [Resending to the list, apparently the list failed on > me again. Sorry if you see this multiple times.] > > Since we decided to move to the ND options based approach, > issue 11 seems to boil down to the following: > > 1. Always process nonces from solicitated messages first, > and if the nonce and signatures are verified OK, do create > a cache entry even if the clock difference is larger > than delta. > > 2. If timestamp checking is enabled for all inbound NSs, nodes > with bad clocks can't get our address. So, a sensible rule > might be that "in case of invalid timestamp in a received NS, > still respond to the message, but don't create a neighbor > cache entry". > > Both of these look doable with the new Issue 22 new method > of handling separately Delta and clock drift. > > Hence, should we adopt the approach above? > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Oct 6 00:49:47 2003 Received: from penguin-ext.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 AAA05509 for ; Mon, 6 Oct 2003 00:49:46 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h964iIN1023183; Mon, 6 Oct 2003 06:44:19 +0200 (MEST) 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 T6Y29SFV; Mon, 6 Oct 2003 06:45:47 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h964iHXA026971; Mon, 6 Oct 2003 06:44:17 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h964gume014884; Mon, 6 Oct 2003 06:42:56 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h964guoO014883; Mon, 6 Oct 2003 06:42:56 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h964gsme014879 for ; Mon, 6 Oct 2003 06:42:54 +0200 (MET DST) Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id BDFD9279514 for ; Mon, 6 Oct 2003 00:42:52 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Mon, 06 Oct 2003 00:42:52 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id B4C4074B7D; Mon, 6 Oct 2003 00:42:52 -0400 (EDT) Content-Disposition: inline Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ietf-send@standards.ericsson.net Date: Mon, 06 Oct 2003 10:12:52 +0530 X-Epoch: 1065415372 X-Sasl-enc: tYECP9eip7veGX5qQ2lqaw Subject: Comments on draft-ietf-send-psreq-03 Message-Id: <20031006044252.B4C4074B7D@smtp.us2.messagingengine.com> X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h964gtme014880 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tjatte.sw.ericsson.se id h964iHXA026971 Content-Transfer-Encoding: quoted-printable Hello, I went over the draft during the weekend, and jotted down few comments. CP Technical comments ------------------- 1. Threats for a L2-switch, and ND-proxies. L2-switches, and ND- proxies build their neighbor cache by snooping the source IPv6 address, and the corresponding link-layer address. It is possible to send fake NS/NA/RA/RD/redirect/Data (any packet which is used to build the neighbor cache), and do a redirect/DOS attack. I think section 4 should list a threat concerning such devices. 2. Flood DoS is described in section 4, but none of the attack is listed as "Flood DoS". I haven=92t evaluated the attacks for this one, but a quick scan shows that 4.1.1 qualifies as Flood DoS. 3. Section 4.2.1. a. What is the "entering node"? b. I might be a bit confused - isn=92t the section referring to th= e first-hop router? Can you also give the reference number to a section number in RFC2461 talks of this threat? c. The 3rd paragraph talks of RFC 2461, and 2462. Is there a conflict between these two documents? I am not able to understand why the default router selection procedure in section 6.3.6 needs a rule that concerns with the lifetime of the router. 4. Mention the type of attack in section 4.2.2. Editorial comments ------------------ 5. Reorganize the text concerning threats in section 4. The flow of text for all the text is not similar. It hampers readability, and it is difficult to identify the missing pieces. For example, section 5.1.2 does not mention the type of attack. My suggestion is that the text for each threat should be divided amongst the following headings. (More headings may be headed as required) ------------------------------------------------------------------ THREAT DESCRIPTION TYPE OF ATTACK EXTENSIONS MESSAGES INVOLVED THREAT ANALYSIS AND SOLUTIONS ------------------------------------------------------------------ As an example let me rewrite the threat listed in Section 4.1.3. ------------------------------------------------------------------ THREAT DESCRIPTION In networks where the entering hosts obtain their addresses using stateless address autoconfiguration [4], an attacking node could launch a DoS attack by responding to every duplicate address detection attempt made by an entering host. If the attacker claims the address, then the host will never be able to obtain an address. The attacker can claim the address in two ways: it can either reply with an NS, simulating that it is performing DAD, too, or it can reply with an NA, simulating that it has already taken the address into use. This threat was identified in RF2462 [4]. TYPE OF ATTACK DoS. EXTENSIONS None. MESSAGES INVOLVED NS/NA THREAT ANALYSIS AND SOLUTIONS 1. Model 1. This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes become exposed to this DoS threat. Solution : The operator may act as an authorizer, keeping track of allocated addresses and making sure that no node has allocated more than a few (hundreds of) addresses. On the other hand, it may be detrimental to adopt such a practice, since there may be situations where it is desirable for one node to have a large number of addresses, e.g, creating a separate address per TCP connection, or when running an ND proxy. Thus, it may be inappropriate to suggest that ISPs could control how many addresses a legitimate host can have; the discussion above must be considered only as examples, as stated in the beginning of this draft. 2. Model 2, and 3. This attack can be performed in both these models, as there is no trust relationship between the nodes. Solution : The node performing DAD is able to verify whether the sender of the NA response is authorized to use the given IP address or not. Solution : For model 3, one may want to structure the addresses in such a way that self authorization is possible. ------------------------------------------------------------------ I found it a bit tedious to correlate the "+,-,R" symbols in the=20 trust columns with the actual threat description. After the rewrite,=20 it should be easy to do that. 6. Abstract. Rephrase the last sentence to "The output forms a clear problem statement and a set of requirements for Securing IPv6 Neighbor Discovery." 7. Section 4.2.5, 3rd paragraph. s/finite system/system with finite resources/ 8. Section 4.2.6. 5th paragraph. s/target link will get all replies/target link may get replies/ -------------------------------------------------------------------- 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 Oct 6 15:58:52 2003 Received: from albatross-ext.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 PAA19523 for ; Mon, 6 Oct 2003 15:58:51 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h96JqqlN008325; Mon, 6 Oct 2003 21:52:56 +0200 (MEST) 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 T6Y3R82Y; Mon, 6 Oct 2003 21:54:01 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h96Jqmwg028704; Mon, 6 Oct 2003 21:52:49 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h96JpsB5029291; Mon, 6 Oct 2003 21:51:54 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h96JpsjI029290; Mon, 6 Oct 2003 21:51:54 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h96JprB5029286 for ; Mon, 6 Oct 2003 21:51:53 +0200 (MET DST) Received: from piuha.net ([62.248.153.78]) by fep21-app.kolumbus.fi with ESMTP id <20031006195153.XEAW17285.fep21-app.kolumbus.fi@piuha.net>; Mon, 6 Oct 2003 22:51:53 +0300 Message-ID: <3F815998.3090404@kolumbus.fi> Date: Mon, 06 Oct 2003 15:01:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG Subject: Re: Issue 11: Timestamp processing issues, nonce vs. timestamp References: <3F7AA1D8.6090809@nomadiclab.com> In-Reply-To: <3F7AA1D8.6090809@nomadiclab.com> 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 Pekka Nikander wrote: > [Resending to the list, apparently the list failed on > me again. Sorry if you see this multiple times.] > > Since we decided to move to the ND options based approach, > issue 11 seems to boil down to the following: > > 1. Always process nonces from solicitated messages first, > and if the nonce and signatures are verified OK, do create > a cache entry even if the clock difference is larger > than delta. > > 2. If timestamp checking is enabled for all inbound NSs, nodes > with bad clocks can't get our address. So, a sensible rule > might be that "in case of invalid timestamp in a received NS, > still respond to the message, but don't create a neighbor > cache entry". > > Both of these look doable with the new Issue 22 new method > of handling separately Delta and clock drift. > > Hence, should we adopt the approach above? Yes. --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 Mon Oct 6 15:58:55 2003 Received: from albatross-ext.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 PAA19540 for ; Mon, 6 Oct 2003 15:58:54 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h96JqtlN008329; Mon, 6 Oct 2003 21:52:55 +0200 (MEST) 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 T6YTP2SJ; Mon, 6 Oct 2003 21:55:53 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h96Jqswg028714; Mon, 6 Oct 2003 21:52:54 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h96Jq2B5029304; Mon, 6 Oct 2003 21:52:02 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h96Jq1U5029303; Mon, 6 Oct 2003 21:52:01 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h96Jq1B5029298 for ; Mon, 6 Oct 2003 21:52:01 +0200 (MET DST) Received: from piuha.net ([62.248.153.78]) by fep21-app.kolumbus.fi with ESMTP id <20031006195200.XEBI17285.fep21-app.kolumbus.fi@piuha.net>; Mon, 6 Oct 2003 22:52:00 +0300 Message-ID: <3F81765B.4050702@kolumbus.fi> Date: Mon, 06 Oct 2003 17:04:11 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG Subject: Re: Issue 22: Part 2: Timestamp Delta time References: <3F6ADBE9.6010209@ericsson.com> <3F6C58FF.3060102@kolumbus.fi> <3F7AA1C7.2030805@nomadiclab.com> In-Reply-To: <3F7AA1C7.2030805@nomadiclab.com> 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 Pekka Nikander wrote: > From this point of view, it is clearly better to be very > selective in how to throw out entries. Reducing Delta > is very discriminative against those hosts that have a > large clock difference, while an attacker can reduce its > clock difference into arbitrarily small. Throwing out old > entries just because their clock difference is large seems > like a bad approach. Ok, I'm convinced. > In my opinion, the exact algorithm for expiring cache entries > in the case of a full cache is clearly a local policy issue, > and should not be specified in the document. However, it might > be a good idea to give some guidance for implementors. > > It also looks like that all the previous ideas of reducing > Delta are really bad, since the attacker can easily select > its own Delta, and make it whatever small. A better idea > seems to be to have a separate cache space for new entries and > old entries, and under an attack more eagerly drop new cache > entries than old ones. One could track traffic, and only allow > those new entries that receive genuine traffic to be converted > into old cache entries. Ok. We could perhaps say the following: "When there is a very large number of hosts on the same link, or when an attack is in progress, it is possible that the cache holding the most recent timestamp per sender becomes full. In this case the node MUST remove some entries from the cache or refuse some new requested entries. The specific policy as to which entries are preferred over the others is left as an implementation decision. However, typical policies may prefer existing entries over new ones, CGAs with a large Sec value over smaller Sec values, and so on." > It also looks like a good idea to consider the sec parameter > when forcing cache entries out, and let those entries with > a larger sec a higher chance of staying in. Yes. --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 Mon Oct 13 02:39:05 2003 Received: from penguin-ext.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 CAA24725 for ; Mon, 13 Oct 2003 02:39:03 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9D6YE42018778; Mon, 13 Oct 2003 08:34:15 +0200 (MEST) 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 43DMRM6W; Mon, 13 Oct 2003 08:37:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9D6Xrwg015663; Mon, 13 Oct 2003 08:33:54 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9D6WhB5025020; Mon, 13 Oct 2003 08:32:43 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9D6WhPY025019; Mon, 13 Oct 2003 08:32:43 +0200 (MET DST) 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 sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9D6WgB5025015 for ; Mon, 13 Oct 2003 08:32:42 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 86BAB1C; Mon, 13 Oct 2003 09:45:57 +0300 (EEST) Message-ID: <3F8A4711.9000904@ericsson.com> Date: Mon, 13 Oct 2003 09:32:49 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Tuomas Aura , Jari Arkko Subject: New Issue: Signature inconsistency between the CGA and NDOPTs drafts 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 Folks, I am (finally) finishing the first official WG version of the NDOPTs base spec, and editing in the resolutions for the issues solved at the list. (I am doing this as a proxy for Jari since he is currently unavailable). While doing my first round through the draft, I noticed an inconsistency between the CGA draft and the NDOPTs draft, wrt. to signatures. The CGA draft states as follows: To sign a message, a node SHOULD do the following: .... o Generate the RSA signature using the RSASSA-PKCS1-v1_5 [PKCS.1.1993] signature algorithm with the SHA-1 hash algorithm. The inputs to the generation operation are the private key and the concatenation created above. The NDOPTs draft states as follows: The signature is made using the RSA algorithm and MUST be encoded as private key encryption in PKCS #1 format [18]. The signature value is computed with the RSASSA-PKCS1-v2_1 algorithm and SHA-1 hash as defined in [18]. These seem to be in conflict. Which one is the right one, 1.5 or 2.1? I have never played with the exact details of signatures, and therefore I can't suggest either. --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 Mon Oct 13 03:24:18 2003 Received: from albatross-ext.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 DAA25432 for ; Mon, 13 Oct 2003 03:24:18 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9D7MJlN014369; Mon, 13 Oct 2003 09:22:19 +0200 (MEST) 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 43DMR9FW; Mon, 13 Oct 2003 09:25:26 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9D7L2wg017533; Mon, 13 Oct 2003 09:21:02 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9D7JuB5005601; Mon, 13 Oct 2003 09:19:56 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9D7Jutv005599; Mon, 13 Oct 2003 09:19:56 +0200 (MET DST) 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 sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9D7JsB5005592 for ; Mon, 13 Oct 2003 09:19:54 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 38F7E1C for ; Mon, 13 Oct 2003 10:33:09 +0300 (EEST) Message-ID: <3F8A5221.1040902@ericsson.com> Date: Mon, 13 Oct 2003 10:20:01 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: New issue?: The scope of source address for DCS? 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 Folks, With regard to the DCS source address, the current spec says the following: An IP address assigned to the sending interface, or the unspecified address if no address is assigned to the sending interface. Should we be more specific, and say that the source address SHOULD be the link local address? Right now I don't see any specific reason, other than the old saying of being conservative when sending and liberal when receiving. I didn't find anything in the outstanding issues, but maybe I just missed it? --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 Mon Oct 13 04:01:36 2003 Received: from albatross-ext.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 EAA25990 for ; Mon, 13 Oct 2003 04:01:35 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9D802lN027298; Mon, 13 Oct 2003 10:00:02 +0200 (MEST) 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 43DWWWD2; Mon, 13 Oct 2003 10:03:25 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9D7xrwg019396; Mon, 13 Oct 2003 09:59:53 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9D7xHB5013973; Mon, 13 Oct 2003 09:59:17 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9D7xH2W013972; Mon, 13 Oct 2003 09:59:17 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9D7xGB5013968 for ; Mon, 13 Oct 2003 09:59:16 +0200 (MET DST) Received: from mta.imail.kolumbus.fi ([193.229.5.108]) by fep01-app.kolumbus.fi with ESMTP id <20031013075915.PTJ25024.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi>; Mon, 13 Oct 2003 10:59:15 +0300 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: New Issue: Signature inconsistency between the CGA and NDOPTs drafts Date: Mon, 13 Oct 2003 10:59:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031013075915.PTJ25024.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > These seem to be in conflict. Which one is the right one, 1.5 or 2.1? 2.1. This issue was raised earlier by Pasi Eronen and Valtteri Niemi, registered as issue #9. They were right, I think. I edited a fix for this issue in an intermediate draft version, which you have. So it looks like the CGA draft needs to be changed in this respect. --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 Mon Oct 13 06:57:35 2003 Received: from albatross-ext.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 GAA29979 for ; Mon, 13 Oct 2003 06:57:34 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9DArUlN026212; Mon, 13 Oct 2003 12:53:31 +0200 (MEST) 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 43DMT0DZ; Mon, 13 Oct 2003 12:57:14 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9DArTXA002544; Mon, 13 Oct 2003 12:53:29 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DAqsB5024097; Mon, 13 Oct 2003 12:52:54 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9DAqsMg024096; Mon, 13 Oct 2003 12:52:54 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DAqrB5024092 for ; Mon, 13 Oct 2003 12:52:53 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 0B08A1C; Mon, 13 Oct 2003 14:06:09 +0300 (EEST) Message-ID: <3F8A840D.5040102@ericsson.com> Date: Mon, 13 Oct 2003 13:53:01 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Francis Dupont Subject: Closing issue 19: Allow autoconfig even with non-CGA addrs e.g. ::1 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 has requirested to allow the use of non-CGA addresses instead of CGA addresses, and to use certificates to authorize to use of such addresses. This is OK and in line with the earlier discussions at the WG. To clarify this, the following changes to the document were requested and made: >> - same (comment/request for improvement) >> >> o Cryptographically Generated Addresses are used to assure that the >> sender of a Neighbor or Router Advertisement is the owner of an >> the claimed address. A public-private key pair needs to be >> generated by all nodes before they can claim an address. >> >> => this suggests that all addresses should be CGAs. Of course this >> is only one of the two cases: >> - certified addresses (always the case for universal or static IID) >> - CGAs (which always give local IID) Proposed resolution: Added the following new text after the old text: This specification also allows one to use non-CGA addresses and to use certificates to authorized their use. However, the details of such use have been left for future work. >> - 8.3 Other Requirements (comment) >> >> Hosts that use stateless address autoconfiguration MUST generate a >> new CGA as specified in Section 4 of [27] for each new >> autoconfiguration run. >> >> => I disagree: nodes should have the choice between using a certified >> IID or a CGA based IID. My main name-server is a host and I don't >> want to use CGA for it for many reasons. Of course, I use stateless >> autoconfig even I've switched from EID64 IID to ::1 IID some months >> ago. Proposed resolution: Replace the text above with a new one: Hosts that use stateless address autoconfiguration, SHOULD generate a new CGA as specified in Section 4 of [27] for each new autoconfiguration run. The hosts MAY continue to use the same public key and modifier, and start the process from Step 4. For natural reasons, hosts that are configured with a static address (e.g. PREFIX::1), cannot use CGA. They SHOULD acquire a certificate and use certificate chain based authorization. >> It is outside the scope of this specification to describe the use of >> trusted root authorization between hosts with dynamically changing >> addresses. Such dynamically changing addresses may be the result of >> stateful or stateless address autoconfiguration or through the use of >> RFC 3041 [9]. If the CGA method is not used, hosts would be required >> to exchange certificate chains that terminate in a certificate >> authorizing a host to use an IP address having a particular interface >> identifier. This specification does not specify the format of such >> certificates, since there are currently a few cases where such >> certificates are required by the link layer and it is up to the link >> layer to provide certification for the interface identifier. This >> may be the subject of a future specification. >> >> => this is not sound with the MUST of the previous paragraph. >> And not with all the CGA=yes/no in next sections... This should be consistent now, with the above addition, shouldn't it? Unless anyone objects, I will consider this issue now Solved with these changes. --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 Mon Oct 13 07:42:35 2003 Received: from penguin-ext.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 HAA00762 for ; Mon, 13 Oct 2003 07:42:34 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9DBed42020644; Mon, 13 Oct 2003 13:40:39 +0200 (MEST) 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 43DSSDWG; Mon, 13 Oct 2003 13:40:56 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9DBecXA003660; Mon, 13 Oct 2003 13:40:38 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DBdxB5005147; Mon, 13 Oct 2003 13:39:59 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9DBdx7l005145; Mon, 13 Oct 2003 13:39:59 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DBdwB5005138 for ; Mon, 13 Oct 2003 13:39:58 +0200 (MET DST) Received: from mta.imail.kolumbus.fi ([193.229.5.108]) by fep01-app.kolumbus.fi with ESMTP id <20031013113958.CUIQ25024.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi>; Mon, 13 Oct 2003 14:39:58 +0300 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: Closing issue 19: Allow autoconfig even with non-CGA addrs e.g. ::1 Date: Mon, 13 Oct 2003 14:39:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031013113958.CUIQ25024.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, I agree with the principle of what you are trying to do. But I wonder if we can simultaneously leave the cert-based scheme details outside the scope of the specification and have a keyword in the following text: For natural reasons, hosts that are configured with a static address (e.g. PREFIX::1), cannot use CGA. They SHOULD acquire a certificate and use certificate chain based authorization. How about changing this text to This specification does not address the protection of Neighbor Discovery packets for hosts that are configured with a static address (e.g., PREFIX::1). Future certificate chain based authorization specifications are needed for such hosts. --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 Mon Oct 13 07:59:51 2003 Received: from penguin-ext.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 HAA01355 for ; Mon, 13 Oct 2003 07:59:50 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9DBw042026066; Mon, 13 Oct 2003 13:58:01 +0200 (MEST) 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 43DSS2WJ; Mon, 13 Oct 2003 13:58:16 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9DBvvXA004064; Mon, 13 Oct 2003 13:57:57 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DBvPB5009168; Mon, 13 Oct 2003 13:57:25 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9DBvPgc009167; Mon, 13 Oct 2003 13:57:25 +0200 (MET DST) 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 [81.255.54.11]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DBvOB5009162 for ; Mon, 13 Oct 2003 13:57:24 +0200 (MET DST) Received: from gbl-dhcp-198-236.europe.research.sun.com (194.2.198.236) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3F683B1D006482EE for ietf-send@standards.ericsson.net; Mon, 13 Oct 2003 13:57:23 +0200 From: Julien Laganier To: ietf-send@standards.ericsson.net Subject: Source Address Selection and CGA relationship Date: Mon, 13 Oct 2003 13:55:56 +0200 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200310131355.56526.julien.laganier@laposte.net> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I have a couple of questions regarding the dependance between SEND and default address selections algorithms [RFC3484]. While using SEND, a node only benefits from SEND if itself and its on-link correspondent (that is, either an on-link router or the other communication endpoint if it's on-link) both uses a CGA to mutually denotes each other. Hence, perhaps the SEND protocol specification should state that: "Rule X: Prefer CGA. If SA is a CGA and SB is not, then prefer SA." ? In case the remaining questions being: o Where should this check be done relatively to others source address selection rules (like home/CoA or public/tmp checks)? o Should the sense of this preference be reversible for (mostly diagnostic) applications that aren't interested in having a "secure" network (e.g., parallel fping) ? An addendum might be "Implementations MUST/SHOULD provide a mechanism allowing an application to reverse the sense of this preference and prefer non-CG-Addresses over CG-Addresses (e.g., via appropriate API extensions)." What do you folks think? BTW, I co-authored a draft about a source address selection API allowing to tweak RFC3484 specified default behavior that partly address the CGA case: 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 Mon Oct 13 12:40:56 2003 Received: from albatross-ext.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 MAA14628 for ; Mon, 13 Oct 2003 12:40:55 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9DGcVlN016010; Mon, 13 Oct 2003 18:38:31 +0200 (MEST) 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 43DMXGJY; Mon, 13 Oct 2003 18:42:11 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9DGcPXA009795; Mon, 13 Oct 2003 18:38:25 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DGbYB5015236; Mon, 13 Oct 2003 18:37:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9DGbYd6015235; Mon, 13 Oct 2003 18:37:34 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DGbXB5015224 for ; Mon, 13 Oct 2003 18:37:33 +0200 (MET DST) Received: from ericsson.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 21B6A1C; Mon, 13 Oct 2003 19:50:48 +0300 (EEST) Message-ID: <3F8AD4D3.7000500@ericsson.com> Date: Mon, 13 Oct 2003 19:37:39 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@kolumbus.fi Cc: ietf-send@standards.ericsson.net, Francis Dupont Subject: Re: Closing issue 19: Allow autoconfig even with non-CGA addrs e.g. ::1 References: <20031013113958.CUIQ25024.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> In-Reply-To: <20031013113958.CUIQ25024.fep01-app.kolumbus.fi@mta.imail.kolumbus.fi> 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 jari.arkko@kolumbus.fi wrote: > I agree with the principle of what you are trying to do. > But I wonder if we can simultaneously leave the cert-based > scheme details outside the scope of the specification and > have a keyword in the following text: > > For natural reasons, hosts that are configured with a static > address (e.g. PREFIX::1), cannot use CGA. They SHOULD acquire > a certificate and use certificate chain based authorization. > > How about changing this text to > > This specification does not address the protection of > Neighbor Discovery packets for hosts that are configured > with a static address (e.g., PREFIX::1). Future certificate > chain based authorization specifications are needed for > such hosts. Ok to me. Changed for now. Still waiting possible ack/nack from Francis. --Pekka -------------------------------------------------------------------- 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 Oct 13 14:39:52 2003 Received: from albatross-ext.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 OAA19527 for ; Mon, 13 Oct 2003 14:39:51 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9DIc5lN004032; Mon, 13 Oct 2003 20:38:06 +0200 (MEST) 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 45JW83PF; Mon, 13 Oct 2003 20:41:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9DIbvXA010943; Mon, 13 Oct 2003 20:37:57 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DIbIB5013013; Mon, 13 Oct 2003 20:37:18 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9DIbIsv013012; Mon, 13 Oct 2003 20:37:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DIbHB5012998 for ; Mon, 13 Oct 2003 20:37:17 +0200 (MET DST) Received: from ericsson.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 681761C; Mon, 13 Oct 2003 21:50:31 +0300 (EEST) Message-ID: <3F8AF0E3.8070401@ericsson.com> Date: Mon, 13 Oct 2003 21:37:23 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Francis Dupont Subject: Processing issue 16: Editorial issues from Francis Dupont 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 Issue 16 is all editorial. Some of the remarks have been obsoleted by other changes to the draft, and the others have now been applied with the exception of one comment, which I am discussing privately with Jari and Francis. The details of the issue are available at http://www.arkko.com/publications/send/issues/issue16.txt The comments to the ND overview section were quite extensive, leading to (at least almost) substantial changes. Therefore I am including the new text here: The NDP messages are always meant to be used within a link, and never intended to leak outside of it. The destination and source addresses used in these messages are as follows: o Neighbor Solicitation: The destination address is either the solicited-node multicast address, a unicast address, or an anycast address. The source address is either the unspecified address (in DAD) or a unicast address assigned to the sending interface. In a typical case, the source address is equal to the source address of the outgoing packet, locally triggering the need to send the solicitation. o Neighbor Advertisement: The destination address is either a unicast address or the all nodes multicast address [13]. The source address is a unicast address assigned to the sending interface. o Router Solicitation: The destination address is typically the all routers multicast address [13]. The source address is either the unspecified address or a unicast address assigned to the sending interface. An unspecified source address does not have any special semantics; it is just an optimization for startup. o Router Advertisement: The destination address can be either a unicast or the all nodes multicast address [13]. The source address is a link-local address assigned to the sending interface. o Redirect: This message is always sent to the source address of the packet that triggered the Redirect. Hosts verify that the IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. Rules in [13] dictate that anycast, or multicast addresses may not be used as source addresses. If the source address is an unspecified address, it is impossible to send a Redirect, since the unspecified address is forbidden as the destination address. Therefore, the destination address must always be a unicast address. The source address is a link-local address assigned to the sending interface. Comments? [13] is RFC 3513. Once I get the one remaining comment resolved, I will send another e-mail, and close the issue, unless there are further comments. --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 Mon Oct 13 14:54:49 2003 Received: from albatross-ext.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 OAA20017 for ; Mon, 13 Oct 2003 14:54:48 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9DIqmlN005935; Mon, 13 Oct 2003 20:52:48 +0200 (MEST) 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 43DSWMNZ; Mon, 13 Oct 2003 20:53:06 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9DIqlXA011083; Mon, 13 Oct 2003 20:52:47 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DIqLB5016431; Mon, 13 Oct 2003 20:52:21 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9DIqLam016429; Mon, 13 Oct 2003 20:52:21 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9DIqIB5016425 for ; Mon, 13 Oct 2003 20:52:19 +0200 (MET DST) Message-ID: <066801c391bb$231b4f10$956015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" Cc: "Francis Dupont" References: <3F8A840D.5040102@ericsson.com> Subject: Re: Closing issue 19: Allow autoconfig even with non-CGA addrs e.g. ::1 Date: Mon, 13 Oct 2003 11:52:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I think there might be an issue with saying that cert-based SEND is FFS and then saying that hosts with static addresses SHOULD use it. Or? jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Cc: "Francis Dupont" Sent: Monday, October 13, 2003 3:53 AM Subject: Closing issue 19: Allow autoconfig even with non-CGA addrs e.g. ::1 > Francis Dupont has requirested to allow the use of non-CGA > addresses instead of CGA addresses, and to use certificates > to authorize to use of such addresses. This is OK and in > line with the earlier discussions at the WG. To clarify > this, the following changes to the document were requested > and made: > > >> - same (comment/request for improvement) > >> > >> o Cryptographically Generated Addresses are used to assure that the > >> sender of a Neighbor or Router Advertisement is the owner of an > >> the claimed address. A public-private key pair needs to be > >> generated by all nodes before they can claim an address. > >> > >> => this suggests that all addresses should be CGAs. Of course this > >> is only one of the two cases: > >> - certified addresses (always the case for universal or static IID) > >> - CGAs (which always give local IID) > > Proposed resolution: Added the following new text after the old text: > > This specification also allows one to use non-CGA addresses > and to use certificates to authorized their use. However, > the details of such use have been left for future work. > > >> - 8.3 Other Requirements (comment) > >> > >> Hosts that use stateless address autoconfiguration MUST generate a > >> new CGA as specified in Section 4 of [27] for each new > >> autoconfiguration run. > >> > >> => I disagree: nodes should have the choice between using a certified > >> IID or a CGA based IID. My main name-server is a host and I don't > >> want to use CGA for it for many reasons. Of course, I use stateless > >> autoconfig even I've switched from EID64 IID to ::1 IID some months > >> ago. > > Proposed resolution: Replace the text above with a new one: > > Hosts that use stateless address autoconfiguration, SHOULD > generate a new CGA as specified in Section 4 of [27] for each > new autoconfiguration run. The hosts MAY continue to use the > same public key and modifier, and start the process from Step 4. > > For natural reasons, hosts that are configured with a static > address (e.g. PREFIX::1), cannot use CGA. They SHOULD acquire > a certificate and use certificate chain based authorization. > > > >> It is outside the scope of this specification to describe the use of > >> trusted root authorization between hosts with dynamically changing > >> addresses. Such dynamically changing addresses may be the result of > >> stateful or stateless address autoconfiguration or through the use of > >> RFC 3041 [9]. If the CGA method is not used, hosts would be required > >> to exchange certificate chains that terminate in a certificate > >> authorizing a host to use an IP address having a particular interface > >> identifier. This specification does not specify the format of such > >> certificates, since there are currently a few cases where such > >> certificates are required by the link layer and it is up to the link > >> layer to provide certification for the interface identifier. This > >> may be the subject of a future specification. > >> > >> => this is not sound with the MUST of the previous paragraph. > >> And not with all the CGA=yes/no in next sections... > > This should be consistent now, with the above addition, shouldn't it? > > Unless anyone objects, I will consider this issue now Solved with these > changes. > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Oct 14 02:35:49 2003 Received: from albatross-ext.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 CAA27523 for ; Tue, 14 Oct 2003 02:35:48 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9E6XMlN019434; Tue, 14 Oct 2003 08:33:23 +0200 (MEST) 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 43DM655W; Tue, 14 Oct 2003 08:37:09 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9E6XDXA015014; Tue, 14 Oct 2003 08:33:13 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9E6WVB5012450; Tue, 14 Oct 2003 08:32:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9E6WVeB012449; Tue, 14 Oct 2003 08:32:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9E6WTB5012445 for ; Tue, 14 Oct 2003 08:32:30 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id D95D11C; Tue, 14 Oct 2003 09:45:44 +0300 (EEST) Message-ID: <3F8B9884.6050201@ericsson.com> Date: Tue, 14 Oct 2003 09:32:36 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Pekka Nikander , SEND WG , Francis Dupont Subject: Re: Closing issue 19: Allow autoconfig even with non-CGA addrs e.g. ::1 References: <3F8A840D.5040102@ericsson.com> <066801c391bb$231b4f10$956015ac@dclkempt40> In-Reply-To: <066801c391bb$231b4f10$956015ac@dclkempt40> 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 James Kempf wrote: > I think there might be an issue with saying that cert-based SEND is FFS and > then saying that hosts with static addresses SHOULD use it. > > Or? Jari already noticed this, and provided some alternative text. I think his suggestion is ok: > This specification does not address the protection of Neighbor > Discovery packets for hosts that are configured with a static address > (e.g., PREFIX::1). Future certificate chain based authorization > specifications are needed for such hosts. --Pekka -------------------------------------------------------------------- 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 Oct 14 06:08:33 2003 Received: from penguin-ext.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 GAA02227 for ; Tue, 14 Oct 2003 06:08:32 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EA2Q42008328; Tue, 14 Oct 2003 12:02:27 +0200 (MEST) 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 43DS9L3T; Tue, 14 Oct 2003 12:02:46 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9EA2PXA018197; Tue, 14 Oct 2003 12:02:25 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9EA1WB5000517; Tue, 14 Oct 2003 12:01:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9EA1WGb000516; Tue, 14 Oct 2003 12:01:32 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9EA1VB5000512 for ; Tue, 14 Oct 2003 12:01:31 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 29F9F1C for ; Tue, 14 Oct 2003 13:14:46 +0300 (EEST) Message-ID: <3F8BC982.6010403@ericsson.com> Date: Tue, 14 Oct 2003 13:01:38 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Closing issues 11 and 22: Nonce and timestamp management 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 I have now tried to edit in the results of the dicussions on Issues 11 and 22. It has resulted in a new combined section for the Nonce and Timestamp options, and an appendix discussing the issue somewhat longer. I am including the new text below. If there are no comments, I will consider these issues closed. --Pekka Nikander 5.4 Timestamp and Nonce options 5.4.1 Timestamp Option 5.4.2 Nonce Option 5.4.3 Processing rules for senders All solicitation messages MUST include a Nonce. All solicited-for announcements MUST include a Nonce, copying the nonce value from the received solicitation. When sending a solication, the sender MUST store the nonce internally so that it can recognize any replies containing that particular nonce. All NDP messages MUST include a Timestamp. Senders SHOULD set the Timestamp field to the current time, according to their real time clock. If a message has both Nonce and a Timestamp options, the Nonce option MUST precede the Timestamp option in order. 5.4.4 Processing rules for receivers The processing of the Nonce and Timestamp options depends on whether a packet is a solicited-for advertisement or not. A system may implement the distinction in various means. Section 5.4.4.1 defines the processing rules for solicited-for advertisements. Section 5.4.4.2 defines the processing rules for all other messages. When there is a very large number of hosts on the same link, or when a cache filling attack is in progress, it is possible that the cache holding the most recent timestamp per sender becomes full. In this case the node MUST remove some entries from the cache or refuse some new requested entries. The specific policy as to which entries are preferred over the others is left as an implementation decision. However, typical policies may prefer existing entries over new ones, CGAs with a large Sec value over smaller Sec values, and so on. The issue is briefly discussed in Appendix C. 5.4.4.1 Processing solicited-for advertisements The receiver MUST verify that it has recently send a matching solicitation, and that the received advertisement does contain a copy of the Nonce sent in the solicitation. If the message does not contain a Nonce option, it MAY be considered as a non-solicited-for announcement, and processed according to Section 5.4.4.2. If the message does contain a Nonce option, but the Nonce value is not recognized, the message MUST be silently dropped. If the message is accepted, the receiver SHOULD store the receive time of the message and the time stamp time in the message, as specified in Section 5.4.4.2 5.4.4.2 Processing all other messages Receivers SHOULD be configured with an allowed timestamp Delta value and an allowed clock drift parameter. The recommended default value for the allowed Delta is 3,600 seconds (1 hour) and 1% for clock dritf. To facilitate timestamp checking, each node SHOULD store the following information per each peer: The receive time of the last received, acepted ND message. This is called RDlast. The time stamp in the last received, accepted ND message. This is called TSlast. Receivers SHOULD then check the Timestamp field as follows: o When a message is received from a new peer, i.e., one that is not stored in the cache, the received timestamp, TSnew, is checked and the packet is accepted if the timestamp is recent enough with respect to the receival time of the packet, RDnew: -Delta < (RDnew - TSnew) < +Delta The RDnew and TSnew values SHOULD be stored into the cache as RDlast and TSlast. o If the timestamp is NOT within the boundaries but the message is a Neighbor Solicitation message that should be responded to by the receiver, the receiver MAY respond to the message. However, if it does respond to the message, it MUST NOT create a neighbor cache entry. This allows hosts that have large difference in their clocks to still communicate with each other, by exchanging NS/NA pairs. o When a message is received from a known peer, i.e., one that already has an entry in the cache, the time stamp is check against the last received message: TSnew > TSlast + (RDnew - RDlast) x (1 - drift) o If TSnew < TSlast, which is possible if packets arrive rapidly and out of order, TSlast MUST NOT be updated, i.e., the stored TSlast for a given host MUST NOT ever decrease. Otherwise TSlast SHOULD be updated. RDlast MUST be updated in any case. ---------------------------- Appendix C. Cache Management In this section we outline a cache management algorithm that allows a host to remain partially functional even under a cache filling DoS attack. This appendix is informational, and real implementations SHOULD use different algorithms in order to avoid he dangers of monocultural code. There are at least two distinct cache related attack scenarios: 1. There are a number of hosts on a link, and someone launches a cache filling attack. The goal here is clearly make sure that the hosts can continue to communicate even if the attack is going on. 2. There is already a cache filling attack going on, and a new host arrives to the link. The goal here is to make it possible for the new host to become attached to the network, inspite of the attack. From this point of view, it is clearly better to be very selective in how to throw out entries. Reducing the timestamp Delta value is very discriminative against those hosts that have a large clock difference, while an attacker can reduce its clock difference into arbitrarily small. Throwing out old entries just because their clock difference is large seems like a bad approach. A reasonable idea seems to be to have a separate cache space for new entries and old entries, and under an attack more eagerly drop new cache entries than old ones. One could track traffic, and only allow those new entries that receive genuine traffic to be converted into old cache entries. While such a scheme will make attacks harder, it will not fully prevent them. For example, an attacker could send a little traffic (i.e. a ping or TCP syn) after each NS to trick the victim into promoting its cache entry to the old cache. Hence, the host may be more intelligent in keeping its cache entries, and not just have a black/white old/new boundary. It also looks like a good idea to consider the sec parameter when forcing cache entries out, and let those entries with a larger sec a higher chance of staying in. -------------------------------------------------------------------- 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 Oct 14 06:41:30 2003 Received: from albatross-ext.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 GAA03223 for ; Tue, 14 Oct 2003 06:41:29 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EAYPlN011777; Tue, 14 Oct 2003 12:34:28 +0200 (MEST) 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 45JXGM6J; Tue, 14 Oct 2003 12:37:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9EAYEwg018109; Tue, 14 Oct 2003 12:34:14 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9EAXeB5007649; Tue, 14 Oct 2003 12:33:41 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9EAXefK007648; Tue, 14 Oct 2003 12:33:40 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9EAXeB5007644 for ; Tue, 14 Oct 2003 12:33:40 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id EAD391C for ; Tue, 14 Oct 2003 13:46:54 +0300 (EEST) Message-ID: <3F8BD10B.8070407@ericsson.com> Date: Tue, 14 Oct 2003 13:33:47 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Closing issue 07: Use of certs for ND (not RD) not though out 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 The WG agreed at the Vienna meeting that the usage of certificate chains for ND (as opposed to RD) should be left for future study. At the same time, some people voiced their opinion that such a feature might be very useful, and I think that at least someone even volunteered to write a spec. However, so far we (the chairs) haven't seen any concrete results. Anyway, I have now went through the current working version of the draft, and tried to carefully mark any locations that talk about certificates and ND as for further study. I can't promise that I have caught all such locations, though. Hence, some more reading is probably needed. A snapshot (rough at cert formats) of the draft is available at the following URLs: http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct14.txt http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct14.html http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct14.xml Anyway, I think this issue is now closed. --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 Tue Oct 14 07:10:05 2003 Received: from penguin-ext.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 HAA03691 for ; Tue, 14 Oct 2003 07:10:05 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EAxb42026474; Tue, 14 Oct 2003 12:59:37 +0200 (MEST) 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 43DS0AA0; Tue, 14 Oct 2003 12:59:56 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9EAxTwg019309; Tue, 14 Oct 2003 12:59:29 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9EAx1B5012738; Tue, 14 Oct 2003 12:59:01 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9EAx1b3012737; Tue, 14 Oct 2003 12:59:01 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9EAx0B5012731 for ; Tue, 14 Oct 2003 12:59:00 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 171C81C; Tue, 14 Oct 2003 14:12:15 +0300 (EEST) Message-ID: <3F8BD6FB.2090409@ericsson.com> Date: Tue, 14 Oct 2003 13:59:07 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Dave Thaler Subject: Closing issue 05: Clarifications and inconsistency fixes 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 I have now edited in Dave Thaler's comments as follows: > 1) Section 6 states: > > Similarly, the router, which is already connected to the network, can > > if necessary communicate off-link and construct the certificate > > chain. > > This should be clarified with "in some cases". If the router is > not connected to the Internet, this may not be possible. The new text now reads: In the typical case, a router, which is already connected to beyond the link, can (if necessary) communicate with off-link nodes and construct such a certificate chain. > 2) Sections 6.1 and 6.2 describe an Identifier field, but does not > specify how it is set in a solicitation or in an unsolicited > advertisement. E.g. if it is always set to 1, it doesn't seem > very useful. Likewise, if each host starts with 1 and increments, > it's also less useful since hosts can collide. I think it should > be randomly generated if possible. The new text now reads: A 16-bit unsigned integer field, acting as an identifier to help matching advertisements to solicitations. The Identifier field MUST NOT be zero, and its value SHOULD be randomly generated. (This randomness does not need to be cryptographically hard, though. Its purpose is to avoid collisions.) > 3) Sections 6.3 and 6.4 both specify options with a variable-length > field followed by padding. However, they use two different encodings > for no good reason. One specifies the length of the field, and the > other specifies the length of the padding. Instead, both options > should be consistent. Changed now so that both sections have an explicit pad length. > 4) Section 6.4 says: > > When the Name Type field is set to 1, the Name field contains the > > Fully Qualified Domain Name of the trusted root, for example > > "trustroot.operator.com". > > More guidance is needed to prevent interoperability problems. Is the > string null-terminated (I assume no)? Are internationalized domain > names legal? What is the encoding? (UTF-8? Unicode? ...) The new text now reads: When the Name Type field is set to 1, the Name field contains a Fully Qualified Domain Name of the trusted root, for example, "trustroot.example.com". The name is stored as a string, in the "preferred name syntax" DNS format, as specified in RFC1034 Section 3.5. Additionally, the restrictions discussed in RFC 3280 Section 4.2.1.7 apply. > 5) Section 6.5 says: > > RFC 3281. If the GeneralName attribute is a dNSName, it MUST be > > resolvable to a global unicast address assigned to the router. If > > the GeneralName attribute is an iPAddress, it MUST be a global > > unicast address assigned to the router. For purposes of facilitating > > For people not familiar with X.509, is it easy to explain in 1-2 > sentences what it is used for? (That is, why is it a MUST above?) > As is, it sounds suspiciously like a security hole. This issue has disappeared since we no longer use RFC3281. > 6) Section 6.5.1 says: > > This field MUST contain a list of prefixes that the router is > > authorized to route, or the unspecified prefix if the router > > This wording is particularly problematic. Routers route packets > not prefixes. They _advertise_ prefixes in RA's and in routing protocols. > It's similarly unclear whether the prefix list is what remote > prefixes it's allowed to advertise as off-link routes in RA's (e.g. > ::/0 if it can be a default router on the link), or whether the prefix > list is what local prefixes it's allowed to advertise as on-link routes > in RA's. I'm guessing the latter, but I can think of arguments for > restricting both. This issue has disappeared since we no longer use RFC3281. > > 7) Sections 6.6 and 6.7 appear to contradict each other. > 6.6 says: > > SHOULD send an advertisement without any certificates. In this case > > the router SHOULD include the Trusted Root options which were > > solicited. > > Hence the Trusted Root option is legal in an advertisement. > > 6.7 says: > > packet processed in the normal manner. The only defined option that > > may appear is the Certificate option. An advertisement that passes > > Hence the Trusted Root option is not legal in an advertisement. 6.7 fixed to allow Trusted Root option. > 8) Section 7.1.2 and reference [27] contradict each other. > 7.1.2 says: > > > CGAParameters ::= SEQUENCE { > > publicKey SubjectPublicKeyInfo, > > auxParameters CGAAuxParameters OPTIONAL } > > whereas [27] now has the opposite order. It would be better to not > copy the definition here at all, and just refer to [27] for the > definition. This issue has diappeared since we no longer use ASN.1 here. > 9) Section 7.1.3 talks about a minbits parameter. It doesn't really > say how the value should be determined. Some guidance would be > helpful. The new text now reads: The minimum acceptable key length for the public keys used in the generation of the CGA address. The default SHOULD be 1024 bits. Implementations MAY also set an upper limit in order to limit the amount of computation they need to perform when verifying packets that use these security associations. Any implementation should follow prudent cryptographic practise in determining the appropriate key lengths. I don't think whether it is good to give any reference, since references in this field tend to get obsoleted fairly soon. Unless there are any more comments, I will consider this issue closed. --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 Tue Oct 14 11:53:59 2003 Received: from albatross-ext.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 LAA16249 for ; Tue, 14 Oct 2003 11:53:57 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EFlBlN026591; Tue, 14 Oct 2003 17:47:12 +0200 (MEST) 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 43DTCH7P; Tue, 14 Oct 2003 17:47:32 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9EFlAwg029009; Tue, 14 Oct 2003 17:47:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9EFkMB5019108; Tue, 14 Oct 2003 17:46:22 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9EFkMtW019107; Tue, 14 Oct 2003 17:46:22 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9EFkKB5019091 for ; Tue, 14 Oct 2003 17:46:21 +0200 (MET DST) Message-ID: <00a801c3926a$53110980$956015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" Cc: "Pekka Nikander" , "SEND WG" , "Francis Dupont" References: <3F8A840D.5040102@ericsson.com> <066801c391bb$231b4f10$956015ac@dclkempt40> <3F8B9884.6050201@ericsson.com> Subject: Re: Closing issue 19: Allow autoconfig even with non-CGA addrs e.g. ::1 Date: Tue, 14 Oct 2003 08:46:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Yes, that sounds fine. jak ----- Original Message ----- From: "Pekka Nikander" To: "James Kempf" Cc: "Pekka Nikander" ; "SEND WG" ; "Francis Dupont" Sent: Monday, October 13, 2003 11:32 PM Subject: Re: Closing issue 19: Allow autoconfig even with non-CGA addrs e.g. ::1 > James Kempf wrote: > > > I think there might be an issue with saying that cert-based SEND is FFS and > > then saying that hosts with static addresses SHOULD use it. > > > > Or? > > Jari already noticed this, and provided some alternative text. > I think his suggestion is ok: > > > This specification does not address the protection of Neighbor > > Discovery packets for hosts that are configured with a static address > > (e.g., PREFIX::1). Future certificate chain based authorization > > specifications are needed for such hosts. > > --Pekka > > > -------------------------------------------------------------------- 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 Oct 14 23:19:40 2003 Received: from penguin-ext.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 XAA15322 for ; Tue, 14 Oct 2003 23:19:39 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F3GBSs003025; Wed, 15 Oct 2003 05:16:12 +0200 (MEST) 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 45JQHJDJ; Wed, 15 Oct 2003 05:16:40 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9F3GAXA000943; Wed, 15 Oct 2003 05:16:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F3FOB5006774; Wed, 15 Oct 2003 05:15:24 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9F3FOf7006768; Wed, 15 Oct 2003 05:15:24 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F3FMB5006723 for ; Wed, 15 Oct 2003 05:15:23 +0200 (MET DST) Received: (qmail 12750 invoked from network); 15 Oct 2003 03:15:20 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Oct 2003 03:15:20 -0000 Date: Tue, 14 Oct 2003 20:15:20 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Trusted root names From: Jonathan Wood To: SEND WG Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I'm not sure that using a FQDN (i.e. hostname) to represent a trusted root is a good thing, since intermediate and root authorities might not be hosts. Also, if we want to use FQDNs in SEND in this fasion, won't we need to also mandate a certificate profile that requires the inclusion of DNS alt subj names in each cert? I would rather that we stuck with using the basic subject field in a cert. If we do, we would need some changes in the trusted root option: the name should probably be DER-encoded X501 Name type (which is how it is encoded in a cert), and we would not need the pad length any more, since the DER-encoding would give us that information. Section 6.6 would also need to change references to subjectAltName. Comments? Jonathan -------------------------------------------------------------------- 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 Oct 14 23:27:46 2003 Received: from albatross-ext.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 XAA15435 for ; Tue, 14 Oct 2003 23:27:45 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F3PnI2023823; Wed, 15 Oct 2003 05:25:50 +0200 (MEST) 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 43DN1QT5; Wed, 15 Oct 2003 05:29:40 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9F3Pgwg011880; Wed, 15 Oct 2003 05:25:43 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F3PTB5008924; Wed, 15 Oct 2003 05:25:29 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9F3PTAt008923; Wed, 15 Oct 2003 05:25:29 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F3PRB5008919 for ; Wed, 15 Oct 2003 05:25:27 +0200 (MET DST) Received: (qmail 21319 invoked from network); 15 Oct 2003 03:25:26 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail7.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Oct 2003 03:25:26 -0000 Date: Tue, 14 Oct 2003 20:25:25 -0700 Subject: Re: Closing issues 11 and 22: Nonce and timestamp management Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: SEND WG To: Pekka Nikander From: Jonathan Wood In-Reply-To: <3F8BC982.6010403@ericsson.com> Message-Id: <376069A2-FEBF-11D7-9372-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit This looks good to me - one question, and one minor editorial comment: On Tuesday, October 14, 2003, at 03:01 AM, Pekka Nikander wrote: > <...> > If a message has both Nonce and a Timestamp options, the Nonce > option > MUST precede the Timestamp option in order. Why require ordering? (Also note that RFC 2461 section 9 says "Options in Neighbor Discovery packets can appear in any order; receivers MUST be prepared to process them independantly of their order") > > 5.4.4 Processing rules for receivers > > The processing of the Nonce and Timestamp options depends on whether > a packet is a solicited-for advertisement or not. A system may > implement the distinction in various means. Section 5.4.4.1 defines > the processing rules for solicited-for advertisements. Section > 5.4.4.2 defines the processing rules for all other messages. > > When there is a very large number of hosts on the same link, or when > a cache filling attack is in progress, it is possible that the cache > holding the most recent timestamp per sender becomes full. In this > case the node MUST remove some entries from the cache or refuse some > new requested entries. The specific policy as to which entries are > preferred over the others is left as an implementation decision. > However, typical policies may prefer existing entries over new ones, > CGAs with a large Sec value over smaller Sec values, and so on. The > issue is briefly discussed in Appendix C. [Editorial] This paragraph jumps right into a cache discussion with no context; It may be clearer to start with something like "A implementation may utilize some mechanism such as a timestamp cache to strengthen resistance to replay attacks." Jonathan -------------------------------------------------------------------- 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 Oct 15 02:39:30 2003 Received: from albatross-ext.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 CAA16555 for ; Wed, 15 Oct 2003 02:39:29 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F6ZxI2026312; Wed, 15 Oct 2003 08:36:00 +0200 (MEST) 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 43DT2X7R; Wed, 15 Oct 2003 08:36:22 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9F6ZwXA002333; Wed, 15 Oct 2003 08:35:59 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F6Z8B5025293; Wed, 15 Oct 2003 08:35:08 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9F6Z8vS025292; Wed, 15 Oct 2003 08:35:08 +0200 (MET DST) 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 sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F6Z7B5025288 for ; Wed, 15 Oct 2003 08:35:07 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 3AB741C; Wed, 15 Oct 2003 09:48:22 +0300 (EEST) Message-ID: <3F8CEAA4.9020308@nomadiclab.com> Date: Wed, 15 Oct 2003 09:35:16 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Wood Cc: SEND WG Subject: Re: Trusted root names References: In-Reply-To: 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 Jonathan Wood wrote: > I'm not sure that using a FQDN (i.e. hostname) to represent > a trusted root is a good thing, since intermediate and root > authorities might not be hosts. Also, if we want to use FQDNs > in SEND in this fasion, won't we need to also mandate a > certificate profile that requires the inclusion of DNS alt subj > names in each cert? > > I would rather that we stuck with using the basic subject field > in a cert. If we do, we would need some changes in the trusted > root option: the name should probably be DER-encoded X501 > Name type (which is how it is encoded in a cert), and we > would not need the pad length any more, since the DER-encoding > would give us that information. Section 6.6 would also need > to change references to subjectAltName. > > Comments? We discussed this issue at the DT for some length, but I don't remember any more all of the details. In any case, I would have liked to use a hash of the root public key to represent the root, but that was not considered as a good choice since it would be fairly hard to use such a hash as a search key. I think it was mostly James who prefererred the FQDN, and if I remember right, the main reason was the ease of using it as a search key. That is, if we use the FQDN to represent the root, we can use either LDAP or DNS to store the keys and to retrieve them. Anyway, for me it is OK to define a new type of the name field, as an alternativity to the FQDN, both being equally acceptable (and both being mandatory to implement). Here is the suggestion: When the Name Type field is set to 2, the Name field contains a DER encoded X.501 certificate Name, represented and encoded exactly as in the matching X.509v3 root certificate. What comes to Section 6.6, you are right. It needs to be revised so that the FQDN is not really mentioned, but the text should be more generic. Here is my suggestion, presuming that we define a DER encoded subject format. Old text: In a solicited-for advertisement, the router SHOULD include suitable Certificate options so that a delegation chain to the solicited root can be established. The root is identified by the FQDN from the Trusted Root option being equal to an FQDN in the subjectAltName field of the root's certificate. The router SHOULD include the Trusted Root option(s) in the advertisement for which the delegation chain was found. New text: In a solicited-for advertisement, the router SHOULD include suitable Certificate options so that a delegation chain to the solicited root can be established. The root is identified by the Trusted Root option. If the Trusted Root option is represented as an FQDN, the FQDN must be equal to an FQDN in the subjectAltName field of the root's certificate. If the Trusted Root option is represented as a DER Encoded X.501 Name, then the Name must be equal to the Subject field in the root's certificate. The router SHOULD include the Trusted Root option(s) in the advertisement for which the delegation chain was found. Ok? --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 Oct 15 02:58:13 2003 Received: from albatross-ext.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 CAA17399 for ; Wed, 15 Oct 2003 02:58:12 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F6uaI2003112; Wed, 15 Oct 2003 08:56:36 +0200 (MEST) 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 45JXR3BB; Wed, 15 Oct 2003 09:00:06 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9F6uRwg015198; Wed, 15 Oct 2003 08:56:27 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F6txB5029676; Wed, 15 Oct 2003 08:55:59 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9F6txQT029675; Wed, 15 Oct 2003 08:55:59 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F6twB5029659 for ; Wed, 15 Oct 2003 08:55:58 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 705F01C; Wed, 15 Oct 2003 10:09:13 +0300 (EEST) Message-ID: <3F8CEF87.2090409@ericsson.com> Date: Wed, 15 Oct 2003 09:56:07 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Wood Cc: SEND WG Subject: Re: Closing issues 11 and 22: Nonce and timestamp management References: <376069A2-FEBF-11D7-9372-0003930D291E@speakeasy.net> In-Reply-To: <376069A2-FEBF-11D7-9372-0003930D291E@speakeasy.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 Jonathan Wood wrote: >> If a message has both Nonce and a Timestamp options, the Nonce option >> MUST precede the Timestamp option in order. > > Why require ordering? (Also note that RFC 2461 section 9 says > "Options in Neighbor Discovery packets can appear in any order; > receivers MUST be prepared to process them independantly of > their order") Well, having the Nonce before the Timestamp would make processing at the receiving end easier. But if RFC 2461 says otherwise (I was unaware of the clause), then apparently we shouldn't mandate. I changed the text to read as follows: If a message has both Nonce and Timestamp options, the Nonce option SHOULD precede the Timestamp option in order. The receiver MUST be prepared to receive them in any order, as per RFC 2461 Section 9. Better? >> 5.4.4 Processing rules for receivers >> ... >> >> When there is a very large number of hosts on the same link, or when >> a cache filling attack is in progress, it is possible that the cache .... > > > [Editorial] > This paragraph jumps right into a cache discussion with no context; > It may be clearer to start with something like "A implementation may > utilize > some mechanism such as a timestamp cache to strengthen resistance to > replay attacks." Thanks, I added your suggested sentence (with s/^A/An/) --Pekka -------------------------------------------------------------------- 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 Oct 15 05:06:01 2003 Received: from penguin-ext.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 FAA21319 for ; Wed, 15 Oct 2003 05:06:00 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F93rSs023858; Wed, 15 Oct 2003 11:03:53 +0200 (MEST) 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 45JXTACK; Wed, 15 Oct 2003 11:07:24 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9F93qXA004861; Wed, 15 Oct 2003 11:03:52 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F93GB5029221; Wed, 15 Oct 2003 11:03:16 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9F93Gus029216; Wed, 15 Oct 2003 11:03:16 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F93FB5029204 for ; Wed, 15 Oct 2003 11:03:15 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 1A1831C; Wed, 15 Oct 2003 12:16:30 +0300 (EEST) Message-ID: <3F8D0D5C.5020904@ericsson.com> Date: Wed, 15 Oct 2003 12:03:24 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Dave Thaler Subject: Closing issue 04: Editorial issues in draft-send-ipsec-01.txt 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 I have now edited the editorial corrections, where applicable, as proposed by Dave Thaler. Thanks Dave! The resulting snapshot of the draft is available at the following URLs: http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct15.txt http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct15.html http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct15.xml Note that I may update the draft again today, and therefore the contents of the URLs may be slightly different depending on what time of day you access them. OTOH, my TZ is GMT+2, and I won't work throught the night :-) I consider this issue closed. However, that doesn't mean that the draft doesn't contain typos or grammatical mistakes :-( --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 Oct 15 05:08:48 2003 Received: from albatross-ext.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 FAA21376 for ; Wed, 15 Oct 2003 05:08:48 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F978I2024271; Wed, 15 Oct 2003 11:07:08 +0200 (MEST) 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 45JXTB4J; Wed, 15 Oct 2003 11:10:39 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9F977XA004906; Wed, 15 Oct 2003 11:07:07 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F96xB5029861; Wed, 15 Oct 2003 11:06:59 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9F96xJj029860; Wed, 15 Oct 2003 11:06:59 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F96wB5029856 for ; Wed, 15 Oct 2003 11:06:58 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 936ED1C for ; Wed, 15 Oct 2003 12:20:13 +0300 (EEST) Message-ID: <3F8D0E3B.3080100@ericsson.com> Date: Wed, 15 Oct 2003 12:07:07 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Closing issue 26: Timestamp management 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 Issue 26 concerned timestamp and cache management: > Jonathan Wood: I'd like to get some clarification on timestamp > management - what is going into the next draft? > > One thing which has not been clear to me thus far is what to do when > the cache becomes full - how should we decide which entries to > throw out? We need a strategy that does not allow an attacker to > flush a timestamp cache with bogus entries as a prelude to performing > a replay attack. As per the below message by Jon, I think this issue will be closed as soon as we get issues 11 / 22 completely closed. > Date: Tue, 14 Oct 2003 20:25:25 -0700 > Subject: Re: Closing issues 11 and 22: Nonce and timestamp management > Cc: SEND WG > To: Pekka Nikander > From: Jonathan Wood > Message-Id: <376069A2-FEBF-11D7-9372-0003930D291E@speakeasy.net> > > This looks good to me - one question, and one minor editorial > comment: --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 Oct 15 05:45:14 2003 Received: from penguin-ext.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 FAA22378 for ; Wed, 15 Oct 2003 05:45:12 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F9gSSs008046; Wed, 15 Oct 2003 11:42:28 +0200 (MEST) 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 45JQKCC1; Wed, 15 Oct 2003 11:42:58 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9F9gOwg021861; Wed, 15 Oct 2003 11:42:24 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F9fqB5007574; Wed, 15 Oct 2003 11:41:52 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9F9fqtq007573; Wed, 15 Oct 2003 11:41:52 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9F9fpB5007569 for ; Wed, 15 Oct 2003 11:41:51 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 22A7C1C; Wed, 15 Oct 2003 12:55:06 +0300 (EEST) Message-ID: <3F8D1668.7000104@ericsson.com> Date: Wed, 15 Oct 2003 12:42:00 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chirayu Patel Cc: ietf-send@standards.ericsson.net Subject: Re: Comments on draft-ietf-send-psreq-03 References: <20031006044252.B4C4074B7D@smtp.us2.messagingengine.com> In-Reply-To: <20031006044252.B4C4074B7D@smtp.us2.messagingengine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id h9F9gOwg021861 Content-Transfer-Encoding: quoted-printable Dear Chirayu, Thanks a lot for your comments, and sorry for not answering earlier. Our only excuse is that there is a procedural problem with your comments, and we have requested advice from the ADs. We are still waiting for the reply. The problem is that the psreq draft has already passed the IESG review, I have already resolved the minor issues that they had, and now the draft is waiting for their acceptanse on the resolutions. In other words, the draft is fairly long on its way to become an RFC. Based on the that status, and the fact that the draft does not specify a protocol but is only informational, we are inclided to reject your editorial suggestion #5 as a too large one. While it might be good, its doesn't warrant the required new review. What comes to the other editorial comments, let me take them one by one: > 6. Abstract. Rephrase the last sentence to "The output forms a clear > problem statement and a set of requirements for Securing IPv6 > Neighbor Discovery." The last sentence has already been changed, as per IESG request. > 7. Section 4.2.5, 3rd paragraph. > > s/finite system/system with finite resources/ IMHO the concept of "finite system" is well enough defined. As an informal indication, google finds about 8500 uses of it. > 8. Section 4.2.6. 5th paragraph. > > s/target link will get all replies/target link may get replies/ I changed this to read "target link may get a large number of replies". Thanks for catching this. Going to the technical comments: > 1. Threats for a L2-switch, and ND-proxies. L2-switches, and ND- proxi= es > build their neighbor cache by snooping the source IPv6 address, and > the corresponding link-layer address. It is possible to send fake > NS/NA/RA/RD/redirect/Data (any packet which is used to build the > neighbor cache), and do a redirect/DOS attack. >=20 > I think section 4 should list a threat concerning such devices. While your intention is good, I think that any such work should be left for future. There has been some discussion about these kinds of use scenarios before. However, only maybe a couple of people have shown real interest on working on those problems, and so far we have seen no real, concrete input. If you are interested, maybe you could write a new -00 draft, and submit it as an individual draft. If there is interest in continuing the SEND work once the current work has been completed, such input would be very valuable. In any case, if the draft is high quality, it may be interesting enough to be published as an Information RFC even without a working group. Currently our plan is to close the SEND WG as soon as the current wg items are completed. > 2. Flood DoS is described in section 4, but none of the attack is list= ed > as "Flood DoS". I haven=92t evaluated the attacks for this one, but= a > quick scan shows that 4.1.1 qualifies as Flood DoS. The structuring of the introduction in Section 4 and the rest of section 4 is different. We have not really made a difference between flooding DoS and other types of DoS in the rest of section 4. Maybe we should have such distinction, but at least I am not willing to do it at this stage any more. Sorry. > 3. Section 4.2.1. > a. What is the "entering node"? Well, a node attempting to discover a router is most probably a new node entering to the link. I readily admit that the text is not very clear. If you could propose how to revise the text, that would be great. > b. I might be a bit confused - isn=92t the section referring to = the > first-hop router? Can you also give the reference number to a > section number in RFC2461 talks of this threat? The text has been inherited a few times. I would need to read RFC2461 carefully in order to find out which section it is. But, yes, it would be good to add a reference to the specific section. Does anybody else remember right away? > c. The 3rd paragraph talks of RFC 2461, and 2462. Is there a > conflict between these two documents? I am not able to > understand why the default router selection procedure in > section 6.3.6 needs a rule that concerns with the lifetime of > the router. I am not really an expert on the differences between 2461 and 2462. Could somebody else provide an answer? If good enough, I can add it to the draft (if the IESG approves, of course). > 4. Mention the type of attack in section 4.2.2. Good catch. It is mostly a DoS attack, but could also be used to redirect (to the next better router). Added. A pre-release of the updated draft, with the resolutions to the IESG issues and your concerns, is available at http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.txt http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.html http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.xml The changes are highlighted in http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15-diff.h= tml http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15-chbar.= txt --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 Oct 15 06:47:22 2003 Received: from penguin-ext.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 GAA24128 for ; Wed, 15 Oct 2003 06:47:21 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FAjISs026944; Wed, 15 Oct 2003 12:45:18 +0200 (MEST) 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 45JQKV50; Wed, 15 Oct 2003 12:45:47 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9FAjBwg028776; Wed, 15 Oct 2003 12:45:11 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FAiLB5021560; Wed, 15 Oct 2003 12:44:21 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9FAiKrB021559; Wed, 15 Oct 2003 12:44:20 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FAiJB5021552 for ; Wed, 15 Oct 2003 12:44:19 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 73A651C; Wed, 15 Oct 2003 13:57:34 +0300 (EEST) Message-ID: <3F8D250C.7060108@ericsson.com> Date: Wed, 15 Oct 2003 13:44:28 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Francis Dupont Subject: Proceeding issue 20: Francis Dupont's certificate issues 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 I believe that I have now resolved the majority of the certificate issues, as discussed on the list on issue #20. I still need to check that this covers all comments on issue #08, but I'll do that later. The new certificate text reads as follows: ------------------------------------------------- 6.5 Router Authorization Certificate Format The certificate chain of a router terminates in a Router Authorization Certificate that authorizes a specific IPv6 node to act as a router. Because authorization chains are not a common practice in the Internet at the time this specification is being written, the chain MUST consist of standard Public Key Certificates (PKC, in the sense of [22]). The certificates chain MUST start from the identity of a trusted root that is shared by the host and the router. This allows the host to anchor trust for the router's public key in the trusted root. Note that there MAY be multiple certificates issued by a single trusted root. 6.5.1 Router Authorization Certificate Profile Router Authorization Certificates MUST contain the X.509 extension for IP addresses, as defined in [13]. The parent certificates in the certificate chain MUST contain one or more X.509 IP address extensions, back up to the delegating authority (the Regional Address Registry or IANA) that delegated the original IP address space block. The certificates for intermediate delegating authorities MUST contain X.509 IP address extension(s) for subdelegations. The router's certificate is signed by the delegating authority for the prefixes the router is authorized to to advertize. The X.509 IP address extension MUST contain at least one addressesOrRanges element that contains an addressPrefix element with an IPv6 address prefix for a prefix the router or the intermediate entity is authorized to advertize. If the entity is allowed to route any prefix, the used IPv6 address prefix is the null prefix, 0/0. The addressFamily element of the containing IPAddrBlocks sequence element MUST contain the IPv6 AFI (0002), as specified in [13] for IPv6 prefixes. Instead of an addressPrefix element, the addressesOrRange element MAY contain an addressRange element for a range of prefixes, if more than one prefix is authorized. The X.509 IP address extension MAY contain additional IPv6 prefixes, expressed either as an addressPrefix or an addressRange. A SEND node receiving a Router Authorization Certificate MUST first check whether the certificate's signature was generated by the delegating authority. Then the client MUST check whether all the addressPrefix or addressRange entries in the router's certificate are contained within the address ranges in the delegating authority's certificate, and whether the addressPrefix entries match any addressPrefix entries in the delegating authority's certificate. If an addressPrefix or addressRange is not contained within the delegating authority's prefixes or ranges, the client MAY attept to take an intersection of the ranges/prefixes, and use that intersection. If the addressPrefix in the certificate is the null prefix, 0/0, such an intersection SHOULD be used. (In that case the intersection is the parent prefix or range.) If the resulting intersection is empty, the client MUST NOT accept the certificate. The above check SHOULD be done for all certificates in the chain received through DCA messages. If any of the checks fail, the client MUST NOT accept the certificate. Since it is possible that some PKC certificates used with SEND do not immediately contain the X.509 IP address extension element, an implementation MAY contain facilities that allow the prefix and range checks to be relaxed. However, any such configuration options SHOULD be off by default. That is, the system SHOULD have a default configuration that requires rigorious prefix and range checks. ---------------------------------------------------- Comments? Considering the minor points, I have resolved them as follows: > Francis Dupont writes and Jari Arkko responds: > >> - 6.3 Trusted Root Option (comment) >> >> => you don't support two root certificates for the same root... >> I propose to add a name type where one can put a hash of the >> certificate. For the hash itself the objectDigest seems perfect. > > Sounds good. Pekka? The text has now been clarified that a host may be configured with several trusted root, and that there may be several certificates issued by a trusted root. The idea of using hashes to identify trusted roots were not adopted. >> BTW I don't understand why we should not put PKIX certificates? >> IKEv2 does this, and it can make interoperability between implementations >> less problematic. > > There's a pending discussion about the exact certificate types > used. The new text indeed uses PKC certificates, with the IP address extension. >> - 6.5 Router Authorization Certificate Format (comment) >> >> MUST consist of standard Public Key Certificates (PKC, in the sense >> of [11]) for identity from the trusted root shared with the host to >> >> => [11] (PKIX) doesn't use this term... IMHO the right reference is [12] >> and the introduction text of [12] about PKC and AC should be copied! > > Sounds right. Pekka? Used RFC3281 as the reference. Moved RFC3281 is now an informational reference instead of normative. >> - same (comment) >> >> acinfo.attributes >> >> This field MUST contain a list of prefixes that the router is >> authorized to route >> >> => I disagree: a router is not authorized to route a prefix, it is >> authorized to advertise/annonce a prefix. About routing perhaps >> it should be useful to authorize (or not) a router to be a default >> router? > > Right. This has been covered under issue #5. Changed all text to read that a router/entity is authorized to advertize a prefix, not to route it. >> - same (comment) >> >> If the router is authorized only to route specific prefixes, the >> ipAddress values consist of IPv6 addresses in standard RFC 3513 >> [13] prefix format. >> >> => my problem is that ipAddress can't encode prefix in RFC 3513 format >> (i.e., ipAddress can get a mask but not
/). >> Please clarify, for instance with an example. RFC 3280 one is: >> For example, a name >> constraint for "class C" subnet 10.9.8.0 is represented as the octets >> 0A 09 08 00 FF FF FF 00, representing the CIDR notation >> 10.9.8.0/255.255.255.0. > > Ok. This comment does not apply any more as we have changed the certificate format. >> PS: I can't find how to verify certified addresses, even for routers. >> (this is not in 9.2) > > Indeed this is missing! I removed the remaining text that discussed certifying router's addresses. --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 Oct 15 08:11:49 2003 Received: from albatross-ext.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 IAA26453 for ; Wed, 15 Oct 2003 08:11:48 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FC9ZI2029332; Wed, 15 Oct 2003 14:09:35 +0200 (MEST) 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 45JQLPC1; Wed, 15 Oct 2003 14:10:05 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9FC9YXA015960; Wed, 15 Oct 2003 14:09:34 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FC8pB5011467; Wed, 15 Oct 2003 14:08:51 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9FC8pKt011466; Wed, 15 Oct 2003 14:08:51 +0200 (MET DST) 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 sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FC8oB5011460 for ; Wed, 15 Oct 2003 14:08:50 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 09DBF1C; Wed, 15 Oct 2003 15:22:05 +0300 (EEST) Message-ID: <3F8D38DB.5080702@ericsson.com> Date: Wed, 15 Oct 2003 15:08:59 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: pasi.eronen@nokia.com, valtteri.niemi@nokia.com, James Kempf Subject: Closing issue 08: Certificate details review by Pasi and Valtteri 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 I have now processed the subissues in issue #08, and acted mostly as James suggested in his message on Sep 15th. Some specific comments: > Issue 8a: > "The certificate transport is relatively straight-forward, but the > description of certificate chains could benefit from some clarifications and > examples showing at least one valid certificate chain." > > Suggested resolution: > Since jak has been primarily been handling certificates, he will try to come > up with an example. So far I haven't received any examples. James, could you produce one today? I need to have the example by Friday morning my time to get it included. If not possible, I guess we need to leave addition of any such examples for the -01 version of the draft. > Issue 8d: > "o Section 6.3 (editorial): In PKIX-speak, the correct term would probably > be 'trust anchor', not 'trusted root'." > > Suggested resolution: Jari has said in an initial followup email that he > will make the change. I performed a global replace for this, even renaming the Trusted Root option as Trust Anchor option. The document doesn't contain the word "root" any more. > Issue 8e: > "o Sections 6.3 and 6.6 (technical): Presumably, the 'trusted root' should > contain the issuer of the first certificate in the chain But for X.509 > certs, that's a Distinguished Name, not FQDN. So should the "trusted root" > option contain a DER-encoded Issuer DN instead of FQDN? > > Using AltSubjectName (correct spelling is subjectAltName, BTW) seems to make > it more difficult for the router to decide which certificate to send, since > its own certificate doesn't necessarily have the CA's dNSName (though it may > be included in issuerAltName extension). ... > Suggested resolution: These issues are superceded by use of > draft-ietf-pkix-x509-as-extn. Actually the trust anchor name issue is not superceded. The document now allows both FQDM and DER-encoded X.509 Name, as requested by Jon Wood yesterday. Unless there are any more comments, I will consider this issue to close together with issue #20. --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 Oct 15 08:25:02 2003 Received: from albatross-ext.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 IAA26844 for ; Wed, 15 Oct 2003 08:25:01 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FCNJI2003832; Wed, 15 Oct 2003 14:23:23 +0200 (MEST) 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 43DTMR04; Wed, 15 Oct 2003 14:23:37 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9FCNDXA016419; Wed, 15 Oct 2003 14:23:13 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FCMmB5014690; Wed, 15 Oct 2003 14:22:48 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9FCMm21014687; Wed, 15 Oct 2003 14:22:48 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FCMlB5014680 for ; Wed, 15 Oct 2003 14:22:47 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 41F3B1C; Wed, 15 Oct 2003 15:36:02 +0300 (EEST) Message-ID: <3F8D3C20.1000908@ericsson.com> Date: Wed, 15 Oct 2003 15:22:56 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Francis Dupont , valtteri.niemi@nokia.com, pasi.eronen@nokia.com, Jari Arkko , James Kempf Subject: Issue status and Remaining issues: 17 and 13 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 According to my best understanding, I have now processed all issues on the SEND protocol draft, with the exception of issues 17 and 13. Additionally, issues #05, #07, #20 (+08) and the issue on trust anchor names may still require modifications. I really need some help with issue #13. As it reads now, it doesn't make any sense to me. Maybe the subissues have already been resolved with other changes to the draft, maybe not. However, I cannot tell. The details of the issue are available at http://www.arkko.com/publications/send/issues/issue13.txt Pasi and/or Valtteri, could you please review the current pre-release of the new draft, at the following URLs, to see if you concerns still apply? http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct15.txt http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct15.html http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct15.xml Issue #17, Different functions of Redirect, seems to require some serious cycles to solve. I don't have those cycles now. Due to my personal scheduling reasons, I have to submit the draft on Friday morning local time. Hence, I am afraid that this issue will remain open in the -00 version of the ndopts draft, unless someone comes up with text that can be just plugged in to the current draft snapshot. The details of issue #17 are available at http://www.arkko.com/publications/send/issues/issue17.txt --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 Oct 15 13:15:02 2003 Received: from albatross-ext.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 NAA10893 for ; Wed, 15 Oct 2003 13:15:01 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FHCJI2004407; Wed, 15 Oct 2003 19:12:19 +0200 (MEST) 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 43DNLF8S; Wed, 15 Oct 2003 19:16:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9FHCCwg010514; Wed, 15 Oct 2003 19:12:12 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FHBZB5020300; Wed, 15 Oct 2003 19:11:35 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9FHBZdE020298; Wed, 15 Oct 2003 19:11:35 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FHBXB5020280 for ; Wed, 15 Oct 2003 19:11:34 +0200 (MET DST) Message-ID: <021901c3933f$693109b0$956015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" Cc: , References: <3F8D38DB.5080702@ericsson.com> Subject: Re: Closing issue 08: Certificate details review by Pasi and Valtteri Date: Wed, 15 Oct 2003 10:11:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > So far I haven't received any examples. James, could you produce > one today? I need to have the example by Friday morning my time > to get it included. If not possible, I guess we need to leave > addition of any such examples for the -01 version of the draft. > Won't have time today. Sorry. We will need to wait for the 01 draft. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Oct 15 13:28:18 2003 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11856 for ; Wed, 15 Oct 2003 13:28:16 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FHP3oq032149; Wed, 15 Oct 2003 19:25:04 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JQ315T; Wed, 15 Oct 2003 19:25:34 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9FHOvwg010767; Wed, 15 Oct 2003 19:24:57 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FHOVB5023280; Wed, 15 Oct 2003 19:24:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9FHOVEd023279; Wed, 15 Oct 2003 19:24:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FHOTB5023274 for ; Wed, 15 Oct 2003 19:24:30 +0200 (MET DST) Message-ID: <022501c39341$274e5c30$956015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "Jonathan Wood" Cc: "SEND WG" References: <3F8CEAA4.9020308@nomadiclab.com> Subject: Re: Trusted root names Date: Wed, 15 Oct 2003 10:24:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, I don't have any problem with using a DN for this. From talking with some people about it, it seems as if a DN is used for SSL as well, so this seems to be standard practice. Also, from a simplicity standpoint, I think it makes sense to minimize the diffs between this and the PKIX IP Address extension, to avoid implementation and deployment complexity. As for obtaining a key in the DNS, I recall we did discuss this in the DT, but given the current design, I am not sure whether there is any benefit in adding an additional field to the certificate for that purpose if it requires the network operator to modify how they would utilize the standard PKIX router certs. The assumed use case here is that the host has the cert chain for the trusted root preloaded rather than opportunistically being able to get the key from the DNS. I think this use case is likely for the near future. So, I'd suggest that rather than having both the DN and FQDN be required to implement, the former be required and the latter be optional. This would simplify the most likely current deployment base design. When SEND goes from PS to DS, the design can be re-examined based on deployment experience. How does that sound? jak ----- Original Message ----- From: "Pekka Nikander" To: "Jonathan Wood" Cc: "SEND WG" Sent: Tuesday, October 14, 2003 11:35 PM Subject: Re: Trusted root names > Jonathan Wood wrote: > > I'm not sure that using a FQDN (i.e. hostname) to represent > > a trusted root is a good thing, since intermediate and root > > authorities might not be hosts. Also, if we want to use FQDNs > > in SEND in this fasion, won't we need to also mandate a > > certificate profile that requires the inclusion of DNS alt subj > > names in each cert? > > > > I would rather that we stuck with using the basic subject field > > in a cert. If we do, we would need some changes in the trusted > > root option: the name should probably be DER-encoded X501 > > Name type (which is how it is encoded in a cert), and we > > would not need the pad length any more, since the DER-encoding > > would give us that information. Section 6.6 would also need > > to change references to subjectAltName. > > > > Comments? > > We discussed this issue at the DT for some length, but I don't > remember any more all of the details. In any case, I would > have liked to use a hash of the root public key to represent > the root, but that was not considered as a good choice since > it would be fairly hard to use such a hash as a search key. > > I think it was mostly James who prefererred the FQDN, and > if I remember right, the main reason was the ease of using > it as a search key. That is, if we use the FQDN to represent > the root, we can use either LDAP or DNS to store the keys > and to retrieve them. > > Anyway, for me it is OK to define a new type of the name > field, as an alternativity to the FQDN, both being equally > acceptable (and both being mandatory to implement). > Here is the suggestion: > > When the Name Type field is set to 2, the Name field > contains a DER encoded X.501 certificate Name, represented > and encoded exactly as in the matching X.509v3 root > certificate. > > What comes to Section 6.6, you are right. It needs to be > revised so that the FQDN is not really mentioned, but the > text should be more generic. Here is my suggestion, > presuming that we define a DER encoded subject format. > > Old text: > > In a solicited-for advertisement, the router SHOULD include > suitable Certificate options so that a delegation chain to the > solicited root can be established. The root is identified by > the FQDN from the Trusted Root option being equal to an FQDN > in the subjectAltName field of the root's certificate. The > router SHOULD include the Trusted Root option(s) in the > advertisement for which the delegation chain was found. > > New text: > > In a solicited-for advertisement, the router SHOULD include > suitable Certificate options so that a delegation chain to the > solicited root can be established. The root is identified by > the Trusted Root option. If the Trusted Root option is > represented as an FQDN, the FQDN must be equal to an FQDN in > the subjectAltName field of the root's certificate. If the > Trusted Root option is represented as a DER Encoded X.501 > Name, then the Name must be equal to the Subject field in the > root's certificate. The router SHOULD include the Trusted > Root option(s) in the advertisement for which the delegation > chain was found. > > Ok? > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Oct 15 14:43:26 2003 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15440 for ; Wed, 15 Oct 2003 14:43:25 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FIftoq007111; Wed, 15 Oct 2003 20:41:55 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JXZQGK; Wed, 15 Oct 2003 20:45:25 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9FIfmwg014508; Wed, 15 Oct 2003 20:41:48 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FIdiB5010921; Wed, 15 Oct 2003 20:39:44 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9FIdiOD010920; Wed, 15 Oct 2003 20:39:44 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FIdgB5010916 for ; Wed, 15 Oct 2003 20:39:43 +0200 (MET DST) Received: (qmail 7622 invoked from network); 15 Oct 2003 18:39:40 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Oct 2003 18:39:40 -0000 Date: Wed, 15 Oct 2003 11:39:40 -0700 Subject: Re: Trusted root names Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: SEND WG To: Pekka Nikander From: Jonathan Wood In-Reply-To: <3F8CEAA4.9020308@nomadiclab.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, October 14, 2003, at 11:35 PM, Pekka Nikander wrote: > <...> > New text: > > In a solicited-for advertisement, the router SHOULD include > suitable Certificate options so that a delegation chain to the > solicited root can be established. The root is identified by > the Trusted Root option. If the Trusted Root option is > represented as an FQDN, the FQDN must be equal to an FQDN in > the subjectAltName field of the root's certificate. If the > Trusted Root option is represented as a DER Encoded X.501 > Name, then the Name must be equal to the Subject field in the > root's certificate. The router SHOULD include the Trusted > Root option(s) in the advertisement for which the delegation > chain was found. > > Ok? > This is better. However I'm now concerned that this may cause interop issues, in that unless the rest of the PKI infrastructure is set up to handle each case, nodes may not be able to find delegation chains. For example, if a node sends a DCS with a DNS name trust anchor option, and either the PKI supports only lookups by DNs or the trust anchor certificate doesn't have a DNS alt name extension, then no routers will be able to provide a DC for the requested trust anchor (even though one might exist if indexed by the DN). I guess my discomfort with the DNS alt name stems primarily from my concern that DNS alt names may not always be there in certs and lookup tables, whereas I feel it more likely that DNs will be there. However, I am no PKI expert, so I will happily yield to a counter argument based on more solid information :) Jonathan -------------------------------------------------------------------- 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 Oct 15 14:56:12 2003 Received: from albatross-ext.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 OAA15730 for ; Wed, 15 Oct 2003 14:56:09 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FIs1I2016549; Wed, 15 Oct 2003 20:54:01 +0200 (MEST) 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 45JXZ446; Wed, 15 Oct 2003 20:57:33 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9FIrvwg015248; Wed, 15 Oct 2003 20:53:57 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FIqBB5013915; Wed, 15 Oct 2003 20:52:11 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9FIqAvC013914; Wed, 15 Oct 2003 20:52:10 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FIq8B5013898 for ; Wed, 15 Oct 2003 20:52:09 +0200 (MET DST) Received: (qmail 13904 invoked from network); 15 Oct 2003 18:52:08 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Oct 2003 18:52:08 -0000 Date: Wed, 15 Oct 2003 11:52:07 -0700 Subject: Re: Closing issues 11 and 22: Nonce and timestamp management Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: SEND WG To: Pekka Nikander From: Jonathan Wood In-Reply-To: <3F8CEF87.2090409@ericsson.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Looks good. On Tuesday, October 14, 2003, at 11:56 PM, Pekka Nikander wrote: > Jonathan Wood wrote: >>> If a message has both Nonce and a Timestamp options, the Nonce >>> option >>> MUST precede the Timestamp option in order. >> Why require ordering? (Also note that RFC 2461 section 9 says >> "Options in Neighbor Discovery packets can appear in any order; >> receivers MUST be prepared to process them independantly of >> their order") > > Well, having the Nonce before the Timestamp would make processing > at the receiving end easier. But if RFC 2461 says otherwise > (I was unaware of the clause), then apparently we shouldn't > mandate. I changed the text to read as follows: > > If a message has both Nonce and Timestamp options, the > Nonce option SHOULD precede the Timestamp option in order. > The receiver MUST be prepared to receive them in any order, > as per RFC 2461 Section 9. > > Better? > >>> 5.4.4 Processing rules for receivers >>> > ... >>> >>> When there is a very large number of hosts on the same link, or >>> when >>> a cache filling attack is in progress, it is possible that the >>> cache > .... >> [Editorial] >> This paragraph jumps right into a cache discussion with no context; >> It may be clearer to start with something like "A implementation may >> utilize >> some mechanism such as a timestamp cache to strengthen resistance to >> replay attacks." > > Thanks, I added your suggested sentence (with s/^A/An/) > > --Pekka > > -------------------------------------------------------------------- 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 Oct 15 19:11:36 2003 Received: from albatross-ext.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 TAA29214 for ; Wed, 15 Oct 2003 19:11:35 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FN6oI2014711; Thu, 16 Oct 2003 01:06:54 +0200 (MEST) 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 43DTSXJB; Thu, 16 Oct 2003 01:07:15 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9FN6nXA024517; Thu, 16 Oct 2003 01:06:49 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FN4oB5013052; Thu, 16 Oct 2003 01:04:50 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9FN4o0k013051; Thu, 16 Oct 2003 01:04:50 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9FN4mB5013047 for ; Thu, 16 Oct 2003 01:04:48 +0200 (MET DST) Message-ID: <037e01c39370$b5df0ce0$956015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "Jonathan Wood" Cc: "SEND WG" References: Subject: Re: Trusted root names Date: Wed, 15 Oct 2003 16:04:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jon, > > > New text: > > > > In a solicited-for advertisement, the router SHOULD include > > suitable Certificate options so that a delegation chain to the > > solicited root can be established. The root is identified by > > the Trusted Root option. If the Trusted Root option is > > represented as an FQDN, the FQDN must be equal to an FQDN in > > the subjectAltName field of the root's certificate. If the > > Trusted Root option is represented as a DER Encoded X.501 > > Name, then the Name must be equal to the Subject field in the > > root's certificate. The router SHOULD include the Trusted > > Root option(s) in the advertisement for which the delegation > > chain was found. > > > > Ok? > > > > This is better. However I'm now concerned that this may cause > interop issues, in that unless the rest of the PKI infrastructure > is set up to handle each case, nodes may not be able to find > delegation chains. For example, if a node sends a DCS with > a DNS name trust anchor option, and either the PKI supports > only lookups by DNs or the trust anchor certificate doesn't have > a DNS alt name extension, then no routers will be able to > provide a DC for the requested trust anchor (even though one > might exist if indexed by the DN). > > I guess my discomfort with the DNS alt name stems primarily > from my concern that DNS alt names may not always be there in > certs and lookup tables, whereas I feel it more likely that DNs will > be there. However, I am no PKI expert, so I will happily yield > to a counter argument based on more solid information :) > Well, I suppose I agree on this. Even having the DNS alt name in as an option has the potential to lead to additional implementation and deployment complexity. Keeping SEND simple is more likely to cause people to want to implement it (a viewpoint from Randy Bush that I am beginning to appreciate). Perhaps the best course, for now, would be to simply require the DN and leave any mention of the DNS alt name out. If DNS keys become widely deployed, the spec can be revised at that time to include it as an alternative. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Oct 15 22:06:00 2003 Received: from albatross-ext.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 WAA03161 for ; Wed, 15 Oct 2003 22:05:59 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9G23hI2002254; Thu, 16 Oct 2003 04:03:44 +0200 (MEST) 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 45JX8QLQ; Thu, 16 Oct 2003 04:07:17 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9G23gXA025721; Thu, 16 Oct 2003 04:03:42 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9G21YB5023637; Thu, 16 Oct 2003 04:01:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9G21Y3d023635; Thu, 16 Oct 2003 04:01:34 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9G21WB5023631 for ; Thu, 16 Oct 2003 04:01:32 +0200 (MET DST) Received: (qmail 29617 invoked from network); 16 Oct 2003 02:01:30 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail7.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Oct 2003 02:01:30 -0000 Date: Wed, 15 Oct 2003 19:01:28 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: DCS and DCA semantics From: Jonathan Wood To: SEND WG Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Sections 6.6 and 6.7 discuss how DCS and DCA should be sent and processed. Much of this is based on RD semantics from RFC 2461. However, DCS and DCA semantics are different from RD, so in many cases I don't think this is appropriate. Specifically: Section 6.7 says When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Delegation Chain Advertisement. To obtain such advertisements quickly, a host MAY transmit up to MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation Chain Solicitations MAY be sent after any of the following events: o The interface is initialized at system startup time. o The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. o The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management. o The host attaches to a link for the first time. o A movement has been indicated by lower layers or has been inferred from changed information in a Router Advertisement. o The host re-attaches to a link after being detached for some time. o A Router Advertisement has been received with a public key that is not stored in the hosts' cache of certificates, or there is no authorization delegation chain to the host's trust anchor. All these will happen naturally as a consequence of a RS/RA exchange, if the host cannot form a delegation chain for the RA. So I think the text quoted above could be replaced with just the last item: o A Router Advertisement has been received with a public key that is not stored in the hosts' cache of certificates, or there is no authorization delegation chain to the host's trust anchor. The following should also be changed: Delegation Chain Solicitations SHOULD be rate limited and timed similarly with Router Solicitations, as specified in RFC 2461 [6]. to perhaps just some text about rate limiting (if even that is necessary...) Section 6.6 says Routers MAY send unsolicited Delegation Chain Advertisements for their configured trust anchor(s). When such advertisements are sent, their timing MUST follow the rules given for Router Advertisements in RFC 2461 [6]. Periodic, unsolicited DCAs, however, do not serve the same purpose as unsolicited RAs. Usually hosts that care about the certificates in a DCA will have already retrieved them as a consequence of receiving an RA, or they won't care about them at all. The only case I can think of where unsolicited DCAs could be useful is if they contain proxied certificates for routers on other links (in which case hosts would not be able to discovery them by receiving RAs). So if I'm not missing something, I propose that the wording be changed to make this explicit, i.e. Routers MAY send unsolicited Delegation Chain Advertisements for other routers that hosts may encounter on other links. Routers should not otherwise send unsolicited Delegation Chain Advertisements. I'm not sure I agree with the timing rules either - some randomization as per RFC 2461 is probably a good thing, but we don't need to inherit the complexity involved with sending adverts more frequently on startup. Regarding DCA rate limiting, RFC 2461 only mandates rate limiting for RAs sent to the all-nodes multicast group. DCAs (as currently specified) are only sent to all-nodes if unsolicited (in which case rate limiting is moot) or the DCS has an unspecified address (which is probably not common). So the rate-limiting rule mostly misses the mark. In fact, one scenario where it would be useful is when a router first comes up. It will multicast an RA, which will likely cause all hosts to send DCSs, which will in turn cause the router to multicast (to the solicited-node MC address) a storm of DCAs. Since the rate limiting only covers all-nodes MC, it will not prevent this (and if it did, many nodes would not be able to process the RA). To handle this sort of situation, I propose all multicast DCAs be rate limited and monitored. If a router finds that it is responding to a DCS too soon after one has just been sent, it should set the DCA's ID to 0 and multicast it to the all-nodes group. This should ensure both that the network is not flooded with DCAs and that all nodes receive the DCA. Jonathan -------------------------------------------------------------------- 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 Oct 16 03:57:49 2003 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23837 for ; Thu, 16 Oct 2003 03:57:48 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9G7tboq022046; Thu, 16 Oct 2003 09:55:37 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JYBCRJ; Thu, 16 Oct 2003 09:59:09 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9G7tYXA028648; Thu, 16 Oct 2003 09:55:34 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9G7shB5014243; Thu, 16 Oct 2003 09:54:43 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9G7shec014242; Thu, 16 Oct 2003 09:54:43 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9G7seB5014201 for ; Thu, 16 Oct 2003 09:54:40 +0200 (MET DST) Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1738615210; Thu, 16 Oct 2003 16:54:37 +0900 (JST) Date: Thu, 16 Oct 2003 16:54:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Cc: mip6@ietf.org, ietf-send@standards.ericsson.net Subject: RFC2462 update User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Hello, (Sorry for the cross-posting. This is because many people who are not in the ipv6 list may want to join the discussion. I'll restrict my further posting to the ipv6 list in order to avoid unnecessary noise.) As asked by the IPv6 wg co-chairs, I'm going to update the "IPv6 Stateless Address Autoconfiguration" document (which is currently RFC2462) as a new I-D. Since we'll soon miss the cut-off date for an initial I-D, my current plan is to make a list of issues raised so far (that include the very recent discussion in the ipv6 list) and submit a 00 draft containing the list. I'll send an initial proposal of the issue list to the ipv6 list in a day or so, get quick comments on the issue list, and then edit and submit the draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Oct 16 08:50:08 2003 Received: from penguin-ext.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 IAA01139 for ; Thu, 16 Oct 2003 08:50:07 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9GClcSs002242; Thu, 16 Oct 2003 14:47:39 +0200 (MEST) 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 45JQWPND; Thu, 16 Oct 2003 14:48:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9GClbXA006372; Thu, 16 Oct 2003 14:47:37 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GCkrB5021688; Thu, 16 Oct 2003 14:46:53 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9GCkrnU021687; Thu, 16 Oct 2003 14:46:53 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ftmail.lab.flarion.com (mail.flarion.com [63.103.94.23]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GCkpB5021669 for ; Thu, 16 Oct 2003 14:46:51 +0200 (MET DST) Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RCK9R>; Thu, 16 Oct 2003 08:46:38 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922DD9@ftmail.lab.flarion.com> From: Soliman Hesham To: ipv6@ietf.org Cc: mip6@ietf.org, ietf-send@standards.ericsson.net Subject: RFC2461 update Date: Thu, 16 Oct 2003 08:46:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-2022-JP" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Folks, Sorry for the cross posting. This is a heads up to let you know that I'm updating the Neighbour Discovery specification, RFC 2461 as requested by the IPv6 WG chairs. The updates are likely to include issues raised in the WGs copied on this email. If you're interested in following this discussion please monitor the IPv6 mailing list. Like Jinmeii, I'll be sending a list of issues that were raised and would appreciate your feedback. The list of issues will come towards the beginning of next week. I'm currently going through the archives. Hesham -------------------------------------------------------------------- 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 Oct 16 13:03:41 2003 Received: from albatross-ext.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 NAA11231 for ; Thu, 16 Oct 2003 13:03:41 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9GH1TI2028468; Thu, 16 Oct 2003 19:01:29 +0200 (MEST) 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 45JYHVXF; Thu, 16 Oct 2003 19:05:05 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9GH1SXA010983; Thu, 16 Oct 2003 19:01:28 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GH0jB5020013; Thu, 16 Oct 2003 19:00:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9GH0jQ7020010; Thu, 16 Oct 2003 19:00:45 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GH0hB5019977 for ; Thu, 16 Oct 2003 19:00:43 +0200 (MET DST) Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 180252F7316; Thu, 16 Oct 2003 12:58:51 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Thu, 16 Oct 2003 12:58:51 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id 183D5525DA; Thu, 16 Oct 2003 12:58:49 -0400 (EDT) Content-Disposition: inline Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: "Pekka Nikander" Date: Thu, 16 Oct 2003 22:28:48 +0530 X-Epoch: 1066323531 X-Sasl-enc: +duzLCSzSAz1/aqk5aI7Ag Cc: ietf-send@standards.ericsson.net Subject: Re: Comments on draft-ietf-send-psreq-03 References: ARRAY(0xa17d524) In-Reply-To: ARRAY(0xa17c810) Message-Id: <20031016165849.183D5525DA@smtp.us2.messagingengine.com> X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h9GH0iB5019986 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tjatte.sw.ericsson.se id h9GH1SXA010983 Content-Transfer-Encoding: quoted-printable On Wed, 15 Oct 2003 12:42:00 +0300, "Pekka Nikander" said: > The problem is that the psreq draft has already passed the IESG review, > I have already resolved the minor issues that they had, and now the > draft is waiting for their acceptanse on the resolutions. In other > words, the draft is fairly long on its way to become an RFC. I hadn't picked up the document with the intention of reviewing it. But, I had time, and I also had many suggestions so I mailed them. That's it. :-) I wasn't even a WG member then. Hopefully, I'll be wiser next time around, and check the document status. I do understand that some of the comments cannot be incorporated. Btw, is there any link that shows the document status? The main IETF page only points to documents in last call. > Based on the that status, and the fact that the draft does not specify > a protocol but is only informational, we are inclided to reject your > editorial suggestion #5 as a too large one. While it might be good, its > doesn't warrant the required new review. I was keen on this one. Anyways..... > Going to the technical comments: > > > 1. Threats for a L2-switch, and ND-proxies. L2-switches, and ND- > > proxies build their neighbor cache by snooping the source IPv6 > > address, and the corresponding link-layer address. It is possible > > to send fake NS/NA/RA/RD/redirect/Data (any packet which is used > > to build the neighbor cache), and do a redirect/DOS attack. > > > > I think section 4 should list a threat concerning such devices. > > While your intention is good, I think that any such work should be left > for future. There has been some discussion about these kinds of use > scenarios before. However, only maybe a couple of people have shown > real interest on working on those problems, and so far we have seen no > real, concrete input. I am surprised that there is not much input on the subject as I perceive that L2-switches, and similar devices can be exploited rather easily. > > 3. Section 4.2.1. > > a. What is the "entering node"? > > Well, a node attempting to discover a router is most probably a new > node entering to the link. I readily admit that the text is not > very clear. If you could propose how to revise the text, that would > be great. Maybe you can substitute entering node by "a node attempting to discover a router". It will cover all nodes irrespective of whether they have entered the network, or are already on the network, and are attempting to discover routers for no matter what reason. > > b. I might be a bit confused - isn=92t the section referring t= o > > the first-hop router? Can you also give the reference > > number to a section number in RFC2461 talks of this threat? > > The text has been inherited a few times. I would need to read RFC2461 > carefully in order to find out which section it is. But, yes, it would > be good to add a reference to the specific section. > > Does anybody else remember right away? More than the section number, I am concerned about the terminology. I think the text should refer to the router as a first hop router, and not as a last hop router. > > > c. The 3rd paragraph talks of RFC 2461, and 2462. Is there a > > conflict between these two documents? I am not able to > > understand why the default router selection procedure in > > section 6.3.6 needs a rule that concerns with the lifetime > > of the router. > > I am not really an expert on the differences between 2461 and 2462. > Could somebody else provide an answer? If good enough, I can add it to > the draft (if the IESG approves, of course). You can probably read section 5.5.3 of rfc2462, and 6.3.6 of rfc2461, and make the judgement. I think this paragraph is misleading, and should be rephrased. (Sorry, it's late in the night for me to suggest anything sensible. ;-)) > A pre-release of the updated draft, with the resolutions to the IESG > issues and your concerns, is available at > > http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.txt > http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.html > http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15.xml > > The changes are highlighted in > > http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-Oct15- > diff.html http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-04-pre-= Oct15- > chbar.txt Thanks. I am curious - what software do you use to get the changebars? regards, CP -------------------------------------------------------------------- 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 Oct 16 14:21:03 2003 Received: from albatross-ext.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 OAA14619 for ; Thu, 16 Oct 2003 14:21:02 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9GIIII2006583; Thu, 16 Oct 2003 20:18:18 +0200 (MEST) 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 43DT9JKV; Thu, 16 Oct 2003 20:18:45 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9GIIGXA011831; Thu, 16 Oct 2003 20:18:16 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GIHOB5007771; Thu, 16 Oct 2003 20:17:24 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9GIHOjR007770; Thu, 16 Oct 2003 20:17:24 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GIHNB5007752 for ; Thu, 16 Oct 2003 20:17:23 +0200 (MET DST) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 98E481C; Thu, 16 Oct 2003 21:30:37 +0300 (EEST) Message-ID: <3F8E4EC2.6050805@nomadiclab.com> Date: Thu, 16 Oct 2003 09:54:42 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Jonathan Wood , SEND WG Subject: Re: Trusted root names References: <037e01c39370$b5df0ce0$956015ac@dclkempt40> In-Reply-To: <037e01c39370$b5df0ce0$956015ac@dclkempt40> 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 >>> In a solicited-for advertisement, the router SHOULD include >>> suitable Certificate options so that a delegation chain to the >>> solicited root can be established. The root is identified by the >>> Trusted Root option. If the Trusted Root option is represented >>> as an FQDN, the FQDN must be equal to an FQDN in the >>> subjectAltName field of the root's certificate. If the Trusted >>> Root option is represented as a DER Encoded X.501 Name, then the >>> Name must be equal to the Subject field in the root's >>> certificate. The router SHOULD include the Trusted Root >>> option(s) in the advertisement for which the delegation chain was >>> found. >> >> This is better. However I'm now concerned that this may cause >> interop issues, ... >> >> I guess my discomfort with the DNS alt name stems primarily from my >> concern that DNS alt names may not always be there in certs and >> lookup tables, whereas I feel it more likely that DNs will be >> there. ... > > Well, I suppose I agree on this. Even having the DNS alt name in as > an option has the potential to lead to additional implementation and > deployment complexity. Keeping SEND simple is more likely to cause > people to want to implement it (a viewpoint from Randy Bush that I am > beginning to appreciate). Having the FQDN there as an OPTIONAL feature doesn't add much implementation complexity. The deployment complexity may be a real issue, though. > Perhaps the best course, for now, would be to simply require the DN > and leave any mention of the DNS alt name out. If DNS keys become > widely deployed, the spec can be revised at that time to include it > as an alternative. Well, for the current version of the draft, I did the following: - reordered the names so that DER Encoded X.501 Name is number 1 and FQDN is number 2 - made FQDN support OPTIONAL - added a requirement that a each Delegation Chain Solitiation MUST have at the first (or only) Trust Anchor option a DER Encoded X.501 Name. I think that this is more future proof, taking even care of the situation where people are using new types of Trust Anchors. What do you think? --Pekka -------------------------------------------------------------------- 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 Oct 16 14:21:05 2003 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14621 for ; Thu, 16 Oct 2003 14:21:03 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9GIICoq001915; Thu, 16 Oct 2003 20:18:13 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JQZCB7; Thu, 16 Oct 2003 20:18:47 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9GIIAXA011826; Thu, 16 Oct 2003 20:18:10 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GIHPB5007777; Thu, 16 Oct 2003 20:17:25 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9GIHPXP007774; Thu, 16 Oct 2003 20:17:25 +0200 (MET DST) 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 sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GIHOB5007768 for ; Thu, 16 Oct 2003 20:17:24 +0200 (MET DST) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 90EFC24; Thu, 16 Oct 2003 21:30:38 +0300 (EEST) Message-ID: <3F8E4FEE.8010009@nomadiclab.com> Date: Thu, 16 Oct 2003 09:59:42 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Wood Cc: SEND WG , Jari Arkko Subject: Re: DCS and DCA semantics References: In-Reply-To: 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 Jon, Unfortunately I don't have time to think about or incorprate these changes now. Hence, we have to wait for -01 with this. Jari, Could you create a new trackable issue on this? --Pekka > Sections 6.6 and 6.7 discuss how DCS and DCA should be sent > and processed. Much of this is based on RD semantics from RFC > 2461. However, DCS and DCA semantics are different from RD, > so in many cases I don't think this is appropriate. > > Specifically: > > Section 6.7 says > > When an interface becomes enabled, a host may be unwilling to wait > for the next unsolicited Delegation Chain Advertisement. To obtain > such advertisements quickly, a host MAY transmit up to > MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each > separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation > Chain Solicitations MAY be sent after any of the following events: > o The interface is initialized at system startup time. > o The interface is reinitialized after a temporary interface failure > or after being temporarily disabled by system management. > o The system changes from being a router to being a host, by having > its IP forwarding capability turned off by system management. > o The host attaches to a link for the first time. > o A movement has been indicated by lower layers or has been inferred > from changed information in a Router Advertisement. > o The host re-attaches to a link after being detached for some time. > o A Router Advertisement has been received with a public key that is > not stored in the hosts' cache of certificates, or there is no > authorization delegation chain to the host's trust anchor. > > All these will happen naturally as a consequence of a RS/RA exchange, > if the host cannot form a delegation chain for the RA. So I think the text > quoted above could be replaced with just the last item: > > o A Router Advertisement has been received with a public key that is > not stored in the hosts' cache of certificates, or there is no > authorization delegation chain to the host's trust anchor. > > The following should also be changed: > > Delegation Chain Solicitations SHOULD be rate limited and timed > similarly with Router Solicitations, as specified in RFC 2461 [6]. > > to perhaps just some text about rate limiting (if even that is > necessary...) > > Section 6.6 says > > Routers MAY send unsolicited Delegation Chain Advertisements for > their configured trust anchor(s). When such advertisements are sent, > their timing MUST follow the rules given for Router Advertisements in > RFC 2461 [6]. > > Periodic, unsolicited DCAs, however, do not serve the same purpose as > unsolicited RAs. Usually hosts that care about the certificates in a DCA > will > have already retrieved them as a consequence of receiving an RA, or > they won't care about them at all. The only case I can think of where > unsolicited > DCAs could be useful is if they contain proxied certificates for routers on > other links (in which case hosts would not be able to discovery them by > receiving RAs). So if I'm not missing something, I propose that the wording > be changed to make this explicit, i.e. > > Routers MAY send unsolicited Delegation Chain Advertisements for other > routers that hosts may encounter on other links. Routers should not > otherwise send unsolicited Delegation Chain Advertisements. > > I'm not sure I agree with the timing rules either - some randomization > as per RFC 2461 is probably a good thing, but we don't need to > inherit the complexity involved with sending adverts more frequently > on startup. > > Regarding DCA rate limiting, RFC 2461 only mandates rate limiting > for RAs sent to the all-nodes multicast group. DCAs (as currently > specified) are only sent to all-nodes if unsolicited (in which case rate > limiting is moot) or the DCS has an unspecified address (which is > probably not common). So the rate-limiting rule mostly misses the > mark. > > In fact, one scenario where it would be useful is when a router first > comes up. It will multicast an RA, which will likely cause all hosts > to send DCSs, which will in turn cause the router to multicast (to the > solicited-node MC address) a storm of DCAs. Since the rate limiting > only covers all-nodes MC, it will not prevent this (and if it did, many > nodes would not be able to process the RA). To handle this sort of > situation, I propose all multicast DCAs be rate limited and monitored. > If a router finds that it is responding to a DCS too soon after one has > just been sent, it should set the DCA's ID to 0 and multicast it to the > all-nodes group. This should ensure both that the network is not > flooded with DCAs and that all nodes receive the DCA. > > Jonathan > > > -------------------------------------------------------------------- > 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 Oct 16 14:53:01 2003 Received: from penguin-ext.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 OAA16193 for ; Thu, 16 Oct 2003 14:53:00 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9GIoeSs024543; Thu, 16 Oct 2003 20:50:41 +0200 (MEST) 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 43DT9RZB; Thu, 16 Oct 2003 20:51:07 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9GIoRwg021931; Thu, 16 Oct 2003 20:50:27 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GInxB5014948; Thu, 16 Oct 2003 20:49:59 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9GInxJD014947; Thu, 16 Oct 2003 20:49:59 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GInvB5014942 for ; Thu, 16 Oct 2003 20:49:58 +0200 (MET DST) Received: (qmail 30723 invoked from network); 16 Oct 2003 18:48:55 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Oct 2003 18:48:55 -0000 Date: Thu, 16 Oct 2003 11:48:54 -0700 Subject: Re: Trusted root names Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: James Kempf , SEND WG To: Pekka Nikander From: Jonathan Wood In-Reply-To: <3F8E4EC2.6050805@nomadiclab.com> Message-Id: <6421595A-0009-11D8-91BB-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, October 16, 2003, at 12:54 AM, Pekka Nikander wrote: > > Well, for the current version of the draft, I did the following: > > - reordered the names so that DER Encoded X.501 Name is number 1 > and FQDN is number 2 > > - made FQDN support OPTIONAL > > - added a requirement that a each Delegation Chain Solitiation > MUST have at the first (or only) Trust Anchor option a DER > Encoded X.501 Name. > > I think that this is more future proof, taking even care of > the situation where people are using new types of Trust Anchors. > > What do you think? > I am happy with this. Jonathan -------------------------------------------------------------------- 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 Oct 16 14:54:25 2003 Received: from penguin-ext.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 OAA16247 for ; Thu, 16 Oct 2003 14:54:24 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9GIqoSs024767; Thu, 16 Oct 2003 20:52:50 +0200 (MEST) 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 45JY24Y9; Thu, 16 Oct 2003 20:56:26 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9GIqnXA012451; Thu, 16 Oct 2003 20:52:49 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GIqgB5015464; Thu, 16 Oct 2003 20:52:42 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9GIqgUa015463; Thu, 16 Oct 2003 20:52:42 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9GIqeB5015458 for ; Thu, 16 Oct 2003 20:52:40 +0200 (MET DST) Message-ID: <006d01c39416$b16714e0$396015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "Jonathan Wood" Cc: "SEND WG" References: <6421595A-0009-11D8-91BB-0003930D291E@speakeasy.net> Subject: Re: Trusted root names Date: Thu, 16 Oct 2003 11:52:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Fine by me as well. jak ----- Original Message ----- From: "Jonathan Wood" To: "Pekka Nikander" Cc: "James Kempf" ; "SEND WG" Sent: Thursday, October 16, 2003 11:48 AM Subject: Re: Trusted root names > > On Thursday, October 16, 2003, at 12:54 AM, Pekka Nikander wrote: > > > > > Well, for the current version of the draft, I did the following: > > > > - reordered the names so that DER Encoded X.501 Name is number 1 > > and FQDN is number 2 > > > > - made FQDN support OPTIONAL > > > > - added a requirement that a each Delegation Chain Solitiation > > MUST have at the first (or only) Trust Anchor option a DER > > Encoded X.501 Name. > > > > I think that this is more future proof, taking even care of > > the situation where people are using new types of Trust Anchors. > > > > What do you think? > > > > I am happy with this. > > Jonathan > > -------------------------------------------------------------------- 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 Oct 17 02:04:29 2003 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12506 for ; Fri, 17 Oct 2003 02:04:28 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9H60Soq021775; Fri, 17 Oct 2003 08:00:28 +0200 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DNZHHR; Fri, 17 Oct 2003 08:04:27 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9H60RXA016114; Fri, 17 Oct 2003 08:00:27 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9H5xbB5029495; Fri, 17 Oct 2003 07:59:37 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9H5xbK6029494; Fri, 17 Oct 2003 07:59:37 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9H5xaB5029490 for ; Fri, 17 Oct 2003 07:59:36 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id D93651C for ; Fri, 17 Oct 2003 09:12:50 +0300 (EEST) Message-ID: <3F8F8552.7000300@ericsson.com> Date: Fri, 17 Oct 2003 08:59:46 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Closing issues 20 and 16 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 I haven't received any comments on my detailed proposals on how to edit in issues #20 and #16: http://standards.ericsson.net/lists/ietf-send/msg00685.html http://standards.ericsson.net/lists/ietf-send/msg00671.html Therefore I think that we can close them. If I am wrong, we can reopen both or either of them after -00 is out. --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 Fri Oct 17 02:04:29 2003 Received: from penguin-ext.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 CAA12497 for ; Fri, 17 Oct 2003 02:04:28 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9H60NSs016813; Fri, 17 Oct 2003 08:00:24 +0200 (MEST) 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 43D4DW4L; Fri, 17 Oct 2003 08:00:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9H60Iwg008536; Fri, 17 Oct 2003 08:00:18 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9H5xsB5029532; Fri, 17 Oct 2003 07:59:54 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9H5xrUE029531; Fri, 17 Oct 2003 07:59:53 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9H5xrB5029527 for ; Fri, 17 Oct 2003 07:59:53 +0200 (MET DST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 951D81C for ; Fri, 17 Oct 2003 09:13:07 +0300 (EEST) Message-ID: <3F8F8563.7080306@nomadiclab.com> Date: Fri, 17 Oct 2003 09:00:03 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: draft-ndopt issue status and editing responsibility 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 If I have done the tracking correctly, the current situation is as follows: - Issue 17 on Redirect is Open, since I didn't have cycles. - Issue 13 on some Clarifications is Proposed, since I couldn't figure out how to edit it in. - We have a new issue #27 on DCS and DCA semantics. This needs to be added to the web page. My understanding is that Jari will take the editing baton back once I've got the -00 out; that will happen shortly. I haven't been able to talk to Jari about this, though. --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 Fri Oct 17 02:19:00 2003 Received: from albatross-ext.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 CAA20417 for ; Fri, 17 Oct 2003 02:18:59 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9H6EbI2020767; Fri, 17 Oct 2003 08:14:38 +0200 (MEST) 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 45JY33H5; Fri, 17 Oct 2003 08:18:15 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9H6EaXA016246; Fri, 17 Oct 2003 08:14:36 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9H6E6B5002924; Fri, 17 Oct 2003 08:14:06 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9H6E6ns002923; Fri, 17 Oct 2003 08:14:06 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9H6E5B5002919 for ; Fri, 17 Oct 2003 08:14:05 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 0E3D81C for ; Fri, 17 Oct 2003 09:27:20 +0300 (EEST) Message-ID: <3F8F88B7.7060102@ericsson.com> Date: Fri, 17 Oct 2003 09:14:15 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: draft-ietf-send-ndopt-00.txt is out 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 I have now submitted draft-ietf-send-ndopt-00.txt to the repositories. In the meanwhile, it is available at the following URLs. http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00.txt http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00.html http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00.xml --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 Fri Oct 17 11:40:50 2003 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07201 for ; Fri, 17 Oct 2003 11:40:49 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9HFb1oq007683; Fri, 17 Oct 2003 17:37:01 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JRBT39; Fri, 17 Oct 2003 17:37:37 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9HFaiwg010402; Fri, 17 Oct 2003 17:36:45 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9HFZnB5013853; Fri, 17 Oct 2003 17:35:49 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9HFZnGa013851; Fri, 17 Oct 2003 17:35:49 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9HFZlB5013844 for ; Fri, 17 Oct 2003 17:35:48 +0200 (MET DST) Message-ID: <00ad01c394c4$5c7f8df0$396015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" References: <3F8F8563.7080306@nomadiclab.com> Subject: Re: draft-ndopt issue status and editing responsibility Date: Fri, 17 Oct 2003 08:35:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Thanx for your hard work on this. jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Sent: Thursday, October 16, 2003 11:00 PM Subject: draft-ndopt issue status and editing responsibility > If I have done the tracking correctly, the current situation > is as follows: > > - Issue 17 on Redirect is Open, since I didn't have cycles. > - Issue 13 on some Clarifications is Proposed, since I couldn't > figure out how to edit it in. > - We have a new issue #27 on DCS and DCA semantics. This needs > to be added to the web page. > > My understanding is that Jari will take the editing baton back > once I've got the -00 out; that will happen shortly. I haven't > been able to talk to Jari about this, though. > > --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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Oct 20 04:47:10 2003 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18021 for ; Mon, 20 Oct 2003 04:47:08 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9K8eJoq003068; Mon, 20 Oct 2003 10:40:19 +0200 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JZRGS8; Mon, 20 Oct 2003 10:44:09 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9K8dvwg021872; Mon, 20 Oct 2003 10:39:57 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9K8cjB5008976; Mon, 20 Oct 2003 10:38:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9K8cjUw008975; Mon, 20 Oct 2003 10:38:45 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9K8ciB5008971 for ; Mon, 20 Oct 2003 10:38:44 +0200 (MET DST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Oct 2003 01:38:42 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Oct 2003 01:38:42 -0700 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 20 Oct 2003 01:38:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Oct 2003 01:36:44 -0700 Message-ID: <64A531765B7C8342BFA260497BE004571E60BA@RED-MSG-43.redmond.corp.microsoft.com> Thread-Index: AcOW5UrMYz3uEanXQ1eQJA8Y6UYiwA== From: "Tuomas Aura" To: "SEND WG" X-OriginalArrivalTime: 20 Oct 2003 08:38:32.0956 (UTC) FILETIME=[8B8E93C0:01C396E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id h9K8cjB5008972 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit I have submitted a new version of draft-ietf-send-cga-02 with only very minor modifications to the previous version. It is immediately available at: http://research.microsoft.com/users/tuomaura/CGA/draft-ietf-send-cga-02. txt The issues list is at: http://research.microsoft.com/users/tuomaura/CGA/CGAIssues.aspx 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 Tue Oct 21 05:41:32 2003 Received: from penguin-ext.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 FAA11509 for ; Tue, 21 Oct 2003 05:41:31 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9L9apSs027310; Tue, 21 Oct 2003 11:36:56 +0200 (MEST) 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 45JSAF00; Tue, 21 Oct 2003 11:37:43 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9L9adwg005619; Tue, 21 Oct 2003 11:36:41 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9L9ZYB5005827; Tue, 21 Oct 2003 11:35:34 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9L9ZYA4005826; Tue, 21 Oct 2003 11:35:34 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9L9ZWB5005822 for ; Tue, 21 Oct 2003 11:35:33 +0200 (MET DST) Message-ID: <017801c397b6$b6cf0b10$0a6015ac@dclkempt40> From: "James Kempf" To: Subject: Last Call on draft-ietf-send-cga-02.txt Date: Tue, 21 Oct 2003 02:35:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Pekka and I want to issue a Last Call on draft-ietf-send-cga-02.txt (the CGA draft), expiring on Nov. 7. We are making the Last Call extra long because people are busy right now with pre-IETF preparations. We will be discussing Last Call comments at the meeting in Minneapolis. Please pay careful attention to any omissions/incompatibilities/need for correction between this draft and draft-ietf-send-ndopts-00.txt, as we will be taking that draft to Last Call right after 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 Tue Oct 21 05:43:51 2003 Received: from penguin-ext.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 FAA11549 for ; Tue, 21 Oct 2003 05:43:50 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9L9eVSs027892; Tue, 21 Oct 2003 11:40:31 +0200 (MEST) 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 45JZ0699; Tue, 21 Oct 2003 11:44:25 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9L9eUXA014365; Tue, 21 Oct 2003 11:40:30 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9L9eJB5006679; Tue, 21 Oct 2003 11:40:19 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9L9eI7T006678; Tue, 21 Oct 2003 11:40:18 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9L9eGB5006674 for ; Tue, 21 Oct 2003 11:40:17 +0200 (MET DST) Message-ID: <017901c397b7$60eba090$0a6015ac@dclkempt40> From: "James Kempf" To: Subject: Please read and comment on draft-ietf-send-ndopts-00.txt Date: Tue, 21 Oct 2003 02:40:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Pekka and I have decided not to issue Last Call on draft-ietf-send-ndopts-00.txt at this time, since there is missing text and a few additional unresolved issues that need to be put into place first. The plan is to generate a version 01 as soon as the gate opens after the Minneapolis meeting, and the remaining work is done. We will be discussing the unresolved issues in Minneapolis. However, we would like to encourage people to *please* read the draft and look for any additional issues, expecially w.r.t. the CGA draft, since we would like to send that to the IESG right after Minneapolis. We will discuss any issues raised but not resolved on the list in Minneapolis. For reference, the SEND issues list is at: http://www.piuha.net/~jarkko/publications/send/issues/ Thanx. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Oct 21 09:28:14 2003 Received: from penguin-ext.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 JAA16742 for ; Tue, 21 Oct 2003 09:28:13 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9LDP8Ss014175; Tue, 21 Oct 2003 15:25:08 +0200 (MEST) 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 43D399JQ; Tue, 21 Oct 2003 15:29:26 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9LDP5wg022014; Tue, 21 Oct 2003 15:25:05 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9LDODB5028674; Tue, 21 Oct 2003 15:24:13 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9LDODkc028673; Tue, 21 Oct 2003 15:24:13 +0200 (MET DST) 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 sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9LDOCB5028669 for ; Tue, 21 Oct 2003 15:24:12 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6A9491C; Tue, 21 Oct 2003 16:37:25 +0300 (EEST) Message-ID: <3F95337C.7020908@ericsson.com> Date: Tue, 21 Oct 2003 16:24:12 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chirayu Patel Cc: ietf-send@standards.ericsson.net Subject: Re: Comments on draft-ietf-send-psreq-03 References: ARRAY(0xa17d524) <20031016165849.183D5525DA@smtp.us2.messagingengine.com> In-Reply-To: <20031016165849.183D5525DA@smtp.us2.messagingengine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by fnatte.sw.ericsson.se id h9LDP5wg022014 Content-Transfer-Encoding: quoted-printable Chirayu, Sorry for the delay in answering (again), but I have been busy trying to get drafts out. > Btw, is there any link that shows the document status? The main IETF pa= ge > only points to documents in last call. Go to the IETF web page -> WG Chairs -> ID tracker. There you can look up the status of WG IDs. >>> b. I might be a bit confused - isn=92t the section referring to >>> the first-hop router? Can you also give the reference >>> number to a section number in RFC2461 talks of this threat? >> > More than the section number, I am concerned about the terminology. I > think the text should refer to the router as a first hop router, and no= t > as a last hop router. Valid point. I will fix this if there is yet another round of the=20 draft. (Made the change to the internal 05-pre version, which may be or may not be ever used.) > Thanks. I am curious - what software do you use to get the changebars? Some hack called chbars.sh. I have seen better ones, should try to locate one. --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 Sat Oct 25 04:13:08 2003 Received: from albatross-ext.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 EAA29149 for ; Sat, 25 Oct 2003 04:13:07 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9P8ADI2010667; Sat, 25 Oct 2003 10:10:14 +0200 (MEST) 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 VRY1M8FY; Sat, 25 Oct 2003 10:10:13 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9P8ACXA029107; Sat, 25 Oct 2003 10:10:12 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9P87gB5028543; Sat, 25 Oct 2003 10:07:42 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9P87glY028542; Sat, 25 Oct 2003 10:07:42 +0200 (MET DST) 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 sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9P87fB5028538 for ; Sat, 25 Oct 2003 10:07:41 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id A7EC91C; Sat, 25 Oct 2003 11:20:53 +0300 (EEST) Message-ID: <3F9A2F4C.7080504@ericsson.com> Date: Sat, 25 Oct 2003 11:07:40 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: James Kempf , Jari Arkko , Tuomas Aura , Jonathan Wood Subject: Draft Agenda for SEND WG meeting at 58th IETF in Minneapolis 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 SEND (Securing IPv6 Neighbor Discovery) Draft Agenda ---------------------------------------------------- TUESDAY, November 11, 2003 1300-1400 Afternoon Sessions I Chairs: James Kempf Pekka Nikander Agenda: 10 min Preliminaries Chairs - Agenda bashing - Action points followup - Significant changes after Vienna 15 min Implementation report Jonathan Wood 10 min CGA last call issues Pekka Nikander on I-D: draft-ietf-send-cga-02.txt behalf of Tuomas Aura 10 min NDOPTs Open issues Jari Arkko I-D: draft-ietf-send-ndopt-00.txt 5 min Next steps Chairs and ADs -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Oct 25 05:42:00 2003 Received: from albatross-ext.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 FAA00745 for ; Sat, 25 Oct 2003 05:41:59 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9P9dmI2019049; Sat, 25 Oct 2003 11:39:49 +0200 (MEST) 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 VRYFKBLR; Sat, 25 Oct 2003 11:40:56 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9P9dZwg014074; Sat, 25 Oct 2003 11:39:35 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9P9dHB5019025; Sat, 25 Oct 2003 11:39:17 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9P9dHJo019024; Sat, 25 Oct 2003 11:39:17 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9P9dEB5019007 for ; Sat, 25 Oct 2003 11:39:15 +0200 (MET DST) Message-ID: <048101c39adb$e0312ba0$896015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" Cc: "Jari Arkko" , "Tuomas Aura" , "Jonathan Wood" References: <3F9A2F4C.7080504@ericsson.com> Subject: Re: Draft Agenda for SEND WG meeting at 58th IETF in Minneapolis Date: Sat, 25 Oct 2003 02:39:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Oops, sorry. If Jon doesn't come, I will present the report. jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Cc: "James Kempf" ; "Jari Arkko" ; "Tuomas Aura" ; "Jonathan Wood" Sent: Saturday, October 25, 2003 1:07 AM Subject: Draft Agenda for SEND WG meeting at 58th IETF in Minneapolis > SEND (Securing IPv6 Neighbor Discovery) Draft Agenda > ---------------------------------------------------- > > TUESDAY, November 11, 2003 > 1300-1400 Afternoon Sessions I > > Chairs: James Kempf > Pekka Nikander > > Agenda: > > 10 min Preliminaries Chairs > - Agenda bashing > - Action points followup > - Significant changes after Vienna > > 15 min Implementation report Jonathan Wood > > 10 min CGA last call issues Pekka Nikander on > I-D: draft-ietf-send-cga-02.txt behalf of Tuomas Aura > > 10 min NDOPTs Open issues Jari Arkko > I-D: draft-ietf-send-ndopt-00.txt > > 5 min Next steps Chairs and ADs > > > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Oct 25 05:42:13 2003 Received: from albatross-ext.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 FAA00764 for ; Sat, 25 Oct 2003 05:42:12 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9P9dmI2019048; Sat, 25 Oct 2003 11:39:49 +0200 (MEST) 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 VRYDYCS8; Sat, 25 Oct 2003 11:39:48 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9P9dTwg014067; Sat, 25 Oct 2003 11:39:29 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9P9ceB5018929; Sat, 25 Oct 2003 11:38:40 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9P9ceoI018927; Sat, 25 Oct 2003 11:38:40 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9P9caB5018910 for ; Sat, 25 Oct 2003 11:38:37 +0200 (MET DST) Message-ID: <046b01c39adb$c1614ac0$896015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "SEND WG" Cc: "Jari Arkko" , "Tuomas Aura" , "Jonathan Wood" References: <3F9A2F4C.7080504@ericsson.com> Subject: Re: Draft Agenda for SEND WG meeting at 58th IETF in Minneapolis Date: Sat, 25 Oct 2003 02:38:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Looks fine. Though, I wonder if we can get DoCoMo to spring for Jon's airfare/lodging to Minneapolis... jak ----- Original Message ----- From: "Pekka Nikander" To: "SEND WG" Cc: "James Kempf" ; "Jari Arkko" ; "Tuomas Aura" ; "Jonathan Wood" Sent: Saturday, October 25, 2003 1:07 AM Subject: Draft Agenda for SEND WG meeting at 58th IETF in Minneapolis > SEND (Securing IPv6 Neighbor Discovery) Draft Agenda > ---------------------------------------------------- > > TUESDAY, November 11, 2003 > 1300-1400 Afternoon Sessions I > > Chairs: James Kempf > Pekka Nikander > > Agenda: > > 10 min Preliminaries Chairs > - Agenda bashing > - Action points followup > - Significant changes after Vienna > > 15 min Implementation report Jonathan Wood > > 10 min CGA last call issues Pekka Nikander on > I-D: draft-ietf-send-cga-02.txt behalf of Tuomas Aura > > 10 min NDOPTs Open issues Jari Arkko > I-D: draft-ietf-send-ndopt-00.txt > > 5 min Next steps Chairs and ADs > > > > -------------------------------------------------------------------- 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 Oct 30 13:24:38 2003 Received: from penguin-ext.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 NAA03974 for ; Thu, 30 Oct 2003 13:24:37 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9UIMASs013760; Thu, 30 Oct 2003 19:22:10 +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.2657.72) id V63A93V6; Thu, 30 Oct 2003 19:22:13 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9UILEXA014073; Thu, 30 Oct 2003 19:21:14 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9UIIWB5018239; Thu, 30 Oct 2003 19:18:32 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9UIIWcb018238; Thu, 30 Oct 2003 19:18:32 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9UIIVB5018234 for ; Thu, 30 Oct 2003 19:18:31 +0100 (MET) Received: from piuha.net ([62.248.252.129]) by fep02-app.kolumbus.fi with ESMTP id <20031030181831.LIWU2186.fep02-app.kolumbus.fi@piuha.net>; Thu, 30 Oct 2003 20:18:31 +0200 Message-ID: <3FA13D72.9060401@kolumbus.fi> Date: Thu, 30 Oct 2003 18:33:54 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Wood CC: SEND WG Subject: Re: DCS and DCA semantics References: In-Reply-To: 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 Jonathan Wood wrote: > > Sections 6.6 and 6.7 discuss how DCS and DCA should be sent > and processed. Much of this is based on RD semantics from RFC > 2461. However, DCS and DCA semantics are different from RD, > so in many cases I don't think this is appropriate. Ok, reading on... > Specifically: > > Section 6.7 says > > When an interface becomes enabled, a host may be unwilling to wait > for the next unsolicited Delegation Chain Advertisement. To obtain > such advertisements quickly, a host MAY transmit up to > MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each > separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation > Chain Solicitations MAY be sent after any of the following events: > o The interface is initialized at system startup time. > o The interface is reinitialized after a temporary interface failure > or after being temporarily disabled by system management. > o The system changes from being a router to being a host, by having > its IP forwarding capability turned off by system management. > o The host attaches to a link for the first time. > o A movement has been indicated by lower layers or has been inferred > from changed information in a Router Advertisement. > o The host re-attaches to a link after being detached for some time. > o A Router Advertisement has been received with a public key that is > not stored in the hosts' cache of certificates, or there is no > authorization delegation chain to the host's trust anchor. > > All these will happen naturally as a consequence of a RS/RA exchange, > if the host cannot form a delegation chain for the RA. So I think the text > quoted above could be replaced with just the last item: > > o A Router Advertisement has been received with a public key that is > not stored in the hosts' cache of certificates, or there is no > authorization delegation chain to the host's trust anchor. Hmm... this sounds very good actually. It even covers the case when the router's key is re-configured but everything else stays the same. Just one check: you are replacing just the items, and keeping the rate limiting? I think we need that. Perhaps this could be the final text: The host has a need to retrieve a delegation chain when a Router Advertisement has been received with a public key that is not stored in the hosts' cache of certificates, or there is no authorization delegation chain to the host's trust anchor. In these situations, the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain Solicitation messages, each separated by at least DCS_INTERVAL seconds. (And MAX_DCS_MESSAGES would be defined similarly to MAX_RTR_SOLICITATIONS, and DCS_INTERVAL similarly for RTR_SOLICITATION_INTERVAL) > The following should also be changed: > > Delegation Chain Solicitations SHOULD be rate limited and timed > similarly with Router Solicitations, as specified in RFC 2461 [6]. > > to perhaps just some text about rate limiting (if even that is > necessary...) Ah, you thought about this too. Well, I think the host should be able to send multiple messages if there's packet loss, but not too often. Maybe the text that I provided above works. > Section 6.6 says > > Routers MAY send unsolicited Delegation Chain Advertisements for > their configured trust anchor(s). When such advertisements are sent, > their timing MUST follow the rules given for Router Advertisements in > RFC 2461 [6]. > > Periodic, unsolicited DCAs, however, do not serve the same purpose as > unsolicited RAs. Usually hosts that care about the certificates in a DCA > will > have already retrieved them as a consequence of receiving an RA, or > they won't care about them at all. The only case I can think of where > unsolicited > DCAs could be useful is if they contain proxied certificates for routers on > other links (in which case hosts would not be able to discovery them by > receiving RAs). So if I'm not missing something, I propose that the wording > be changed to make this explicit, i.e. Routers are allowed to send the DCAs to the specific node (or its solicited-node address to be more exact). A periodic DCA to the all-nodes address might be received by all hosts. OTOH, the routers are also allowed to the send the solicited DCAs to the all-nodes address. This depends on what the source of the DCS was. If there's multiple nodes coming to the link at the same time, they probably don't have an address yet, and the DCA goes to all then... maybe you are right and we don't need periodic DCAs. > Routers MAY send unsolicited Delegation Chain Advertisements for other > routers that hosts may encounter on other links. Routers should not > otherwise send unsolicited Delegation Chain Advertisements. Hmm... there might be other means of receiving information from the other links. I wonder if we need a SEND specific scheme here. Delete periodic DCA completely? > I'm not sure I agree with the timing rules either - some randomization > as per RFC 2461 is probably a good thing, but we don't need to > inherit the complexity involved with sending adverts more frequently > on startup. > > Regarding DCA rate limiting, RFC 2461 only mandates rate limiting > for RAs sent to the all-nodes multicast group. DCAs (as currently > specified) are only sent to all-nodes if unsolicited (in which case rate > limiting is moot) or the DCS has an unspecified address (which is > probably not common). So the rate-limiting rule mostly misses the > mark. Ok. > In fact, one scenario where it would be useful is when a router first > comes up. It will multicast an RA, which will likely cause all hosts > to send DCSs, which will in turn cause the router to multicast (to the > solicited-node MC address) a storm of DCAs. Since the rate limiting > only covers all-nodes MC, it will not prevent this (and if it did, many > nodes would not be able to process the RA). To handle this sort of > situation, I propose all multicast DCAs be rate limited and monitored. > If a router finds that it is responding to a DCS too soon after one has > just been sent, it should set the DCA's ID to 0 and multicast it to the > all-nodes group. This should ensure both that the network is not > flooded with DCAs and that all nodes receive the DCA. Sounds good. Essentially, we'd be allowing the router to respond to the all-nodes address at its discretion. --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 Oct 30 13:24:43 2003 Received: from albatross-ext.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 NAA03991 for ; Thu, 30 Oct 2003 13:24:42 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9UIMAI2002114; Thu, 30 Oct 2003 19:22:10 +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.2657.72) id V6NLL15X; Thu, 30 Oct 2003 19:22:10 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9UIL8XA014063; Thu, 30 Oct 2003 19:21:08 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9UIIcB5018276; Thu, 30 Oct 2003 19:18:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9UIIchi018275; Thu, 30 Oct 2003 19:18:38 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9UIIbB5018265 for ; Thu, 30 Oct 2003 19:18:37 +0100 (MET) Received: from piuha.net ([62.248.252.129]) by fep02-app.kolumbus.fi with ESMTP id <20031030181837.LIXV2186.fep02-app.kolumbus.fi@piuha.net>; Thu, 30 Oct 2003 20:18:37 +0200 Message-ID: <3FA13FAC.5000107@kolumbus.fi> Date: Thu, 30 Oct 2003 18:43:24 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG Subject: Re: New issue?: The scope of source address for DCS? References: <3F8A5221.1040902@ericsson.com> In-Reply-To: <3F8A5221.1040902@ericsson.com> 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 Pekka Nikander wrote: > Folks, > > With regard to the DCS source address, the current spec says > the following: > > An IP address assigned to the sending interface, or the > unspecified address if no address is assigned to the sending > interface. > > Should we be more specific, and say that the source address SHOULD > be the link local address? Right now I don't see any specific > reason, other than the old saying of being conservative when > sending and liberal when receiving. In issue 21 we agreed that DCA source should be link-local. It seems logical to require the same from DCS? --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 Oct 30 13:25:00 2003 Received: from penguin-ext.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 NAA04015 for ; Thu, 30 Oct 2003 13:24:59 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9UIMsSs013921; Thu, 30 Oct 2003 19:22:58 +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.2657.72) id V6MFR8FD; Thu, 30 Oct 2003 19:22:54 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id h9UIMlXA014123; Thu, 30 Oct 2003 19:22:47 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9UIMKB5018913; Thu, 30 Oct 2003 19:22:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id h9UIMKEQ018912; Thu, 30 Oct 2003 19:22:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id h9UIMJB5018908 for ; Thu, 30 Oct 2003 19:22:19 +0100 (MET) Received: from kolumbus.fi ([62.248.252.129]) by fep02-app.kolumbus.fi with ESMTP id <20031030182219.LKEV2186.fep02-app.kolumbus.fi@kolumbus.fi>; Thu, 30 Oct 2003 20:22:19 +0200 Message-ID: <3FA155E0.2090906@kolumbus.fi> Date: Thu, 30 Oct 2003 20:18:08 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG Subject: Re: draft-ndopt issue status and editing responsibility References: <3F8F8563.7080306@nomadiclab.com> In-Reply-To: <3F8F8563.7080306@nomadiclab.com> 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 Pekka Nikander wrote: > If I have done the tracking correctly, the current situation > is as follows: > > - Issue 17 on Redirect is Open, since I didn't have cycles. > - Issue 13 on some Clarifications is Proposed, since I couldn't > figure out how to edit it in. > - We have a new issue #27 on DCS and DCA semantics. This needs > to be added to the web page. Done. The issues web has now been updated: http://www.arkko.com/publications/send/issues/ > My understanding is that Jari will take the editing baton back > once I've got the -00 out; that will happen shortly. Yes. I'm back at work now, and finally getting to SEND too. Thanks for producing an excellent 00 version! --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------