From jari.arkko@lmf.ericsson.se Mon Feb 2 02:56:38 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23853 for ; Mon, 2 Feb 2004 02:56:37 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i127ubAh006392 for ; Mon, 2 Feb 2004 08:56:37 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 08:56:43 +0100 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 1A62TBVC; Mon, 2 Feb 2004 08:56:42 +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 i127uaXA006442; Mon, 2 Feb 2004 08:56:36 +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 i127pbIt026863; Mon, 2 Feb 2004 08:51:37 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i127paLT026862; Mon, 2 Feb 2004 08:51:36 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i127pZIt026858 for ; Mon, 2 Feb 2004 08:51:35 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i127p0Q30207; Mon, 2 Feb 2004 09:51:00 +0200 Date: Mon, 2 Feb 2004 09:51:00 +0200 (EET) From: Pekka Savola To: iesg@ietf.org cc: ietf-send@standards.ericsson.net Subject: Re: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 02 Feb 2004 07:56:43.0821 (UTC) FILETIME=[195EB5D0:01C3E962] On Mon, 19 Jan 2004, The IESG wrote: > - 'Cryptographically Generated Addresses (CGA) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-02. This is basically a very good document, but seems to call for a bit more clarity in certain places. That is, the sections up to 5 aren't sufficiently clear, IMHO, that using CGA itself gives you nothing (security considerations is OK though). Anyone possessing the public key can generate the CGA, so that in itself provides no ownership. Ownership can only be proven through other protocols, or by applying the private key in a signature. This should require some rewording, e.g.: In order to verify the association between the address and the public key, the verifier needs to know the address itself, the public key, and the values of the auxiliary parameters. No additional security infrastructure, such as a public key infrastructure (PKI), certification authorities, or other trusted servers, is needed. ==> add something like, modified from the security considerations: Note that an attacker can create a new address from an arbitrary subnet prefix and its own (or anyone else's) public key because CGAs themselves are not certified -- and unless a message has been specifically signed, connection to the real owner of the public key can't be verified. That is, the attacker cannot impersonate somebody else's address when a message is being signed using the private key related to the public key used to generate the CGA. There are other places in the first sections where this could be made clearer. On their own, CGAs prove nothing. It's only with when the private key is applied than some guarantees can be obtained. Another thing which I don't think has been discussed sufficiently is the CPU resource exhaustion attacks. Are there ways using which the nodes might be forced to perform heavy signature or CGA verification steps (e.g., flood with a lot of CGA addresses, where the parameters etc. were trivially calculated)? Luckily enough, you can't force the receivers to perform heavy hash2 computation (i.e., sec > 0) unless you first break sec=0. A few more specific comments below. substantial ----------- 3. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are all zero (or if Sec=0), continue with step (4). Otherwise, increment the modifier and go back to step (2). ==> the modifier is a random number. Do you increment it by *one* (not specified but implicit I guess) or re-randomize it? If not re-randomize, why not? 6. Concatenate from left to right the modifier, 9 zero octets, and the public key. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2. 7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one of them is non-zero, the CGA verification fails. Otherwise, the verification succeeds. (If Sec=0, the CGA verification never fails at this step.) ==> so, 7. seems to say that for the verification to succeed, the hash2 value must be zero. Looking again at the generation of hash values (rules 2. and 3.) it seems that for e.g. sec=3, you'd probably have to generate the hash function billions of times, until the first 48 bits are all zeros. What kind of hash computation is that?!?! What's the point? Shouldn't you just generate the hash, and when verifying it, check that it's equal? (now it checks that it's zero)? If this kind of very heavy computation is intended, it should be spelled out explicitly I think. If the verification succeeds, the verifier knows that the public key in the CGA Parameters is the authentic public key of the address owner. ==> this is an inaccurate statement. This verification gives you nothing except the knowledge that the CGA address has been generated using a public key -- anyone with the public key can do it. So, "authentic public key of the address owner" seems to give a hint about the use of private address, and this is only OK after the verifying a signature. Note that the values of bits 6 and 7 (the "u" and "g" bits) of the interface identifier are ignored during CGA verification. After the verification succeeds, the verifier SHOULD process all CGAs in the same way regardless of the Sec, modifier and collision count values. In particular, the verifier SHOULD NOT have any security policy that differentiates between addresses based on the value of Sec. That way, the address generator is free choose any value of Sec. ==> I find it difficult to justify this SHOULD NOT. I feel it's totally wrong for this document to state that you SHOULD not differentiate between the different strengths of an address (e.g., if a site considers sec=0 too light, it could only treat sec >= 1 as being "good"). This seems to be something we should not disallow. This would seem to be similar to saying that one SHOULD not differentiate security policies whether e.g. a single DES or 3DES was being used. For each valid CGA Parameters data structure, there are 4*(Sec+1) different CGAs that match the value. This is because decrementing the Sec value in the three leftmost bits of the interface identifier does not invalidate the address, ==> s/decrementing/changing (typically decrementing)/ -- you can up the sec as well, even though for an attacker that's probably not lucrative -- unless maybe if CPU resource exhaustion is the goal. Intellectual Property Statement ==> this doesn't include the note that the IETF has been notified of some claims. This is a must. editorial --------- Discovery (SEND) protocol [I-D.ietf-send-ndopt]. The basic idea is to ==> could one use some other identifier for the drafts..? A cryptographically generated address is an IPv6 address for which the following two equations hold: Hash1 & Mask2 == interface identifier & Mask2 Hash2 & Mask1 == 0x0000000000000000000000000000 ==> any reason why you wouldn't defined Mask2 and Mask1 the other way, then they would be associated with the hashes of the same number? address (e.g., as an RFC-3041 address [RFC3041]). An attacker does ==> s/RFC-/RFC / multiple pseudorandom CGAs by executing the CGA generation algorithm of Section 4 multiple times and by using a different random or pseudorandom initial value for the modifier every time. The host ==> s/by using/using/ This document defines a new CGA Message Type name space for use as type tags in messages may be signed using CGA signatures. ==> s/may/that may/ ? The new values SHOULD be generated by the requester with a strong random-number generator. ==> reword to: The requester SHOULD generated the new values with a strong random-number generator. Michael Roe, Dave Thaler, and several other participants of the IETF working group. ==> s/IETF/SEND/ ? -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 2 11:16:06 2004 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 LAA20769 for ; Mon, 2 Feb 2004 11:16:06 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i12GG4qY003207 for ; Mon, 2 Feb 2004 17:16:05 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 17:16:58 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1AZZ98C7; Mon, 2 Feb 2004 17:16:27 +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 i12GG3XA007796; Mon, 2 Feb 2004 17:16:03 +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 i12GFDIt013143; Mon, 2 Feb 2004 17:15:13 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i12GFDbQ013140; Mon, 2 Feb 2004 17:15:13 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i12GFAIt013043 for ; Mon, 2 Feb 2004 17:15:11 +0100 (MET) Message-ID: <000201c3e9a7$cc07a850$936015ac@dclkempt40> From: "James Kempf" To: Subject: Last Call Issue: Deprecating RFC 2461 Security Date: Sat, 31 Jan 2004 02:49:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 02 Feb 2004 16:16:58.0775 (UTC) FILETIME=[FBAD3A70:01C3E9A7] Content-Transfer-Encoding: 7bit RFC 2461 Section 11 specifies using IPsec AH for Neighbor Discovery security. But, as described in the ND options draft, this will only work with manual keying and then the number of SAs may become large on links with many nodes. Therefore, I'd like to suggest inclusion of a section in draft-ietf-send-ndopts that specifically deprecates Section 11 of RFC 2461. In Minneapolis, I asked Steve Bellovin about this and he mentioned he thought it would be OK. Here is the text I would like to suggest: 10.0 Deprecation of RFC 2461 Security Section 11 of RFC 2461 [7] specifies that IPsec AH should be used for Neighbor Discovery security. However, as described in [21], IPsec can only be used if keys are configured manually, and even then, the number of security associations generated can become large if many nodes are on the link. Therefore, Section 11 of RFC 2461 is deprecated as soon as this specification is approved as a proposed standard. Comments? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 2 11:16:24 2004 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 LAA20810 for ; Mon, 2 Feb 2004 11:16:24 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i12GGPqY003448 for ; Mon, 2 Feb 2004 17:16:25 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 17:16:24 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1CVTV2LQ; Mon, 2 Feb 2004 17:16:23 +0100 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 i12GGCwg002800; Mon, 2 Feb 2004 17:16:12 +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 i12GFDIt013142; Mon, 2 Feb 2004 17:15:13 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i12GFD9U013137; Mon, 2 Feb 2004 17:15:13 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i12GFAIt013037 for ; Mon, 2 Feb 2004 17:15:11 +0100 (MET) Message-ID: <000101c3e9a7$cbcdac90$936015ac@dclkempt40> From: "James Kempf" To: Subject: Last Call Issue: CRL Check on DCA Certs Date: Sat, 31 Jan 2004 02:40:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 02 Feb 2004 16:16:24.0593 (UTC) FILETIME=[E74D7810:01C3E9A7] Content-Transfer-Encoding: 7bit The last paragraph in Section 6.1.1 says this about checking certificates received in a DCA for validity: When processing the three certificates, the usual RFC 3280 certificate path validation is performed, for instance by checking for revoked certificates. As a practical matter, the node will typically be performing the certificate check in response to a router advertisement containing a signature for which the host does not have the certificate. So the host will not at that time have a connection to the Internet by which it can perform a CRL check. Therefore, the host will be unable to perform a CRL check, exposing it to the possibility that the router may have been compromised and its certificate revoked. What to do? I'd like to suggest the following text: When procesing the three certificates, the usual RFC 3280 certificate path validation is performed. Note, however, that at the time a node is checking certificates received in a DCA from a router, it typically does not have a connection to the Internet yet, and so it is not possible to perform an on-line Certificate Revocation List (CRL) check if such a check is necessary. Until such a check is performed, acceptance of the certificate MUST be considered provisional, and the node MUST perform a check as soon as it has established a connection with the Internet through the router. If the router has been compromised, it could interfere with the CRL check. Should performance of the CRL check be disrupted or should the check fail, the node SHOULD immediately stop using the router as a default and use another router on the link instead. Comments? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 2 18:01:43 2004 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 SAA20240 for ; Mon, 2 Feb 2004 18:01:43 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i12N1iqY004136 for ; Tue, 3 Feb 2004 00:01:44 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 00:01:43 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1CVTYRAJ; Tue, 3 Feb 2004 00:01:43 +0100 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 i12N1Rwg024032; Tue, 3 Feb 2004 00:01:27 +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 i12N0dIt002975; Tue, 3 Feb 2004 00:00:39 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i12N0d1m002972; Tue, 3 Feb 2004 00:00:39 +0100 (MET) 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 i12N0bIt002947 for ; Tue, 3 Feb 2004 00:00:37 +0100 (MET) Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGVGY8>; Mon, 2 Feb 2004 18:00:37 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F0420F6@ftmail.lab.flarion.com> From: Soliman Hesham To: "'James Kempf'" , ietf-send@standards.ericsson.net Subject: RE: Last Call Issue: Deprecating RFC 2461 Security Date: Mon, 2 Feb 2004 18:00:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 02 Feb 2004 23:01:43.0797 (UTC) FILETIME=[86AD8250:01C3E9E0] > RFC 2461 Section 11 specifies using IPsec AH for Neighbor Discovery > security. But, as described in the ND options draft, this > will only work > with manual keying and then the number of SAs may become > large on links with > many nodes. Therefore, I'd like to suggest inclusion of a section in > draft-ietf-send-ndopts that specifically deprecates Section > 11 of RFC 2461. > In Minneapolis, I asked Steve Bellovin about this and he mentioned he > thought it would be OK. Here is the text I would like to suggest: > > 10.0 Deprecation of RFC 2461 Security > > Section 11 of RFC 2461 [7] specifies that IPsec AH should be used for > Neighbor Discovery security. However, as described in [21], > IPsec can only > be used if keys are configured manually, and even then, the number of > security associations generated can become large if many > nodes are on the > link. Therefore, Section 11 of RFC 2461 is deprecated as soon as this > specification is approved as a proposed standard. > > Comments? => What does "deprecated" mean here ? If someone has a link with two nodes on it and decides to use IPsec to secure ND on this link is s/he doing something wrong? 2461 is going to be obsolete anyway by a new RFC so I don't know how valuable this section would be. Hesham > > jak > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > > This communication is confidential and intended solely for > the addressee(s). Any unauthorized review, use, disclosure > or distribution is prohibited. If you believe this message > has been sent to you in error, please notify the sender by > replying to this transmission and delete the message without > disclosing it. Thank you. > > E-mail including attachments is susceptible to data > corruption, interruption, unauthorized amendment, tampering > and viruses, and we only send and receive e-mails on the > basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any > consequences thereof. > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 3 00:46:44 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09501 for ; Tue, 3 Feb 2004 00:46:43 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i135kjAh014523 for ; Tue, 3 Feb 2004 06:46:45 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 06:46:46 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1AZAGG4H; Tue, 3 Feb 2004 06:46:45 +0100 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 i135kYwg008532; Tue, 3 Feb 2004 06:46:34 +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 i135joIt003387; Tue, 3 Feb 2004 06:45:50 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i135jo1i003381; Tue, 3 Feb 2004 06:45:50 +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 i135jmIt003366 for ; Tue, 3 Feb 2004 06:45:49 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep02-app.kolumbus.fi with ESMTP id <20040203054548.FGQA1464.fep02-app.kolumbus.fi@kolumbus.fi>; Tue, 3 Feb 2004 07:45:48 +0200 Message-ID: <401F352E.1040603@kolumbus.fi> Date: Tue, 03 Feb 2004 07:44:14 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham , "'James Kempf'" CC: ietf-send@standards.ericsson.net Subject: Re: Last Call Issue: Deprecating RFC 2461 Security References: <9E3BA3946476AD4EB94672712B12A85F0420F6@ftmail.lab.flarion.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F0420F6@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 03 Feb 2004 05:46:46.0586 (UTC) FILETIME=[1C44D1A0:01C3EA19] Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > RFC 2461 Section 11 specifies using IPsec AH for Neighbor Discovery > > security. But, as described in the ND options draft, this > > will only work > > with manual keying and then the number of SAs may become > > large on links with > > many nodes. Therefore, I'd like to suggest inclusion of a section in > > draft-ietf-send-ndopts that specifically deprecates Section > > 11 of RFC 2461. > > In Minneapolis, I asked Steve Bellovin about this and he mentioned he > > thought it would be OK. Here is the text I would like to suggest: > > > > 10.0 Deprecation of RFC 2461 Security > > > > Section 11 of RFC 2461 [7] specifies that IPsec AH should be used for > > Neighbor Discovery security. However, as described in [21], > > IPsec can only > > be used if keys are configured manually, and even then, the number of > > security associations generated can become large if many > > nodes are on the > > link. Therefore, Section 11 of RFC 2461 is deprecated as soon as this > > specification is approved as a proposed standard. > > > > Comments? > > => What does "deprecated" mean here ? If someone has a link > with two nodes on it and decides to use IPsec to secure > ND on this link is s/he doing something wrong? > 2461 is going to be obsolete anyway by a new RFC so I don't > know how valuable this section would be. The easiest option for us is to do nothing. Then we don't need to ask permission from IPv6 WG, no one will get upset that we are "changing" IPv6 etc. However, I believe the honest thing to do is to admit that RFC 2461 has some significant limitations. Of course, we already describe some of this in our document. The question is perhaps whether this is sufficient or whether we need to make it more explicit. And if we do something about the IPsec parts, do we rip it out completely, constrain it to manual keying, or just warn about its limitations? And where do we do it, in 2461bis, the send protocol document, or in a separate document? I do not feel strongly about this, but my preference would be to do this as follows: - Leave send document as it is. It already mentions the limitations. - When updating 2461, demote the current IPsec model by . Removing the keywords . Moving it to an appendix . Deleting strong claims, such as "Confidentiality issues are addressed by the IP Security Architecture and ESP" or "The security associations may have been created through manual configuration or through the operation of some key management protocol." . Pointing to my old drafts (maybe published as RFCs) or other explanations describing the limitations in more detail. . Pointing to SEND as the current official security mechanism. This would still enable compliant use of the old mechanisms, but would give sufficient warning, at the right place, that some problems exist. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 3 00:53:47 2004 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 AAA09726 for ; Tue, 3 Feb 2004 00:53:47 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i135rnYG001199 for ; Tue, 3 Feb 2004 06:53:49 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 06:53:48 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1AZ5FF8A; Tue, 3 Feb 2004 06:54:12 +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 i135rkXA015597; Tue, 3 Feb 2004 06:53:46 +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 i135rOIt004961; Tue, 3 Feb 2004 06:53:24 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i135rOXt004960; Tue, 3 Feb 2004 06:53:24 +0100 (MET) 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 i135rMIt004956 for ; Tue, 3 Feb 2004 06:53:23 +0100 (MET) Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGV2HJ>; Tue, 3 Feb 2004 00:53:22 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F0420FB@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Jari Arkko'" , "'James Kempf'" Cc: ietf-send@standards.ericsson.net Subject: RE: Last Call Issue: Deprecating RFC 2461 Security Date: Tue, 3 Feb 2004 00:53:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 03 Feb 2004 05:53:48.0264 (UTC) FILETIME=[179BC680:01C3EA1A] Jari, That's exactly what I think we should do. Thanks, Hesham > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Tuesday, February 03, 2004 12:44 AM > To: Soliman Hesham; 'James Kempf' > Cc: ietf-send@standards.ericsson.net > Subject: Re: Last Call Issue: Deprecating RFC 2461 Security > > > Soliman Hesham wrote: > > > RFC 2461 Section 11 specifies using IPsec AH for > Neighbor Discovery > > > security. But, as described in the ND options draft, this > > > will only work > > > with manual keying and then the number of SAs may become > > > large on links with > > > many nodes. Therefore, I'd like to suggest inclusion of > a section in > > > draft-ietf-send-ndopts that specifically deprecates Section > > > 11 of RFC 2461. > > > In Minneapolis, I asked Steve Bellovin about this and > he mentioned he > > > thought it would be OK. Here is the text I would like > to suggest: > > > > > > 10.0 Deprecation of RFC 2461 Security > > > > > > Section 11 of RFC 2461 [7] specifies that IPsec AH > should be used for > > > Neighbor Discovery security. However, as described in [21], > > > IPsec can only > > > be used if keys are configured manually, and even then, > the number of > > > security associations generated can become large if many > > > nodes are on the > > > link. Therefore, Section 11 of RFC 2461 is deprecated > as soon as this > > > specification is approved as a proposed standard. > > > > > > Comments? > > > > => What does "deprecated" mean here ? If someone has a link > > with two nodes on it and decides to use IPsec to secure > > ND on this link is s/he doing something wrong? > > 2461 is going to be obsolete anyway by a new RFC so I don't > > know how valuable this section would be. > > The easiest option for us is to do nothing. Then we don't need to > ask permission from IPv6 WG, no one will get upset that we are > "changing" IPv6 etc. However, I believe the honest thing to do > is to admit that RFC 2461 has some significant limitations. Of > course, we already describe some of this in our document. The > question is perhaps whether this is sufficient or whether we need > to make it more explicit. And if we do something about the IPsec > parts, do we rip it out completely, constrain it to manual keying, > or just warn about its limitations? And where do we do it, in > 2461bis, the send protocol document, or in a separate document? > > I do not feel strongly about this, but my preference would be > to do this as follows: > > - Leave send document as it is. It already mentions the > limitations. > - When updating 2461, demote the current IPsec model by > . Removing the keywords > . Moving it to an appendix > . Deleting strong claims, such as "Confidentiality issues > are addressed by the IP Security Architecture and ESP" > or "The security associations may have been created through > manual configuration or through the operation of some > key management protocol." > . Pointing to my old drafts (maybe published as RFCs) or > other explanations describing the limitations in more > detail. > . Pointing to SEND as the current official security > mechanism. > > This would still enable compliant use of the old mechanisms, > but would give sufficient warning, at the right place, that > some problems exist. > > --Jari > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 3 05:36:58 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01025 for ; Tue, 3 Feb 2004 05:36:57 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i13AavAh017896 for ; Tue, 3 Feb 2004 11:36:58 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 11:36:57 +0100 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 1CVT9HFS; Tue, 3 Feb 2004 11:36:57 +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 i13AauXA019490; Tue, 3 Feb 2004 11:36:56 +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 i13AZtIt021503; Tue, 3 Feb 2004 11:35:55 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i13AZtai021502; Tue, 3 Feb 2004 11:35:55 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i13AZsIt021498 for ; Tue, 3 Feb 2004 11:35:54 +0100 (MET) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 11:35:46 +0100 Received: from pdico ([10.193.165.17]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 11:35:45 +0100 From: "Jean-Michel COMBES" To: "Soliman Hesham" , "'James Kempf'" , Subject: RE: Last Call Issue: Deprecating RFC 2461 Security Date: Tue, 3 Feb 2004 11:37:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F0420F6@ftmail.lab.flarion.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 03 Feb 2004 10:35:45.0130 (UTC) FILETIME=[7AD8ACA0:01C3EA41] 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 i13AauXA019490 Content-Transfer-Encoding: quoted-printable Hi, I agree with Hesham regarding the use of IPsec : if someone wants to use IPsec, let's him to use it (why to deprecate something that works ?) Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > -----Message d'origine----- > De : owner-ietf-send@standards.ericsson.net > [mailto:owner-ietf-send@standards.ericsson.net]De la part de Soliman > Hesham > Envoy=E9 : mardi 3 f=E9vrier 2004 00:01 > =C0 : 'James Kempf'; ietf-send@standards.ericsson.net > Objet : RE: Last Call Issue: Deprecating RFC 2461 Security > > > > > RFC 2461 Section 11 specifies using IPsec AH for Neighbor Discovery > > security. But, as described in the ND options draft, this > > will only work > > with manual keying and then the number of SAs may become > > large on links with > > many nodes. Therefore, I'd like to suggest inclusion of a section in= > > draft-ietf-send-ndopts that specifically deprecates Section > > 11 of RFC 2461. > > In Minneapolis, I asked Steve Bellovin about this and he mentioned h= e > > thought it would be OK. Here is the text I would like to suggest: > > > > 10.0 Deprecation of RFC 2461 Security > > > > Section 11 of RFC 2461 [7] specifies that IPsec AH should be used fo= r > > Neighbor Discovery security. However, as described in [21], > > IPsec can only > > be used if keys are configured manually, and even then, the number o= f > > security associations generated can become large if many > > nodes are on the > > link. Therefore, Section 11 of RFC 2461 is deprecated as soon as thi= s > > specification is approved as a proposed standard. > > > > Comments? > > =3D> What does "deprecated" mean here ? If someone has a link > with two nodes on it and decides to use IPsec to secure > ND on this link is s/he doing something wrong? > 2461 is going to be obsolete anyway by a new RFC so I don't > know how valuable this section would be. > > Hesham > > > > > > jak > > > > --------------------------------------------------------------------= > > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > > body to . > > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html= > > --------------------------------------------------------------------= > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure > > or distribution is prohibited. If you believe this message > > has been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank y= ou. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. From jari.arkko@lmf.ericsson.se Tue Feb 3 05:39:38 2004 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 FAA01245 for ; Tue, 3 Feb 2004 05:39:37 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i13AdcYG007215 for ; Tue, 3 Feb 2004 11:39:38 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 11:39:37 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1A6JBVN8; Tue, 3 Feb 2004 11:39:45 +0100 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 i13AdYwg020073; Tue, 3 Feb 2004 11:39:34 +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 i13AdPIt022208; Tue, 3 Feb 2004 11:39:25 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i13AdPGB022203; Tue, 3 Feb 2004 11:39:25 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i13AdNIt022198 for ; Tue, 3 Feb 2004 11:39:24 +0100 (MET) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 11:39:21 +0100 Received: from pdico ([10.193.165.17]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 11:39:20 +0100 From: "Jean-Michel COMBES" To: "Jari Arkko" , "Soliman Hesham" , "'James Kempf'" Cc: Subject: RE: Last Call Issue: Deprecating RFC 2461 Security Date: Tue, 3 Feb 2004 11:41:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <401F352E.1040603@kolumbus.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 03 Feb 2004 10:39:20.0886 (UTC) FILETIME=[FB726D60:01C3EA41] Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > -----Message d'origine----- > De : owner-ietf-send@standards.ericsson.net > [mailto:owner-ietf-send@standards.ericsson.net]De la part de Jari Arkko > Envoye : mardi 3 fevrier 2004 06:44 > A : Soliman Hesham; 'James Kempf' > Cc : ietf-send@standards.ericsson.net > Objet : Re: Last Call Issue: Deprecating RFC 2461 Security > > > Soliman Hesham wrote: > > > RFC 2461 Section 11 specifies using IPsec AH for Neighbor Discovery > > > security. But, as described in the ND options draft, this > > > will only work > > > with manual keying and then the number of SAs may become > > > large on links with > > > many nodes. Therefore, I'd like to suggest inclusion of a section in > > > draft-ietf-send-ndopts that specifically deprecates Section > > > 11 of RFC 2461. > > > In Minneapolis, I asked Steve Bellovin about this and he mentioned he > > > thought it would be OK. Here is the text I would like to suggest: > > > > > > 10.0 Deprecation of RFC 2461 Security > > > > > > Section 11 of RFC 2461 [7] specifies that IPsec AH should be used for > > > Neighbor Discovery security. However, as described in [21], > > > IPsec can only > > > be used if keys are configured manually, and even then, the number of > > > security associations generated can become large if many > > > nodes are on the > > > link. Therefore, Section 11 of RFC 2461 is deprecated as soon as this > > > specification is approved as a proposed standard. > > > > > > Comments? > > > > => What does "deprecated" mean here ? If someone has a link > > with two nodes on it and decides to use IPsec to secure > > ND on this link is s/he doing something wrong? > > 2461 is going to be obsolete anyway by a new RFC so I don't > > know how valuable this section would be. > > The easiest option for us is to do nothing. Then we don't need to > ask permission from IPv6 WG, no one will get upset that we are > "changing" IPv6 etc. However, I believe the honest thing to do > is to admit that RFC 2461 has some significant limitations. Of > course, we already describe some of this in our document. The > question is perhaps whether this is sufficient or whether we need > to make it more explicit. And if we do something about the IPsec > parts, do we rip it out completely, constrain it to manual keying, > or just warn about its limitations? And where do we do it, in > 2461bis, the send protocol document, or in a separate document? > > I do not feel strongly about this, but my preference would be > to do this as follows: > > - Leave send document as it is. It already mentions the > limitations. Agree > - When updating 2461, demote the current IPsec model by > . Removing the keywords > . Moving it to an appendix > . Deleting strong claims, such as "Confidentiality issues > are addressed by the IP Security Architecture and ESP" > or "The security associations may have been created through > manual configuration or through the operation of some > key management protocol." > . Pointing to my old drafts (maybe published as RFCs) or > other explanations describing the limitations in more > detail. > . Pointing to SEND as the current official security > mechanism. Agree > > This would still enable compliant use of the old mechanisms, > but would give sufficient warning, at the right place, that > some problems exist. Fine. > > --Jari JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 3 06:08:14 2004 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 GAA02867 for ; Tue, 3 Feb 2004 06:08:14 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i13B8FYG014129 for ; Tue, 3 Feb 2004 12:08:15 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 12:08:14 +0100 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 1A6JB0G4; Tue, 3 Feb 2004 12:08:21 +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 i13B8DXA019975; Tue, 3 Feb 2004 12:08:13 +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 i13B7bIt029842; Tue, 3 Feb 2004 12:07:37 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i13B7b4o029838; Tue, 3 Feb 2004 12:07:37 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep22-app.kolumbus.fi (fep22-0.kolumbus.fi [193.229.0.60]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i13B7aIt029820 for ; Tue, 3 Feb 2004 12:07:36 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.108]) by fep22-app.kolumbus.fi with ESMTP id <20040203110736.XAXO3524.fep22-app.kolumbus.fi@mta.imail.kolumbus.fi>; Tue, 3 Feb 2004 13:07:36 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: Last Call Issue: CRL Check on DCA Certs Date: Tue, 3 Feb 2004 13:07:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040203110736.XAXO3524.fep22-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 03 Feb 2004 11:08:14.0520 (UTC) FILETIME=[04C5FB80:01C3EA46] Content-Transfer-Encoding: 7bit Your proposal works for me. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 3 11:29:29 2004 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 LAA16647 for ; Tue, 3 Feb 2004 11:29:28 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i13GTSqY025100 for ; Tue, 3 Feb 2004 17:29:28 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 17:29:27 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1CV4CFW5; Tue, 3 Feb 2004 17:29:27 +0100 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 i13GTKwg011421; Tue, 3 Feb 2004 17:29:20 +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 i13GSVIt026498; Tue, 3 Feb 2004 17:28:31 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i13GSUUr026497; Tue, 3 Feb 2004 17:28:30 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i13GSSIt026481 for ; Tue, 3 Feb 2004 17:28:29 +0100 (MET) Message-ID: <004a01c3ea72$d10fa2a0$936015ac@dclkempt40> From: "James Kempf" To: "Soliman Hesham" , References: <9E3BA3946476AD4EB94672712B12A85F0420F6@ftmail.lab.flarion.com> Subject: Re: Last Call Issue: Deprecating RFC 2461 Security Date: Tue, 3 Feb 2004 08:28:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 03 Feb 2004 16:29:27.0950 (UTC) FILETIME=[E4A202E0:01C3EA72] Content-Transfer-Encoding: 7bit > => What does "deprecated" mean here ? If someone has a link > with two nodes on it and decides to use IPsec to secure > ND on this link is s/he doing something wrong? Not wrong, it just won't work very well. That is what ref. 21 describes. > 2461 is going to be obsolete anyway by a new RFC so I don't > know how valuable this section would be. > Are you planning on rewriting Section 11? And what is the timeline for the rewrite? It may not matter if the new version comes out within a year or so. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 3 11:59:37 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18119 for ; Tue, 3 Feb 2004 11:59:37 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i13GxcAh023207 for ; Tue, 3 Feb 2004 17:59:38 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 17:59:38 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1A6JFZAL; Tue, 3 Feb 2004 17:59:46 +0100 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 i13GxYwg013270; Tue, 3 Feb 2004 17:59:34 +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 i13GwnIt004667; Tue, 3 Feb 2004 17:58:49 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i13GwnYq004666; Tue, 3 Feb 2004 17:58:49 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i13GwlIt004649 for ; Tue, 3 Feb 2004 17:58:48 +0100 (MET) Message-ID: <012c01c3ea77$0affcd10$936015ac@dclkempt40> From: "James Kempf" To: "Jari Arkko" , "Soliman Hesham" Cc: References: <9E3BA3946476AD4EB94672712B12A85F0420F6@ftmail.lab.flarion.com> <401F352E.1040603@kolumbus.fi> Subject: Re: Last Call Issue: Deprecating RFC 2461 Security Date: Tue, 3 Feb 2004 08:59:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 03 Feb 2004 16:59:38.0088 (UTC) FILETIME=[1B8F2680:01C3EA77] Content-Transfer-Encoding: 7bit Jari, This sounds like a good plan. I think we should publish your draft about limitations on IPsec security for ND. Since we are trying to wind down the WG, I'd suggest publishing it as an individual submission, with the WG chairs recommending it. But it might be a good idea to solicit someone with IPsec experience to do a review. jak ----- Original Message ----- From: "Jari Arkko" To: "Soliman Hesham" ; "'James Kempf'" Cc: Sent: Monday, February 02, 2004 9:44 PM Subject: Re: Last Call Issue: Deprecating RFC 2461 Security > Soliman Hesham wrote: > > > RFC 2461 Section 11 specifies using IPsec AH for Neighbor Discovery > > > security. But, as described in the ND options draft, this > > > will only work > > > with manual keying and then the number of SAs may become > > > large on links with > > > many nodes. Therefore, I'd like to suggest inclusion of a section in > > > draft-ietf-send-ndopts that specifically deprecates Section > > > 11 of RFC 2461. > > > In Minneapolis, I asked Steve Bellovin about this and he mentioned he > > > thought it would be OK. Here is the text I would like to suggest: > > > > > > 10.0 Deprecation of RFC 2461 Security > > > > > > Section 11 of RFC 2461 [7] specifies that IPsec AH should be used for > > > Neighbor Discovery security. However, as described in [21], > > > IPsec can only > > > be used if keys are configured manually, and even then, the number of > > > security associations generated can become large if many > > > nodes are on the > > > link. Therefore, Section 11 of RFC 2461 is deprecated as soon as this > > > specification is approved as a proposed standard. > > > > > > Comments? > > > > => What does "deprecated" mean here ? If someone has a link > > with two nodes on it and decides to use IPsec to secure > > ND on this link is s/he doing something wrong? > > 2461 is going to be obsolete anyway by a new RFC so I don't > > know how valuable this section would be. > > The easiest option for us is to do nothing. Then we don't need to > ask permission from IPv6 WG, no one will get upset that we are > "changing" IPv6 etc. However, I believe the honest thing to do > is to admit that RFC 2461 has some significant limitations. Of > course, we already describe some of this in our document. The > question is perhaps whether this is sufficient or whether we need > to make it more explicit. And if we do something about the IPsec > parts, do we rip it out completely, constrain it to manual keying, > or just warn about its limitations? And where do we do it, in > 2461bis, the send protocol document, or in a separate document? > > I do not feel strongly about this, but my preference would be > to do this as follows: > > - Leave send document as it is. It already mentions the > limitations. > - When updating 2461, demote the current IPsec model by > . Removing the keywords > . Moving it to an appendix > . Deleting strong claims, such as "Confidentiality issues > are addressed by the IP Security Architecture and ESP" > or "The security associations may have been created through > manual configuration or through the operation of some > key management protocol." > . Pointing to my old drafts (maybe published as RFCs) or > other explanations describing the limitations in more > detail. > . Pointing to SEND as the current official security > mechanism. > > This would still enable compliant use of the old mechanisms, > but would give sufficient warning, at the right place, that > some problems exist. > > --Jari > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 3 12:08:33 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18725 for ; Tue, 3 Feb 2004 12:08:33 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i13H8YAh025068 for ; Tue, 3 Feb 2004 18:08:34 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 18:08:34 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1AZANNWT; Tue, 3 Feb 2004 18:08:34 +0100 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 i13H8Xwg013861; Tue, 3 Feb 2004 18:08:33 +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 i13H8LIt007640; Tue, 3 Feb 2004 18:08:21 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i13H8L8G007639; Tue, 3 Feb 2004 18:08:21 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i13H8KIt007630 for ; Tue, 3 Feb 2004 18:08:20 +0100 (MET) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 18:08:18 +0100 Received: from pdico ([10.193.165.17]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 18:08:18 +0100 From: "Jean-Michel COMBES" To: Subject: RE: Last Call Issue: Deprecating RFC 2461 Security Date: Tue, 3 Feb 2004 18:10:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 03 Feb 2004 17:08:18.0007 (UTC) FILETIME=[51747E70:01C3EA78] 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 i13H8Xwg013861 Content-Transfer-Encoding: quoted-printable Lost in the Internet 'space' ... (sorry if you received this mail twice) France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > -----Message d'origine----- > De : Jean-Michel COMBES [mailto:jeanmichel.combes@francetelecom.com] > Envoy=E9 : mardi 3 f=E9vrier 2004 11:38 > =C0 : Soliman Hesham; 'James Kempf'; ietf-send@standards.ericsson.net > Objet : RE: Last Call Issue: Deprecating RFC 2461 Security > > > Hi, > > I agree with Hesham regarding the use of IPsec : if someone wants > to use IPsec, let's him to use it (why to deprecate something > that works ?) > > Regards. > > JMC. > > France Telecom R&D - DTL/SSR > Jean-Michel COMBES, Internet/Intranet Security > E-Mail : jeanmichel.combes@francetelecom.com > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > > > -----Message d'origine----- > > De : owner-ietf-send@standards.ericsson.net > > [mailto:owner-ietf-send@standards.ericsson.net]De la part de Soliman > > Hesham > > Envoy=E9 : mardi 3 f=E9vrier 2004 00:01 > > =C0 : 'James Kempf'; ietf-send@standards.ericsson.net > > Objet : RE: Last Call Issue: Deprecating RFC 2461 Security > > > > > > > > > RFC 2461 Section 11 specifies using IPsec AH for Neighbor Discover= y > > > security. But, as described in the ND options draft, this > > > will only work > > > with manual keying and then the number of SAs may become > > > large on links with > > > many nodes. Therefore, I'd like to suggest inclusion of a section = in > > > draft-ietf-send-ndopts that specifically deprecates Section > > > 11 of RFC 2461. > > > In Minneapolis, I asked Steve Bellovin about this and he mentioned= he > > > thought it would be OK. Here is the text I would like to suggest: > > > > > > 10.0 Deprecation of RFC 2461 Security > > > > > > Section 11 of RFC 2461 [7] specifies that IPsec AH should be used = for > > > Neighbor Discovery security. However, as described in [21], > > > IPsec can only > > > be used if keys are configured manually, and even then, the number= of > > > security associations generated can become large if many > > > nodes are on the > > > link. Therefore, Section 11 of RFC 2461 is deprecated as soon as t= his > > > specification is approved as a proposed standard. > > > > > > Comments? > > > > =3D> What does "deprecated" mean here ? If someone has a link > > with two nodes on it and decides to use IPsec to secure > > ND on this link is s/he doing something wrong? > > 2461 is going to be obsolete anyway by a new RFC so I don't > > know how valuable this section would be. > > > > Hesham > > > > > > > > > > jak > > > > > > ------------------------------------------------------------------= -- > > > To unsubscribe from this list, send email with "UNSUBSCRIBE" in th= e > > > body to . > > > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.ht= ml > > > ------------------------------------------------------------------= -- > > > > > > This communication is confidential and intended solely for > > > the addressee(s). Any unauthorized review, use, disclosure > > > or distribution is prohibited. If you believe this message > > > has been sent to you in error, please notify the sender by > > > replying to this transmission and delete the message without > > > disclosing it. Thank you. > > > > > > E-mail including attachments is susceptible to data > > > corruption, interruption, unauthorized amendment, tampering > > > and viruses, and we only send and receive e-mails on the > > > basis that we are not liable for any such corruption, > > > interception, amendment, tampering or viruses or any > > > consequences thereof. > > > > > -------------------------------------------------------------------- > > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > > body to . > > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > > -------------------------------------------------------------------- > > > > This communication is confidential and intended solely for the > > addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has been > > sent to you in error, please notify the sender by replying to > > this transmission and delete the message without disclosing it. > Thank you. > > > > E-mail including attachments is susceptible to data corruption, > > interruption, unauthorized amendment, tampering and viruses, and > > we only send and receive e-mails on the basis that we are not > > liable for any such corruption, interception, amendment, > > tampering or viruses or any consequences thereof. > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. From jari.arkko@lmf.ericsson.se Tue Feb 3 12:43:50 2004 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 MAA20716 for ; Tue, 3 Feb 2004 12:43:50 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i13HhpqY010493 for ; Tue, 3 Feb 2004 18:43:51 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 18:43:50 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1CV4DAT8; Tue, 3 Feb 2004 18:43:50 +0100 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 i13Hhbwg015874; Tue, 3 Feb 2004 18:43:37 +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 i13Hh0It016597; Tue, 3 Feb 2004 18:43:00 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i13Hh0uY016596; Tue, 3 Feb 2004 18:43:00 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i13HgvIt016591 for ; Tue, 3 Feb 2004 18:42:58 +0100 (MET) Message-ID: <02bb01c3ea7d$31545d90$936015ac@dclkempt40> From: "James Kempf" To: "Pekka Savola" , Cc: References: Subject: Re: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard Date: Tue, 3 Feb 2004 09:43:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 03 Feb 2004 17:43:50.0468 (UTC) FILETIME=[48803840:01C3EA7D] Content-Transfer-Encoding: 7bit Hi Pekka, Thanx for your comments. I'll forward them to Tuomas Aurea, the draft editor for processing. W.r.t. the timing, as usual, early review is better than later. The SEND WG is currently in Last Call on the document draft-ietf-send-ndopts-03.txt, expiring on Monday Feb. 9. Could you take a look at that draft and submit comments (hopefully as detailed as those below) to the WG list prior to expiration of Last Call, so we can incorporate them into the document before sending it to the IESG? jak ----- Original Message ----- From: "Pekka Savola" To: Cc: Sent: Sunday, February 01, 2004 11:51 PM Subject: Re: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard > On Mon, 19 Jan 2004, The IESG wrote: > > - 'Cryptographically Generated Addresses (CGA) ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-02. > > This is basically a very good document, but seems to call for a bit > more clarity in certain places. > > That is, the sections up to 5 aren't sufficiently clear, IMHO, that > using CGA itself gives you nothing (security considerations is OK > though). Anyone possessing the public key can generate the CGA, so > that in itself provides no ownership. Ownership can only be proven > through other protocols, or by applying the private key in a > signature. > > This should require some rewording, e.g.: > > In order to verify the association between the address and the public > key, the verifier needs to know the address itself, the public key, > and the values of the auxiliary parameters. No additional security > infrastructure, such as a public key infrastructure (PKI), > certification authorities, or other trusted servers, is needed. > > ==> add something like, modified from the security considerations: > > Note that an attacker can create a new address from an arbitrary > subnet prefix and its own (or anyone else's) public key because > CGAs themselves are not certified -- and unless a message has been > specifically signed, connection to the real owner of the public key > can't be verified. That is, the attacker cannot impersonate > somebody else's address when a message is being signed using the > private key related to the public key used to generate the CGA. > > There are other places in the first sections where this could be made > clearer. On their own, CGAs prove nothing. It's only with when the > private key is applied than some guarantees can be obtained. > > Another thing which I don't think has been discussed sufficiently is > the CPU resource exhaustion attacks. Are there ways using which the > nodes might be forced to perform heavy signature or CGA verification > steps (e.g., flood with a lot of CGA addresses, where the parameters > etc. were trivially calculated)? Luckily enough, you can't force the > receivers to perform heavy hash2 computation (i.e., sec > 0) unless > you first break sec=0. > > A few more specific comments below. > > substantial > ----------- > > 3. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are > all zero (or if Sec=0), continue with step (4). Otherwise, > increment the modifier and go back to step (2). > > ==> the modifier is a random number. Do you increment it by *one* > (not specified but implicit I guess) or re-randomize it? If not > re-randomize, why not? > > 6. Concatenate from left to right the modifier, 9 zero octets, and > the public key. Execute the SHA-1 algorithm on the concatenation. > Take the 112 leftmost bits of the SHA-1 hash value. The result is > Hash2. > > 7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one > of them is non-zero, the CGA verification fails. Otherwise, the > verification succeeds. (If Sec=0, the CGA verification never > fails at this step.) > > ==> so, 7. seems to say that for the verification to succeed, > the hash2 value must be zero. Looking again at the generation of > hash values (rules 2. and 3.) it seems that for e.g. sec=3, you'd > probably have to generate the hash function billions of times, until > the first 48 bits are all zeros. What kind of hash computation is > that?!?! What's the point? Shouldn't you just generate the hash, > and when verifying it, check that it's equal? (now it checks that it's > zero)? > > If this kind of very heavy computation is intended, it should be > spelled out explicitly I think. > > If the verification succeeds, the verifier knows that the public key > in the CGA Parameters is the authentic public key of the address > owner. > > ==> this is an inaccurate statement. This verification gives you > nothing except the knowledge that the CGA address has been generated > using a public key -- anyone with the public key can do it. So, > "authentic public key of the address owner" seems to give a hint > about the use of private address, and this is only OK after the > verifying a signature. > > Note that the values of bits 6 and 7 (the "u" and "g" bits) of the > interface identifier are ignored during CGA verification. After the > verification succeeds, the verifier SHOULD process all CGAs in the > same way regardless of the Sec, modifier and collision count values. > In particular, the verifier SHOULD NOT have any security policy that > differentiates between addresses based on the value of Sec. That way, > the address generator is free choose any value of Sec. > > ==> I find it difficult to justify this SHOULD NOT. I feel it's > totally wrong for this document to state that you SHOULD not > differentiate between the different strengths of an address > (e.g., if a site considers sec=0 too light, it could only treat > sec >= 1 as being "good"). This seems to be something we should > not disallow. This would seem to be similar to saying that one SHOULD > not differentiate security policies whether e.g. a single DES or 3DES > was being used. > > For each valid CGA Parameters data structure, there are 4*(Sec+1) > different CGAs that match the value. This is because decrementing the > Sec value in the three leftmost bits of the interface identifier does > not invalidate the address, > > ==> s/decrementing/changing (typically decrementing)/ -- you can up the > sec as well, even though for an attacker that's probably not lucrative -- > unless maybe if CPU resource exhaustion is the goal. > > Intellectual Property Statement > > ==> this doesn't include the note that the IETF has been notified > of some claims. This is a must. > > editorial > --------- > > Discovery (SEND) protocol [I-D.ietf-send-ndopt]. The basic idea is to > > ==> could one use some other identifier for the drafts..? > > > A cryptographically generated address is an IPv6 address for which > the following two equations hold: > > Hash1 & Mask2 == interface identifier & Mask2 > Hash2 & Mask1 == 0x0000000000000000000000000000 > > ==> any reason why you wouldn't defined Mask2 and Mask1 the > other way, then they would be associated with the hashes of the > same number? > > address (e.g., as an RFC-3041 address [RFC3041]). An attacker does > > ==> s/RFC-/RFC / > > multiple pseudorandom CGAs by executing the CGA generation algorithm > of Section 4 multiple times and by using a different random or > pseudorandom initial value for the modifier every time. The host > > ==> s/by using/using/ > > This document defines a new CGA Message Type name space for use as > type tags in messages may be signed using CGA signatures. > > ==> s/may/that may/ ? > > The new values SHOULD be generated by the requester with a strong > random-number generator. > > ==> reword to: > > The requester SHOULD generated the new values with a strong > random-number generator. > > Michael Roe, Dave Thaler, and several other participants of the IETF > working group. > > ==> s/IETF/SEND/ ? > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 3 23:02:38 2004 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 XAA20712 for ; Tue, 3 Feb 2004 23:02:37 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1442XYG005657 for ; Wed, 4 Feb 2004 05:02:38 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Feb 2004 05:02:32 +0100 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 1AZAS187; Wed, 4 Feb 2004 05:02:32 +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 i1442VXA000842; Wed, 4 Feb 2004 05:02:31 +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 i1441mIt013466; Wed, 4 Feb 2004 05:01:49 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1441mTn013465; Wed, 4 Feb 2004 05:01:48 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1441kIt013461 for ; Wed, 4 Feb 2004 05:01:47 +0100 (MET) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 3 Feb 2004 20:01:42 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Feb 2004 19:46:03 -0800 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); Tue, 3 Feb 2004 19:45:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard Date: Tue, 3 Feb 2004 19:46:01 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457011A5CFE@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard Thread-Index: AcPpYiqG1pJjKgehTeySRiDhIhTTbQBX0f+Q From: "Tuomas Aura" To: "Pekka Savola" , "James Kempf" Cc: , "Pekka Nikander" , , X-OriginalArrivalTime: 04 Feb 2004 03:45:59.0456 (UTC) FILETIME=[670E4A00:01C3EAD1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i1441mIt013462 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Pekka, thank you for your careful review of the draft. I'll submit a new version on Wednesday next week if there are no further changes. > That is, the sections up to 5 aren't sufficiently clear, IMHO, that > using CGA itself gives you nothing (security considerations is OK > though). Anyone possessing the public key can generate the CGA, so > that in itself provides no ownership. Ownership can only be proven > through other protocols, or by applying the private key in a > signature. In the spirit of your proposed additions, the intro now has the following wording: "In order to verify the association between the address and the public key, the verifier needs to know the address itself, the public key, and the values of the auxiliary parameters. The verifier can then go on to verify messages signed by the owner of the public key (i.e., the address owner). No additional security infrastructure, such as a public key infrastructure (PKI), certification authorities, or other trusted servers, is needed. It is important to note that because CGAs themselves are not certified, an attacker can create a new CGA from any subnet prefix and its own (or anyone else's) public key. What the attacker cannot do is to take a CGA created by someone else and send signed messages that appear to come from the owner of that address." > Another thing which I don't think has been discussed sufficiently is > the CPU resource exhaustion attacks. Are there ways using which the > nodes might be forced to perform heavy signature or CGA verification > steps (e.g., flood with a lot of CGA addresses, where the parameters > etc. were trivially calculated)? Luckily enough, you can't force the > receivers to perform heavy hash2 computation (i.e., sec > 0) unless > you first break sec=0. First, the address verification procedure described in this document is very light-weight. It takes two calculations of the SHA-1 hash function (or only one if Sec=0). Only the generation of a new CGA from a new public key requires the expensive brute-force search (and even then only if Sec>0). I'll return to this below as you seem to have misunderstood this bit. Second, the signature verification could be used for DoS attacks. That, however, is beyond the scope of this paper. Such attacks and defenses against them should be considered in the protocols (e.g., draft-ietf-send-ndopt) that use the signatures if the threat is considered significant for the particular protocol. > ==> the modifier is a random number. Do you increment it by *one* > (not specified but implicit I guess) or re-randomize it? If not > re-randomize, why not? Increment *by one*. I'll clarify this. Re-randomization has no security advantages compared to linear search from a random initial value. The generation of random values is also expensive and would slow down the linear search by orders of magnitude. Note that even if the honest address generator did re-randomize, the attacker could anyway use the faster linear search during a brute-force attack. > ==> so, 7. seems to say that for the verification to succeed, > the hash2 value must be zero. Looking again at the generation of > hash values (rules 2. and 3.) it seems that for e.g. sec=3, you'd > probably have to generate the hash function billions of times, until > the first 48 bits are all zeros. What kind of hash computation is > that?!?! What's the point? Shouldn't you just generate the hash, > and when verifying it, check that it's equal? (now it checks that it's > zero)? There is no loop in the verification algorithm. At most two hashes are computed. It seems the meaning of "verification fails" is not clear enough. It does not mean "loop back and try again". I have added the following clarification: "If the verification fails at any step, the execution of the algorithm MUST be stopped immediately." > If this kind of very heavy computation is intended, it should be > spelled out explicitly I think. It is not needed. I made a small change to the following sentence to clarify this even further: "The verification procedure is relatively fast and always requires at most two computations of the SHA-1 hash function." > If the verification succeeds, the verifier knows that the public key > in the CGA Parameters is the authentic public key of the address > owner. > > ==> this is an inaccurate statement. This verification gives you > nothing except the knowledge that the CGA address has been generated > using a public key -- anyone with the public key can do it. This depends on the definition of "address owner". The way the term is used in the draft, I can generate an address that you own (provided I know your public key). This is consistent with the fact that the expensive address generation procedure can be offloaded, e.g., to a fast server or to a bunch of volunteers. I'd rather not change this terminology as it is used consistently throughout the draft. However, if you think it is critical, I could change the text to: "If the verification succeeds, the verifier knows that it can use the public key to verify signatures on messages that the address owner sends from this address." Personally, I think it would be more cumbersome to read. > In particular, the verifier SHOULD NOT have any security policy that > differentiates between addresses based on the value of Sec. That way, > the address generator is free choose any value of Sec. > > ==> I find it difficult to justify this SHOULD NOT. I feel it's > totally wrong for this document to state that you SHOULD not > differentiate between the different strengths of an address > (e.g., if a site considers sec=0 too light, it could only treat > sec >= 1 as being "good"). This seems to be something we should > not disallow. This would seem to be similar to saying that one SHOULD > not differentiate security policies whether e.g. a single DES or 3DES > was being used. Continuing your analogy with DES/3DES, consider a situation where I send *my* secrets to you through the encrypted channel (but you don't send any secrets to me). In that case, *I* should decide how strong encryption my secrets require. Asking your opinion is unnecessary and causes an extra roundtrip of algorithm negotiation. Similarly, in SEND, higher Sec values give the address owner better protection against DoS attacks. The Sec value that I use for generating *my* address does not affect your security. Thus, asking your opinion about my Sec value is unnecessary and causes incompatibility between nodes that choose different Sec values. (The node with lower Sec could not generate a new address in real time to meet peer's requirement for a higher Sec.) Admittedly, if CGAs are used for authenticating a key exchange, the situation changes. But that is beyond the scope of the SEND WG. To make sure that there is no mistake, I added "in the SEND protocol" to the text: "In the SEND protocol, after the verification succeeds, the verifier SHOULD process all CGAs in the same way regardless of the Sec, modifier and collision count values. In particular, the verifier in the SEND protocol SHOULD NOT have any security policy that differentiates between addresses based on the value of Sec." > For each valid CGA Parameters data structure, there are 4*(Sec+1) > different CGAs that match the value. This is because decrementing the > Sec value in the three leftmost bits of the interface identifier does > not invalidate the address, > > ==> s/decrementing/changing (typically decrementing)/ -- you can up the > sec as well, even though for an attacker that's probably not lucrative -- > unless maybe if CPU resource exhaustion is the goal. No, this is not true. Assume that Sec=2 and Hash2 starts with (at least) 32 zero bits. The attacker can decrement Sec to Sec=1 because (the same) Hash2 certainly start with (at least) 16 zero bits. On the other hand, the attacker cannot increment Sec to Sec=3 because it is *very* unlikely that Hash2 would start with 48 zero bits. > ==> this doesn't include the note that the IETF has been notified > of some claims. This is a must. The statement is currently whatever xml2rfc puts there. If I remember correctly, I was told by lawyers that the IPR statements are filed separately and there is no need to include anything in the draft. But I may be wrong. This is not the type of thing I live for. Anyway, the RFC editor guidelines say: "An RFC should never itself contain an assertion of rights to technology." and not much else. If anyone knows what I should put into the draft, PLEASE let me know. Preferably in a format that is acceptable to xml2rfc. Editorial comments ok, except for the following: > address (e.g., as an RFC-3041 address [RFC3041]). An attacker does > ==> s/RFC-/RFC / Sorry, no. The hyphen is grammatically correct here. (For example, "RFC-3041 addresses are defined in RFC 3041.") Again, thank you for reading the draft so carefully. Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Feb 4 01:22:55 2004 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 BAA24387 for ; Wed, 4 Feb 2004 01:22:54 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i146MrYG020820 for ; Wed, 4 Feb 2004 07:22:54 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Feb 2004 07:22:53 +0100 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 1A6JLLT1; Wed, 4 Feb 2004 07:23:03 +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 i146MqXA001503; Wed, 4 Feb 2004 07:22:52 +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 i146MGIt022486; Wed, 4 Feb 2004 07:22:16 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i146MGOr022485; Wed, 4 Feb 2004 07:22:16 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i146MEIt022478 for ; Wed, 4 Feb 2004 07:22:14 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i146M6Z17311; Wed, 4 Feb 2004 08:22:06 +0200 Date: Wed, 4 Feb 2004 08:22:06 +0200 (EET) From: Pekka Savola To: Tuomas Aura cc: James Kempf , , Pekka Nikander , , Subject: RE: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard In-Reply-To: <64A531765B7C8342BFA260497BE00457011A5CFE@RED-MSG-43.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 04 Feb 2004 06:22:53.0068 (UTC) FILETIME=[52017CC0:01C3EAE7] On Tue, 3 Feb 2004, Tuomas Aura wrote: > > That is, the sections up to 5 aren't sufficiently clear, IMHO, that > > using CGA itself gives you nothing (security considerations is OK > > though). Anyone possessing the public key can generate the CGA, so > > that in itself provides no ownership. Ownership can only be proven > > through other protocols, or by applying the private key in a > > signature. > > In the spirit of your proposed additions, the intro now has the > following wording: > > "In order to verify the association between the address and the > public key, the verifier needs to know the address itself, the > public key, and the values of the auxiliary parameters. The > verifier can then go on to verify messages signed by the owner of > the public key (i.e., the address owner). No additional security > infrastructure, such as a public key infrastructure (PKI), > certification authorities, or other trusted servers, is needed. > > It is important to note that because CGAs themselves are not > certified, an attacker can create a new CGA from any subnet prefix > and its own (or anyone else's) public key. What the attacker cannot > do is to take a CGA created by someone else and send signed messages > that appear to come from the owner of that address." Good. > Second, the signature verification could be used for DoS attacks. > That, however, is beyond the scope of this paper. Such attacks and > defenses against them should be considered in the protocols (e.g., > draft-ietf-send-ndopt) that use the signatures if the threat is > considered significant for the particular protocol. True. A mention in security considerations (CGA check = easy, verification = more complex, but out of scope) section might not hurt, though. Further, I wonder if it's possible to force an implementation to heavy computation resulting from the generation of a new address, e.g., by a DAD attack. This doesn't seem to be the case, because the really expensive Hash2 is only computed once even if there were collisions. > > ==> the modifier is a random number. Do you increment it by *one* > > (not specified but implicit I guess) or re-randomize it? If not > > re-randomize, why not? > > Increment *by one*. I'll clarify this. Re-randomization has no > security advantages compared to linear search from a random initial > value. The generation of random values is also expensive and would > slow down the linear search by orders of magnitude. Note that even > if the honest address generator did re-randomize, the attacker could > anyway use the faster linear search during a brute-force attack. OK. (I think the term "increment" has been used elsewhere in the spec as well.) > > ==> so, 7. seems to say that for the verification to succeed, > > the hash2 value must be zero. Looking again at the generation of > > hash values (rules 2. and 3.) it seems that for e.g. sec=3, you'd > > probably have to generate the hash function billions of times, until > > the first 48 bits are all zeros. What kind of hash computation is > > that?!?! What's the point? Shouldn't you just generate the hash, > > and when verifying it, check that it's equal? (now it checks that it's > > zero)? > > There is no loop in the verification algorithm. At most two hashes > are computed. It seems the meaning of "verification fails" is not > clear enough. It does not mean "loop back and try again". I have added > the following clarification: "If the verification fails at any step, > the execution of the algorithm MUST be stopped immediately." OK. > > If this kind of very heavy computation is intended, it should be > > spelled out explicitly I think. > > It is not needed. I made a small change to the following sentence > to clarify this even further: > "The verification procedure is relatively fast and always requires > at most two computations of the SHA-1 hash function." This clarifies the verification part -- my comment also included (maybe a misunderstanding) about the generation process. For sec>1 you have to generate the hash, to look for all zeros, thousands, millions (or even more) times. That may be pretty bad. I didn't understand right out the purpose for this. Now it seems that the reason may be to optimize it for those that are checking CGA's. Maybe this needs a bit spelling out. > > If the verification succeeds, the verifier knows that the public > key > > in the CGA Parameters is the authentic public key of the address > > owner. > > > > ==> this is an inaccurate statement. This verification gives you > > nothing except the knowledge that the CGA address has been generated > > using a public key -- anyone with the public key can do it. > > This depends on the definition of "address owner". The way the term is > used in the draft, I can generate an address that you own (provided > I know your public key). This is consistent with the fact that the > expensive address generation procedure can be offloaded, e.g., to a > fast server or to a bunch of volunteers. I'd rather not change this > terminology as it is used consistently throughout the draft. > > However, if you think it is critical, I could change the text to: > "If the verification succeeds, the verifier knows that it can use the > public key to verify signatures on messages that the address owner > sends from this address." > Personally, I think it would be more cumbersome to read. OK, let's keep that as-is. With the clarification in Introduction, this is probably enough. > > In particular, the verifier SHOULD NOT have any security policy > that > > differentiates between addresses based on the value of Sec. That > way, > > the address generator is free choose any value of Sec. > > > > ==> I find it difficult to justify this SHOULD NOT. I feel it's > > totally wrong for this document to state that you SHOULD not > > differentiate between the different strengths of an address > > (e.g., if a site considers sec=0 too light, it could only treat > > sec >= 1 as being "good"). This seems to be something we should > > not disallow. This would seem to be similar to saying that one SHOULD > > not differentiate security policies whether e.g. a single DES or 3DES > > was being used. > > Continuing your analogy with DES/3DES, consider a situation where > I send *my* secrets to you through the encrypted channel (but you > don't send any secrets to me). In that case, *I* should decide how > strong encryption my secrets require. Asking your opinion is > unnecessary and causes an extra roundtrip of algorithm negotiation. OK, true. > Similarly, in SEND, higher Sec values give the address owner > better protection against DoS attacks. The Sec value that I use > for generating *my* address does not affect your security. Thus, > asking your opinion about my Sec value is unnecessary and > causes incompatibility between nodes that choose different Sec > values. (The node with lower Sec could not generate a new address > in real time to meet peer's requirement for a higher Sec.) > > Admittedly, if CGAs are used for authenticating a key exchange, > the situation changes. But that is beyond the scope of the SEND WG. > To make sure that there is no mistake, I added "in the SEND protocol" > to the text: > "In the SEND protocol, after the verification succeeds, > the verifier SHOULD process all CGAs in the same way regardless > of the Sec, modifier and collision count values. In particular, > the verifier in the SEND protocol SHOULD NOT have any security > policy that differentiates between addresses based on the > value of Sec." OK. > > For each valid CGA Parameters data structure, there are 4*(Sec+1) > > different CGAs that match the value. This is because decrementing > the > > Sec value in the three leftmost bits of the interface identifier > does > > not invalidate the address, > > > > ==> s/decrementing/changing (typically decrementing)/ -- you can > > up the sec as well, even though for an attacker that's probably > > not lucrative -- unless maybe if CPU resource exhaustion is the > > goal. > > No, this is not true. Assume that Sec=2 and Hash2 starts with (at > least) 32 zero bits. The attacker can decrement Sec to Sec=1 because > (the same) Hash2 certainly start with (at least) 16 zero bits. On > the other hand, the attacker cannot increment Sec to Sec=3 because > it is *very* unlikely that Hash2 would start with 48 zero bits. Ok, right. > > ==> this doesn't include the note that the IETF has been notified > > of some claims. This is a must. > > The statement is currently whatever xml2rfc puts there. If I remember > correctly, I was told by lawyers that the IPR statements are filed > separately and there is no need to include anything in the draft. > But I may be wrong. This is not the type of thing I live for. > Anyway, the RFC editor guidelines say: "An RFC should never itself > contain an assertion of rights to technology." and not much else. There must not be any specific claims on the document, but in case there is knowledge that some have already been made, there must be a note which says so (or that's my understanding): The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. > If anyone knows what I should put into the draft, PLEASE let me know. > Preferably in a format that is acceptable to xml2rfc. This can be achieved with adding up front: > Editorial comments ok, except for the following: > > address (e.g., as an RFC-3041 address [RFC3041]). An attacker does > > ==> s/RFC-/RFC / > > Sorry, no. The hyphen is grammatically correct here. (For example, > "RFC-3041 addresses are defined in RFC 3041.") OK. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Feb 5 10:00:30 2004 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 KAA17396 for ; Thu, 5 Feb 2004 10:00:29 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15F0SqY001588 for ; Thu, 5 Feb 2004 16:00:29 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 16:00:28 +0100 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 1LJR7KMS; Thu, 5 Feb 2004 16:00:41 +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 i15F0QXA017624; Thu, 5 Feb 2004 16:00:26 +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 i15Ew3It011827; Thu, 5 Feb 2004 15:58:03 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i15Ew3Nu011826; Thu, 5 Feb 2004 15:58:03 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i15Ew2It011822 for ; Thu, 5 Feb 2004 15:58:02 +0100 (MET) Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 032E71C; Thu, 5 Feb 2004 17:10:50 +0200 (EET) In-Reply-To: <000101c3e9a7$cbcdac90$936015ac@dclkempt40> References: <000101c3e9a7$cbcdac90$936015ac@dclkempt40> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: Last Call Issue: CRL Check on DCA Certs Date: Thu, 5 Feb 2004 16:58:00 +0200 To: "James Kempf" X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 05 Feb 2004 15:00:28.0395 (UTC) FILETIME=[CAD613B0:01C3EBF8] Content-Transfer-Encoding: 7bit James, > > I'd like to suggest the following text: > > When procesing the three certificates, the usual RFC 3280 > certificate path validation is performed. Note, however, that > at the time a node is checking certificates received in a > DCA from a router, it typically does not have a connection > to the Internet yet, and so it is not possible to perform an > on-line Certificate Revocation List (CRL) check if such a check > is necessary. Until such a check is performed, acceptance > of the certificate MUST be considered provisional, and the > node MUST perform a check as soon as it has established > a connection with the Internet through the router. If the router > has been compromised, it could interfere with the CRL check. > Should performance of the CRL check be disrupted or should > the check fail, the node SHOULD immediately stop using the > router as a default and use another router on the link instead. > > Comments? Looks good, other than I would write "the node SHOULD perform a check as soon as it has established...". In many cases hosts do not perform CRL checks today at all, and if they wouldn't do that anyway, the MUST will become empty. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Feb 5 12:20:28 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24845 for ; Thu, 5 Feb 2004 12:20:27 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15HKQAh016664 for ; Thu, 5 Feb 2004 18:20:26 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 18:20:26 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJR8QGL; Thu, 5 Feb 2004 18:20:40 +0100 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 i15HKJwg011984; Thu, 5 Feb 2004 18:20:19 +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 i15HI9It020339; Thu, 5 Feb 2004 18:18:09 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i15HI9NQ020338; Thu, 5 Feb 2004 18:18:09 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i15HI7It020334 for ; Thu, 5 Feb 2004 18:18:07 +0100 (MET) Message-ID: <01ca01c3ec0c$110fd9c0$936015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" Cc: References: <000101c3e9a7$cbcdac90$936015ac@dclkempt40> Subject: Re: Last Call Issue: CRL Check on DCA Certs Date: Thu, 5 Feb 2004 09:18:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 05 Feb 2004 17:20:26.0252 (UTC) FILETIME=[58595CC0:01C3EC0C] Content-Transfer-Encoding: 7bit Sounds fine. jak ----- Original Message ----- From: "Pekka Nikander" To: "James Kempf" Cc: Sent: Thursday, February 05, 2004 6:58 AM Subject: Re: Last Call Issue: CRL Check on DCA Certs > James, > > > > > I'd like to suggest the following text: > > > > When procesing the three certificates, the usual RFC 3280 > > certificate path validation is performed. Note, however, that > > at the time a node is checking certificates received in a > > DCA from a router, it typically does not have a connection > > to the Internet yet, and so it is not possible to perform an > > on-line Certificate Revocation List (CRL) check if such a check > > is necessary. Until such a check is performed, acceptance > > of the certificate MUST be considered provisional, and the > > node MUST perform a check as soon as it has established > > a connection with the Internet through the router. If the router > > has been compromised, it could interfere with the CRL check. > > Should performance of the CRL check be disrupted or should > > the check fail, the node SHOULD immediately stop using the > > router as a default and use another router on the link instead. > > > > Comments? > > Looks good, other than I would write "the node SHOULD perform a check > as soon as it has established...". In many cases hosts do not > perform CRL checks today at all, and if they wouldn't do that > anyway, the MUST will become empty. > > --Pekka > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Feb 5 20:45:10 2004 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 UAA22707 for ; Thu, 5 Feb 2004 20:45:09 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i161j8YG010391 for ; Fri, 6 Feb 2004 02:45:09 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 6 Feb 2004 02:45:07 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ16ZVB; Fri, 6 Feb 2004 02:45:43 +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 i161j6XA023526; Fri, 6 Feb 2004 02:45:06 +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 i161h0It006289; Fri, 6 Feb 2004 02:43:00 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i161h0Jl006288; Fri, 6 Feb 2004 02:43:00 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i161gwIt006283 for ; Fri, 6 Feb 2004 02:42:59 +0100 (MET) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 17:42:54 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Feb 2004 17:42:57 -0800 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); Thu, 5 Feb 2004 17:42:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard Date: Thu, 5 Feb 2004 17:42:56 -0800 Message-ID: <64A531765B7C8342BFA260497BE00457011F7D01@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard Thread-Index: AcPq5yGKPxFYhVy3T3GFLYTdrcRxfQBajYyg From: "Tuomas Aura" To: Cc: "Pekka Savola" X-OriginalArrivalTime: 06 Feb 2004 01:42:53.0824 (UTC) FILETIME=[89B3C800:01C3EC52] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i161gxIt006285 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Pekka wrote: > Further, I wonder if it's possible to force an implementation to heavy > computation resulting from the generation of a new address, e.g., by a > DAD attack. This doesn't seem to be the case, because the really > expensive Hash2 is only computed once even if there were collisions. Correct. DAD+CGA cannot be used for DoS. > This clarifies the verification part -- my comment also included > (maybe a misunderstanding) about the generation process. For sec>1 > you have to generate the hash, to look for all zeros, thousands, > millions (or even more) times. That may be pretty bad. I didn't > understand right out the purpose for this. Now it seems that the > reason may be to optimize it for those that are checking CGA's. Maybe > this needs a bit spelling out. The reason for the generation to be expensive is the following: The maximum hash length that can fit into the 64-bit interface identifier is 64 bits. This may not be enough to protect against brute-force attacks in the future. But by making the address generation more expensive, we can also make the brute-force attack more expensive. The attacker will always have to do 2^59 times as much work as the address generator. The address generator can choose freely how much work he wants to do. This is explained in Section 7.2. > Thanks. Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 9 08:14:48 2004 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 IAA17465 for ; Mon, 9 Feb 2004 08:14:47 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i19DEkYG001913 for ; Mon, 9 Feb 2004 14:14:46 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 14:14:45 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJP67NJ; Mon, 9 Feb 2004 14:14:45 +0100 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 i19DESwg028640; Mon, 9 Feb 2004 14:14:29 +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 i19DAkIt021443; Mon, 9 Feb 2004 14:10:46 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i19DAkrW021442; Mon, 9 Feb 2004 14:10:46 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i19DAjIt021438 for ; Mon, 9 Feb 2004 14:10:45 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i19DAiL20476 for ; Mon, 9 Feb 2004 15:10:44 +0200 Date: Mon, 9 Feb 2004 15:10:44 +0200 (EET) From: Pekka Savola To: ietf-send@standards.ericsson.net Subject: send-ndopt review Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 09 Feb 2004 13:14:45.0205 (UTC) FILETIME=[AFA71850:01C3EF0E] Hi, Below are the comments based on my WGLC review of send-ndopt document. You may treat these either as late WGLC or early IETF LC comments :). In general, I think the document is in a pretty good shape, very readable etc. -- thanks! But of course, there are a lot of tiny details to iron out :) bigger architectural considerations ----------------------------------- 1) The SEND model requires the model that if a host sends a solicitation, the router must remember and respect that solicitation, even if it wanted to respond using multicast to all the nodes. That is, if the algorithm is set so that if a host sends a solicitation, the router always replies with a multicast "non-solicited response" in return, there must be both the nonce and timestamp to the multicast advertisement. I don't have strong objections to this model, but I just thought it might be something that some implementations (if those exist, not sure) might find objectionable. 2) How exactly can you check for revoked certificates if you don't have off-link network access yet? Does every node have to contain a database of these, and the possible disconnection time is the window of opportunity for the attacker? As stated in the spec: When processing the three certificates, the usual RFC 3280 certificate path validation is performed, for instance by checking for revoked certificates. (This will probably need a bit of discussion in security considerations as well..) 3) Looking up RFC 3280, from the Trust Anchor option (6.2.3), it strikes me that the FQDN part (at least) may be something that may be subject to the i18n requirements for strings in the specifications (something that always comes up in IESG review, and is in ID nits). I know very little about this myself, but this may be something that a subject matter expert from apps area (for example) might be able to help with. substantial ----------- 5.1.1 Processing Rules for Senders The CGA option MUST be present in all Neighbor Solicitation and Advertisement messages, and in Router Solicitation messages not sent with the unspecified source address. ==> if I read this correctly, using CGA with RS messages is a MAY? (I guess the intent is a MUST) ==> is the non-unspecified source address a MUST? Might be good to make it an uppercase/clarify slightly in any case. (That is, which parts of the RS sentence is a MUST (or not) should be made clearer.) [[ Note: the intent is clearer from the rest of 5.1.1 and 5.1.2]] ..... A message containing a CGA option MUST be checked as follows: If the interface has been configured to use CGA, the receiving node MUST verify the source address of the packet using the algorithm described in Section 5 of [12]. The inputs for the algorithm are the contents of the Collision Cnt, Modifier, and the Key Information fields, the claimed address in the packet (as discussed in the previous section), and the minimum acceptable Sec value. If the CGA verification is successful, the recipient proceeds with the cryptographically more time consuming check of the signature. ==> as the CGA verification gives you no increase of security in itself, the last sentence should be more balanced, or add something like, "However, even if the CGA verification succeeds, no claims about the validity of the use can be made, until the signature has been checked." Similar in 3rd paragtaph of 9.3: When CGA protection is used, SEND deals with the DoS attacks using the verification process described in Section 5.2.2. In this process, a simple hash verification of the CGA property of the address is performed before performing the more expensive signature verification. ........... Pad Length An 8-bit integer field, giving the length of the Pad field in units of an octet. [...] ==> I see zero need for this option. Isn't it enough that the signature is padded up to 8 bytes automatically? (The same issue in 6.2.3 and 6.2.4 with Trust Anchor and Certificate options.) 5.3.2 Nonce Option ==> the padding requirement must be spelled out, if the nonce is not 6+8n bytes long. 5.3.3 Processing rules for senders All solicitation messages MUST include a Nonce. All solicited-for advertisements MUST include a Nonce, copying the nonce value from the received solicitation. [and:] 5.3.4.1 Processing solicited-for advertisements [...] Otherwise, if the message does not contain a Nonce option, it MAY be considered as a non-solicited-for advertisement, and processed according to Section 5.3.4.2. ==> note that for senders, putting in a Nonce is a MUST, but here the lack of it MAY be ignored. Is this intentional (could be)? 5.3.4.2 Processing all other messages [...] The receive time of the last received, accepted SEND message. This is called RDlast. The time stamp in the last received, accepted SEND message. This is called TSlast. ==> AFAICS, "receive time" has only defined in 5.3.4.1, which doesn't apply here. Further, it may be worth spelling out what exactly constitutes an "_accepted_ SEND message". 6.2.5 Processing Rules for Routers Routers SHOULD possess a key pair and a certificate from at least one certificate authority. ==> this is an operational requirement, not an implementation requirement, so I would use lower-case for this, or put it in an operational considerations section. (Same in the last paragraphs of section 7.3.) Hosts SHOULD store certificate chains retrieved in Delegation Chain Discovery messages if they start from an anchor trusted by the host. The certificate chains SHOULD be verified, as defined in Section 6.1, before storing them. [[and the similar in section 6.1]] ==> isn't the usefulness of these certificates nullified, unless it can be guaranteed that they have been verified? Why isn't this a MUST? If the reason is only to support temporary storage of certificate chains, those should be treated as separate from the rest of the certificates -- perhaps there should be a notion of verified certificate storage and unverified temporary storage. 7.1 CGA Addresses Nodes that use stateless address autoconfiguration, SHOULD generate a new CGA as specified in Section 4 of [12] for each new autoconfiguration run. ==> what is the definition of "each new autoconfiguration run"? :) o The node SHOULD have a configuration option that causes it to ignore insecure advertisements even when performing Duplicate Address Detection for the first tentative address. This configuration option SHOULD be disabled by default. This is recovery mechanism, in case attacks against the first address become common. ==> I'd lean towards a "MAY have".. because this seems irrelevant. You can optimize away the cost of just one CGA generation (unless Sec > 0), which is a lightweight process, and then the insecure advertisements are ignored. So, I don't think this is really needed, but if it, we could strengthen the requirement later to a SHOULD (or the like) if we think this threat becomes significant. When a SEND node is used on a link that also connects to non-SEND nodes, the SEND node ignores any insecure Neighbor Solicitations or Advertisements that may be send by the non-SEND nodes. ==> Based on section 8 on transition, this is not 100% correct -- the SEND node will allow the first DAD response, correct? The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. ==> actually, there hasn't been. Only about CGA and the old send-ipsec. Is Send-IPSEC still valid for this document now that CGA is out? [26] International Organization for Standardization, "The Directory - Authentication Framework", ISO Standard X.509, 2000. [27] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. ==> there are some references, at least these, which haven't been used in the body. Use or remove. semi-editorial -------------- Internet Control Message Protocol version 6 (ICMPv6) The IPv6 control signaling protocol. Neighbor Discovery Protocol is a part of ICMPv6. ==> I'd avoid the rathole of defining ICMPv6 (the two ugly words, to "control" and "signaling"). Shouldn't it be enough just assume this is known? If needed, one could mention, under NDP, that NDP messages are ICMPv6. non-SEND node An IPv6 node that does not implement this specification but uses the legacy RFC 2461 and RFC 2462 mechanisms. ==> I would consider removing "legacy" here, as it may cause controversy and doesn't add much, but either way works for me. (A bit more difficult similar issue in section 8, 3rd paragraph; maybe "non-SEND" there?) Router Discovery (RD) The Router Discovery function of the Neighbor Discovery Protocol. ==> this definition doesn't really say anything, maybe add a sentence describing what RD does? [[ The same happens with Neighbor Discovery definition but that's a bit larger can of worms .. ]] Length The length of the option, in units of 8 octets. ==> do these lengths include the Type and Length value as well, or just the option "payload"? Should be clear from RFC2461, but might not hurt if a non-ambiguous wording could be found. entity is allowed to route any prefix, the used IPv6 address prefix is the null prefix, 0/0. The addressFamily element of the containing ==> in this case, there is no danger of confusion, but I'd reword this to be correct RFC3513-wise, to ::/0. ispgroup.com is the trust anchor. The host has this certificate for [...] Issuer: isp_group.com ==> one is ispgroup, the other isp_group ==> these have to be converted to be under example.com/net. (A bit difficult to do as one must illustrate different ISPs, but maybe e.g. isp1.example.com vs isp2.example.com could be used.) Type TBD for CGA. ==> Was this intentional or should all of these have been like: TBD . ? ..... | Type | Length | Name Type | Pad Length | [...] Length The length of the option, (including the Type, Length, Name Type, Name Length, and Name fields,) in units of 8 octets. ==> above, this was Pad Length, here it's Name Length. ==> a few editorial nits in the above text as well s/,)/)/ Name Type The type of the name included in the Name field. This specification defines only one legal value for this field: 1 DER Encoded X.501 Name 2 FQDN ==> Well, I think you already defined two :) ..... If the source address was a unicast address, the router MUST send the response to the Solicited-Node multicast address corresponding to the source address. Routers SHOULD NOT send Delegation Chain Advertisements more than MAX_DCA_RATE times within a second. When there are more solicitations than this, the router SHOULD send the response to the All-Nodes multicast address regardless of the source address that appeared in the solicitation. ==> as these MUST and SHOULD are in conflict, it might make sense to reword the MUST sentence to be a little softer, e..g, add at the end: ", except when under load, as specified below." 1. Entries made as a side effect of a Neighbor Solicitation or Router Solicitation. A router receiving a Router Solicitation with a firm IPv6 source address and a Target Link-Layer Address extension inserts an entry for the IPv6 address into its Neighbor Cache. Also, a node performing Duplicate Address Detection (DAD) ==> what is a "_firm_ IPv6 source address" ? :) editorial --------- IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine each the link-layer addresses of the nodes on the link, to find routers, and to maintain reachability information about the paths to active neighbors. ==> remove "each" ? (see introduction first paragraph) Duplicate Address Detection (DAD) A mechanism that assures that two IPv6 nodes on the same link are not using the same addresses. ==> s/addresses/address/ (not sure, I guess either way is fine) Router Authorization Certificate An X.509v3 [10] PKC certificate using the profile specified in Section 6.1.1. ==> spell out PKC? information is necessary in order to know whether a packet should be sent to a router or to the destination node directly. ==> s/to the .. directly/directly to the .../ (slightly better?) Reserved An an 8-bit field reserved for future use. The value MUST be ==> s/an// to mobility requirements. Still, the number of required signature operations is on the order of a few dozen ones per second, some of which can be precomputed as discussed below. A large number of ==> s/ones// indicates the number of seconds since January 1,, 1970 00:00 UTC, ==> s/1,/1/ 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.3.4.2 ==> s/2/2./ be updated. Independent on whether TSlast is updated or not, RDlast is updated in any case. ==> s/on/of/ Because authorization chains are not a common practice in the Internet at the time this specification is being written, ==> s/is being/was/? (or other such minor reword :) Router Authorization Certificates be X.509v3 certificates, as defined ==> s/be/are/ Care should be taken if the certificates used in SEND are re-used to provide authorization in other circumstances, for example with routing gateway protocols. ==> remove "gateway" ?!!? :) which this message is sent. Note that routers may use multiple addresses, and therefore this address not sufficient for the unique identification of routers. ==> s/not sufficient/is not sufficient/ and they MAY posses a certificate from the above mentioned ==> s/posses/possess/ Nodes that use stateless address autoconfiguration, SHOULD generate a new CGA as specified in Section 4 of [12] for each new ==> s/,// o All solicitations sent by SEND nodes MUST be secured. o Unsolicited advertisements sent by a SEND node MUST be secured. ==> s/SEND nodes/a SEND node/ (or a different kind of consistent style.) This document defines a new name space for the Name Type field in the Trust Anchor option. Future values of this field can be allocated using standards action [6]. The current values for this field are: ==> s/standards action/Standards Action/ (two times) [23] Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002. ==> RFC3315 now [25] Nikander, P., "IPv6 Neighbor Discovery trust models and threats", draft-ietf-send-psreq-00 (work in progress), October 2002. ==> why hasn't this been updated to -04? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 9 08:21:26 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17659 for ; Mon, 9 Feb 2004 08:21:25 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i19DLMAh022033 for ; Mon, 9 Feb 2004 14:21:26 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 14:21:22 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJFXH9T; Mon, 9 Feb 2004 14:22:10 +0100 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 i19DLHwg029140; Mon, 9 Feb 2004 14:21:17 +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 i19DIMIt023930; Mon, 9 Feb 2004 14:18:22 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i19DIM9T023929; Mon, 9 Feb 2004 14:18:22 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i19DIKIt023912 for ; Mon, 9 Feb 2004 14:18:21 +0100 (MET) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 05:17:46 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Feb 2004 05:18:21 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 05:17:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Comments on draft-ietf-send-ndopt-03 Date: Mon, 9 Feb 2004 05:16:51 -0800 Message-ID: <64A531765B7C8342BFA260497BE0045701241B9B@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: Comments on draft-ietf-send-ndopt-03 thread-index: AcPq5yGKPxFYhVy3T3GFLYTdrcRxfQBajYygAK81VyA= From: "Tuomas Aura" To: Cc: "James Kempf" , "Pekka Nikander" , "Jari Arkko" X-OriginalArrivalTime: 09 Feb 2004 13:17:11.0754 (UTC) FILETIME=[0700B2A0:01C3EF0F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i19DILIt023914 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Here are some comments on draft-ietf-send-ndopt-03: 1. CURRENT TEXT: Section 5.1.2: "NS and A messages without the CGA option MUST be silently discarded." Section 5.2.2: "NS, NA, RA and Redirect messages without the Signature option MUST be silently discarded." Section 5.3.4 (in three places): "...received without the ... option MUST be silently discarded." PROBLEM: This is not consistent with Section 8. PROPOSAL: Section 5.1.2 and 5.2.2: "...MUST be treated as insecure, i.e., processed in the same way as ND messages sent by a non-SEND node. The processing of insecure messages is specified in Section 8. (Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the insecure messages.)" Section 5.3.4 (in three places): "...received with the Signature option but without the ... option MUST be silently discarded." 2. CURRENT TEXT: Section 7.3: all the text about discarding advertised prefixes that do not fall within the certified ranges, and reporting them to the admin as error. PROBLEM: This is not consistent with Section 8. Also, deployment of SEND will be unnecessarily difficult if all prefixes advertised by the same router must be certified on the same day. It would be better to allow a mixture of certified and uncertified prefixes. PROPOSAL: A router may advertise a combination of certified and uncertified prefixes. The uncertified prefix information is treated as insecure, i.e., processed in the same way as insecure router advertisements sent by non-SEND routers. The processing of insecure messages is specified in Section 8. (Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the insecure information.) ALTERNATIVE PROPOSAL: A SEND-router may advertise both certified and uncertified prefixes but must send separate router advertisements for the two types of prefixes. 3. CURRENT TEXT: Section 5.1.3: "Implementations MAY also set an upper limit..." PROBLEM: This is not consistent with the CGA draft, which requires the upper limit to be at least 2048. PROPOSAL: "The upper limit SHOULD be at least 2048 bits." 4. CURRENT TEXT: Section: 5.2.2: "The Signature option MUST appear as the last option." PROBLEM: What if we one day want to extend the protocol with a options that come after the signature? For example, if we want to have two different signature options, one has to come before the other. PROPOSAL: "The receiver MUST ignore any options the come after the first Signature option." 5. CURRENT TEXT: Section 5.2.3, CGA flag: "This flag may be per interface or per node." PROBLEM: It might be useful for the router to specify in the router advertisements whether CGA is to be used for a particular prefix or not. PROPOSAL: "Note that in future extensions of the SEND protocol, this flag may be per subnet-prefix." 6. CURRENT TEXT: Section 5.3.4.1: See the last two bullets, especially the sentence: "RDlast is updated in any case." PROBLEM: I think the last bullet has been accidentally written as a separate bullet. It should be a sub-case of the second last bullet. Otherwise, an attacker can use the updating of RDlast to increase the replay window. (Details of the attack: Honest node sends message m1 at time t=10 and message m2 at time t=20. At time t=21, the timestamp on the second message expires, i.e., the receiver stops considering replays of message m2 as valid. At time t=25, the attacker replays m1. Because TSnewTSlast+(RDnew-RDlast)x(1-drift)-fuzz is true and TSnewTSlast+(RDnew-RDlast)x(1-drift)-fuzz is false, then the message should be ignored, regardless of whether TSnew. Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 9 10:24:28 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23817 for ; Mon, 9 Feb 2004 10:24:27 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i19FOSAh030161 for ; Mon, 9 Feb 2004 16:24:28 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 16:24:27 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJFYTQD; Mon, 9 Feb 2004 16:25:16 +0100 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 i19FOIwg009034; Mon, 9 Feb 2004 16:24:18 +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 i19FKnIt027151; Mon, 9 Feb 2004 16:20:49 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i19FKnuI027150; Mon, 9 Feb 2004 16:20:49 +0100 (MET) 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 i19FKlIt027145 for ; Mon, 9 Feb 2004 16:20:48 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.110]) by fep21-app.kolumbus.fi with ESMTP id <20040209152047.IJNY27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi>; Mon, 9 Feb 2004 17:20:47 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: , CC: Subject: comments, issue tracker, new revision Date: Mon, 9 Feb 2004 17:20:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040209152047.IJNY27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 09 Feb 2004 15:24:27.0989 (UTC) FILETIME=[CE8DB050:01C3EF20] Content-Transfer-Encoding: 7bit First, I'd like to thank Pekka Savola and Tuomas Aura very much for their detailed review and comments. Secondly, I have inserted all issues to the issue tracker, visible at http://www.arkko.com/publications/send/issues One of Pekka's comments (on CRL checking) was actually raised earlier by James, so for that I did not create a new issues. Refer to the issue 50 file for the proposed resolution Pekka -- is it sufficient or do we need more? And finally, just for your information: I intend to produce a new draft revision before the deadline i.e. next Monday. This version will address all issues that have been resolved before that time. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Tue Feb 10 11:29:07 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26160 for ; Tue, 10 Feb 2004 11:29:06 -0500 (EST) Received: from esealnt614.al.sw.ericsson.se ([153.88.254.124]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1AGMqAh019389; Tue, 10 Feb 2004 17:22:52 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJR8QGL; Thu, 5 Feb 2004 18:20:40 +0100 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 i15HKJwg011984; Thu, 5 Feb 2004 18:20:19 +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 i15HI9It020339; Thu, 5 Feb 2004 18:18:09 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i15HI9NQ020338; Thu, 5 Feb 2004 18:18:09 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i15HI7It020334 for ; Thu, 5 Feb 2004 18:18:07 +0100 (MET) Message-ID: <01ca01c3ec0c$110fd9c0$936015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" Cc: References: <000101c3e9a7$cbcdac90$936015ac@dclkempt40> Subject: Re: Last Call Issue: CRL Check on DCA Certs Date: Thu, 5 Feb 2004 09:18:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Sounds fine. jak ----- Original Message ----- From: "Pekka Nikander" To: "James Kempf" Cc: Sent: Thursday, February 05, 2004 6:58 AM Subject: Re: Last Call Issue: CRL Check on DCA Certs > James, > > > > > I'd like to suggest the following text: > > > > When procesing the three certificates, the usual RFC 3280 > > certificate path validation is performed. Note, however, that > > at the time a node is checking certificates received in a > > DCA from a router, it typically does not have a connection > > to the Internet yet, and so it is not possible to perform an > > on-line Certificate Revocation List (CRL) check if such a check > > is necessary. Until such a check is performed, acceptance > > of the certificate MUST be considered provisional, and the > > node MUST perform a check as soon as it has established > > a connection with the Internet through the router. If the router > > has been compromised, it could interfere with the CRL check. > > Should performance of the CRL check be disrupted or should > > the check fail, the node SHOULD immediately stop using the > > router as a default and use another router on the link instead. > > > > Comments? > > Looks good, other than I would write "the node SHOULD perform a check > as soon as it has established...". In many cases hosts do not > perform CRL checks today at all, and if they wouldn't do that > anyway, the MUST will become empty. > > --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 Feb 10 11:30:49 2004 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 LAA26210 for ; Tue, 10 Feb 2004 11:30:48 -0500 (EST) Received: from esealnt614.al.sw.ericsson.se ([153.88.254.124]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1AGMqqY002919; Tue, 10 Feb 2004 17:22:52 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJR8QGL; Thu, 5 Feb 2004 18:20:40 +0100 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 i15HKJwg011984; Thu, 5 Feb 2004 18:20:19 +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 i15HI9It020339; Thu, 5 Feb 2004 18:18:09 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i15HI9NQ020338; Thu, 5 Feb 2004 18:18:09 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i15HI7It020334 for ; Thu, 5 Feb 2004 18:18:07 +0100 (MET) Message-ID: <01ca01c3ec0c$110fd9c0$936015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" Cc: References: <000101c3e9a7$cbcdac90$936015ac@dclkempt40> Subject: Re: Last Call Issue: CRL Check on DCA Certs Date: Thu, 5 Feb 2004 09:18:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Sounds fine. jak ----- Original Message ----- From: "Pekka Nikander" To: "James Kempf" Cc: Sent: Thursday, February 05, 2004 6:58 AM Subject: Re: Last Call Issue: CRL Check on DCA Certs > James, > > > > > I'd like to suggest the following text: > > > > When procesing the three certificates, the usual RFC 3280 > > certificate path validation is performed. Note, however, that > > at the time a node is checking certificates received in a > > DCA from a router, it typically does not have a connection > > to the Internet yet, and so it is not possible to perform an > > on-line Certificate Revocation List (CRL) check if such a check > > is necessary. Until such a check is performed, acceptance > > of the certificate MUST be considered provisional, and the > > node MUST perform a check as soon as it has established > > a connection with the Internet through the router. If the router > > has been compromised, it could interfere with the CRL check. > > Should performance of the CRL check be disrupted or should > > the check fail, the node SHOULD immediately stop using the > > router as a default and use another router on the link instead. > > > > Comments? > > Looks good, other than I would write "the node SHOULD perform a check > as soon as it has established...". In many cases hosts do not > perform CRL checks today at all, and if they wouldn't do that > anyway, the MUST will become empty. > > --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 Sat Feb 14 03:51:59 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12096 for ; Sat, 14 Feb 2004 03:51:59 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1E8pxAh001196 for ; Sat, 14 Feb 2004 09:51:59 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 09:51:59 +0100 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 1663FHS3; Sat, 14 Feb 2004 09:51:58 +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 i1E8pwXA003614; Sat, 14 Feb 2004 09:51:58 +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 i1E8nqIt014178; Sat, 14 Feb 2004 09:49:52 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1E8nq3m014177; Sat, 14 Feb 2004 09:49:52 +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 i1E8npIt014173 for ; Sat, 14 Feb 2004 09:49:51 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep02-app.kolumbus.fi with ESMTP id <20040214084951.ESLX1464.fep02-app.kolumbus.fi@kolumbus.fi>; Sat, 14 Feb 2004 10:49:51 +0200 Message-ID: <402DE0C2.2060709@kolumbus.fi> Date: Sat, 14 Feb 2004 10:48:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: issue 62 - rdlast Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Feb 2004 08:51:59.0071 (UTC) FILETIME=[CE5EB6F0:01C3F2D7] Content-Transfer-Encoding: 7bit Tuomas, > CURRENT TEXT: Section 5.3.4.1: See the last two bullets, > especially the sentence: "RDlast is updated in any case." > > PROBLEM: I think the last bullet has been accidentally written as a > separate bullet. It should be a sub-case of the second last > bullet. Otherwise, an attacker can use the updating of RDlast to > increase the replay window. > > (Details of the attack: Honest node sends message m1 > at time t=10 and message m2 at time t=20. At time > t=21, the timestamp on the second message expires, > i.e., the receiver stops considering replays of > message m2 as valid. At time t=25, the attacker > replays m1. Because TSnew RDlast but not TSlast. This effectively increases the > replay windows by 5 time units. Attacker can now > replay message m2 and it will be accepted.) > If TSnew+fuzz>TSlast+(RDnew-RDlast)x(1-drift)-fuzz is > true and TSnew updating RDlast. However, I don't understand why it > needs to be updated. > > PROPOSAL: Make the last bullet a sub-case of the second last > bullet. Delete the sentence "RDlast is updated in any case." Most > importantly, if TSnew+fuzz>TSlast+(RDnew-RDlast)x(1-drift)-fuzz is > false, then the message should be ignored, regardless of whether > TSnew TSlast + (RDnew - RDlast) x (1 - drift) - fuzz If this does not hold, the message SHOULD be silently discarded. If it does hold, the message is processed. However, 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 node MUST NOT ever decrease. Otherwise TSlast and RDlast SHOULD be updated. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sat Feb 14 03:52:09 2004 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 DAA12118 for ; Sat, 14 Feb 2004 03:52:09 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1E8q7YG018549 for ; Sat, 14 Feb 2004 09:52:08 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 09:52:06 +0100 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 1663FHTG; Sat, 14 Feb 2004 09:52:06 +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 i1E8q5XA003619; Sat, 14 Feb 2004 09:52:05 +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 i1E8nZIt014119; Sat, 14 Feb 2004 09:49:35 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1E8nZIN014118; Sat, 14 Feb 2004 09:49:35 +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 i1E8nYIt014114 for ; Sat, 14 Feb 2004 09:49:34 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep02-app.kolumbus.fi with ESMTP id <20040214084933.ESKE1464.fep02-app.kolumbus.fi@kolumbus.fi>; Sat, 14 Feb 2004 10:49:33 +0200 Message-ID: <402DE0B0.8030408@kolumbus.fi> Date: Sat, 14 Feb 2004 10:47:44 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG , Tuomas Aura , Pekka Savola , James Kempf Subject: send draft revisions and issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Feb 2004 08:52:06.0915 (UTC) FILETIME=[D30B9D30:01C3F2D7] Content-Transfer-Encoding: 7bit Tuomas, Pekka, James and others, I'm working through the reported issues. Thanks again for submitting detailed comments! You can see the final edits of the resolutions on the issue web page at: http://www.arkko.com/publications/send/issues/ Click on "diff" to see how each issue changed the draft. Most of the time you have provided quite clear proposed text, which I have followed. But if you have time, please check to see if you like the end results. I'll be sending questions on the couple of issues that I have questions on. My intent is to release the -04 version late sunday evening or early monday morning the latest, because of the I-D deadline for Seoul. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sat Feb 14 03:58:30 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12208 for ; Sat, 14 Feb 2004 03:58:30 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1E8wUAh001941 for ; Sat, 14 Feb 2004 09:58:30 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 09:58:30 +0100 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 1LJ47GAC; Sat, 14 Feb 2004 09:58:30 +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 i1E8wTXA003640; Sat, 14 Feb 2004 09:58:29 +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 i1E8uwIt015702; Sat, 14 Feb 2004 09:56:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1E8uwOa015701; Sat, 14 Feb 2004 09:56:58 +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 i1E8uvIt015697 for ; Sat, 14 Feb 2004 09:56:57 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep02-app.kolumbus.fi with ESMTP id <20040214085657.ETWP1464.fep02-app.kolumbus.fi@kolumbus.fi> for ; Sat, 14 Feb 2004 10:56:57 +0200 Message-ID: <402DE26C.5050006@kolumbus.fi> Date: Sat, 14 Feb 2004 10:55:08 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: issue 51 - commented pdf reader? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Feb 2004 08:58:30.0676 (UTC) FILETIME=[B7C8E540:01C3F2D8] Content-Transfer-Encoding: 7bit If anyone knows how to read PDF files with comments on a Linux system, I would appreciate a pointer to the necessary tools. See http://www.arkko.com/publications/send/issues/issue51.pdf (I can read this when on monday I get back to the office where some windows machines and acrobat readers exist, but I would like to start working on it sooner.) --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sat Feb 14 07:22:04 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16340 for ; Sat, 14 Feb 2004 07:22:03 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1ECM3Ah013781 for ; Sat, 14 Feb 2004 13:22:03 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 13:22:03 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 166A3FNG; Sat, 14 Feb 2004 13:22:05 +0100 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 i1ECLlwg014465; Sat, 14 Feb 2004 13:21:48 +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 i1ECJmIt010163; Sat, 14 Feb 2004 13:19:48 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1ECJm27010156; Sat, 14 Feb 2004 13:19:48 +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 i1ECJlIt010149 for ; Sat, 14 Feb 2004 13:19:47 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep02-app.kolumbus.fi with ESMTP id <20040214121947.GSFW1464.fep02-app.kolumbus.fi@kolumbus.fi>; Sat, 14 Feb 2004 14:19:47 +0200 Message-ID: <402E11F5.5090909@kolumbus.fi> Date: Sat, 14 Feb 2004 14:17:57 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: issue 63 -- ref 6.2.1 or list explicit checks for message format Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Feb 2004 12:22:03.0207 (UTC) FILETIME=[27053D70:01C3F2F5] Content-Transfer-Encoding: 7bit > CURRENT TEXT: Section 6.2.5: "All requirements > listed in Section 6.2.1 are fulfilled." Section 6.2.6: > "All requirements listed in Section 6.2.2 are > fulfilled." > > PROBLEM: This is too vague. What are the requirements > is 6.2.1/6.2.2? I would not know what code to write > for this. > > PROPOSAL: List explicitly the things that the > router/host needs to check (rather than referencing > Sections 6.2.1/6.2.2). Tuomas, I agree with almost everything you have commented, but I'm not sure about this one. We actually did have an explicit list of checks in a previous version of the draft, but there were complaints of redundancy and this was one of the things that got simplified. I would note that there are explicit values listed for various fields, as well as keywords dictating the contents of the fields in more complex cases. Is there some specific check that you are missing? Comments? --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sat Feb 14 08:07:24 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17244 for ; Sat, 14 Feb 2004 08:07:23 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1ED7NAh016650 for ; Sat, 14 Feb 2004 14:07:23 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 14:07:23 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ48JHH; Sat, 14 Feb 2004 14:07:23 +0100 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 i1ED7Kwg016566; Sat, 14 Feb 2004 14:07:20 +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 i1ED5TIt022425; Sat, 14 Feb 2004 14:05:29 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1ED5TGt022424; Sat, 14 Feb 2004 14:05:29 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1ED5RIt022420 for ; Sat, 14 Feb 2004 14:05:28 +0100 (MET) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 05:06:05 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 14 Feb 2004 05:05:26 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 05:04:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: issue 62 - rdlast Date: Sat, 14 Feb 2004 05:05:15 -0800 Message-ID: <64A531765B7C8342BFA260497BE004570136E938@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: issue 62 - rdlast Thread-Index: AcPy14O8gE+F0v8KTku3UcrOtnBhJAAEFOtA From: "Tuomas Aura" To: "Jari Arkko" Cc: "SEND WG" X-OriginalArrivalTime: 14 Feb 2004 13:04:44.0196 (UTC) FILETIME=[1D7D2640:01C3F2FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i1ED5SIt022421 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Jari Arkko wrote: > Agreed. But this is complicated. Lets see if I got this > right. Here's the new text for the combined last two bullets: > > 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 checked > against the previously received SEND message: > > TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz > > If this does not hold, the message SHOULD be silently discarded. > > If it does hold, the message is processed. However, 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 node MUST NOT ever decrease. Otherwise TSlast and RDlast > SHOULD be updated. This fixes the main issue. However, it is still not specified whether the receiver should update RDlast if both formulas hold. It is probably better not to update RDlast because the packet that arrives first gives the most accurate measurement of the difference of the clocks. (Note that attackers cannot exploit this because they usually cannot speed up the delivery of packets.) Could we rewrite the 2 last paragraphs above a follows: If this inequality does not hold, the receiver SHOULD silently discard the message. On the other hand, if the inequality holds, the receiver SHOULD process the message. Moreover, if the above inequality holds and TSnew > TSlast, the receiver SHOULD update RDlast and TSlast. Otherwise, the receiver MUST NOT update update RDlast or TSlast. I would leave out the sentence about TSlast never decreasing because the reader might understand this as a general a rule. It is, or course, not a general rule because TSlast can decrease in response to solicited advertisements. Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sat Feb 14 08:34:05 2004 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 IAA17560 for ; Sat, 14 Feb 2004 08:34:04 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1EDY0YG009877 for ; Sat, 14 Feb 2004 14:34:04 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 14:33:59 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJHQ52J; Sat, 14 Feb 2004 14:35:05 +0100 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 i1EDXvwg017606; Sat, 14 Feb 2004 14:33:57 +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 i1EDW6It029711; Sat, 14 Feb 2004 14:32:06 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1EDW6fm029710; Sat, 14 Feb 2004 14:32:06 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1EDW5It029706 for ; Sat, 14 Feb 2004 14:32:05 +0100 (MET) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 05:32:58 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 14 Feb 2004 05:31:56 -0800 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); Sat, 14 Feb 2004 05:32:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: issue 63 -- ref 6.2.1 or list explicit checks for message format Date: Sat, 14 Feb 2004 05:31:53 -0800 Message-ID: <64A531765B7C8342BFA260497BE004570136E93C@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: issue 63 -- ref 6.2.1 or list explicit checks for message format Thread-Index: AcPy9OB5tnyL3mXsTUelydXhaGwyUgAA6iZQ From: "Tuomas Aura" To: "Jari Arkko" Cc: "SEND WG" X-OriginalArrivalTime: 14 Feb 2004 13:32:01.0630 (UTC) FILETIME=[ED79BFE0:01C3F2FE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sw.ericsson.se id i1EDW6It029707 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 8bit Jari Arkko wrote: > I would note that there are explicit values listed for various > fields, as well as keywords dictating the contents of the fields > in more complex cases. Is there some specific check that you are > missing? I guess the real answer is that there aren't any important checks: it is the validness of the certificate chain that matters, not the way in which the certificates are discovered. Perhaps the text in 6.2.5 could be changed as follows: A router MUST silently discard any received Delegation Chain Solicitation messages that do not conform to the message format defined in Section 6.2.1. The contents of the Reserved field, and of any unrecognized... That is, delete the bullets altogether. Section 6.2.6 could be changed similarly. This way, the reader will not start to think that there are some security-critical checks hidden somewhere (as I mistakenly did). Tuomas -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sat Feb 14 11:36:22 2004 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 LAA23233 for ; Sat, 14 Feb 2004 11:36:21 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1EGaLqY009542 for ; Sat, 14 Feb 2004 17:36:21 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 17:36:21 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 166APJK8; Sat, 14 Feb 2004 17:36:24 +0100 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 i1EGaGwg026581; Sat, 14 Feb 2004 17:36:16 +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 i1EGYIIt018096; Sat, 14 Feb 2004 17:34:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1EGYIeX018095; Sat, 14 Feb 2004 17:34:18 +0100 (MET) 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 i1EGYHIt018091 for ; Sat, 14 Feb 2004 17:34:17 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep21-app.kolumbus.fi with ESMTP id <20040214163417.LPNA27281.fep21-app.kolumbus.fi@kolumbus.fi>; Sat, 14 Feb 2004 18:34:17 +0200 Message-ID: <402E4D9B.3000200@kolumbus.fi> Date: Sat, 14 Feb 2004 18:32:27 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: Re: issue 63 -- ref 6.2.1 or list explicit checks for message format References: <64A531765B7C8342BFA260497BE004570136E93C@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE004570136E93C@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Feb 2004 16:36:21.0386 (UTC) FILETIME=[AD9A96A0:01C3F318] Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > Jari Arkko wrote: > >>I would note that there are explicit values listed for various >>fields, as well as keywords dictating the contents of the fields >>in more complex cases. Is there some specific check that you are >>missing? > > > I guess the real answer is that there aren't any important > checks: it is the validness of the certificate chain that > matters, not the way in which the certificates are discovered. > > Perhaps the text in 6.2.5 could be changed as follows: > > A router MUST silently discard any received Delegation Chain > Solicitation messages that do not conform to the message > format defined in Section 6.2.1. The contents of the Reserved > field, and of any unrecognized... > > That is, delete the bullets altogether. Section 6.2.6 could be > changed similarly. This way, the reader will not start to think > that there are some security-critical checks hidden somewhere > (as I mistakenly did). Ok. I had actually already something like this due to an earlier issue which removed the other item from the bullet list. But your wording is better. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sat Feb 14 11:37:12 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23257 for ; Sat, 14 Feb 2004 11:37:12 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1EGbCAh031777 for ; Sat, 14 Feb 2004 17:37:12 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 17:37:12 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 166APJ3P; Sat, 14 Feb 2004 17:37:15 +0100 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 i1EGbBwg026621; Sat, 14 Feb 2004 17:37:11 +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 i1EGZiIt018362; Sat, 14 Feb 2004 17:35:44 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1EGZiWp018361; Sat, 14 Feb 2004 17:35:44 +0100 (MET) 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 i1EGZhIt018357 for ; Sat, 14 Feb 2004 17:35:43 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep21-app.kolumbus.fi with ESMTP id <20040214163543.LQAY27281.fep21-app.kolumbus.fi@kolumbus.fi>; Sat, 14 Feb 2004 18:35:43 +0200 Message-ID: <402E4DF1.10900@kolumbus.fi> Date: Sat, 14 Feb 2004 18:33:53 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura CC: SEND WG Subject: Re: issue 62 - rdlast References: <64A531765B7C8342BFA260497BE004570136E938@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE004570136E938@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 14 Feb 2004 16:37:12.0731 (UTC) FILETIME=[CC3536B0:01C3F318] Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > Jari Arkko wrote: > >>Agreed. But this is complicated. Lets see if I got this >>right. Here's the new text for the combined last two bullets: >> >> 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 checked >> against the previously received SEND message: >> >> TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz >> >> If this does not hold, the message SHOULD be silently > > discarded. > >> If it does hold, the message is processed. However, 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 node MUST NOT ever decrease. Otherwise TSlast and RDlast >> SHOULD be updated. > > > This fixes the main issue. However, it is still not specified > whether the receiver should update RDlast if both formulas > hold. It is probably better not to update RDlast because > the packet that arrives first gives the most accurate > measurement of the difference of the clocks. (Note that > attackers cannot exploit this because they usually cannot > speed up the delivery of packets.) > > Could we rewrite the 2 last paragraphs above a follows: > > If this inequality does not hold, the receiver SHOULD > silently discard the message. On the other hand, if the > inequality holds, the receiver SHOULD process the message. > > Moreover, if the above inequality holds and > TSnew > TSlast, the receiver SHOULD update RDlast > and TSlast. Otherwise, the receiver MUST NOT update > update RDlast or TSlast. > > I would leave out the sentence about TSlast never decreasing > because the reader might understand this as a general a rule. > It is, or course, not a general rule because TSlast can decrease > in response to solicited advertisements. Your text looks good. Thanks. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sun Feb 15 14:12:31 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20327 for ; Sun, 15 Feb 2004 14:12:31 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1FJCUAh015402 for ; Sun, 15 Feb 2004 20:12:30 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 15 Feb 2004 20:12:30 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 166AVWBJ; Sun, 15 Feb 2004 20:12:36 +0100 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 i1FJCIwg027365; Sun, 15 Feb 2004 20:12:19 +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 i1FJ9tIt019860; Sun, 15 Feb 2004 20:09:55 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1FJ9tZO019859; Sun, 15 Feb 2004 20:09:55 +0100 (MET) 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 i1FJ9sIt019855 for ; Sun, 15 Feb 2004 20:09:54 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep21-app.kolumbus.fi with ESMTP id <20040215190954.SXY27281.fep21-app.kolumbus.fi@kolumbus.fi>; Sun, 15 Feb 2004 21:09:54 +0200 Message-ID: <402FC391.5050902@kolumbus.fi> Date: Sun, 15 Feb 2004 21:08:01 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura , SEND WG Subject: issue 58 - certified and non-certified prefixes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Feb 2004 19:12:30.0435 (UTC) FILETIME=[A867C330:01C3F3F7] Content-Transfer-Encoding: 7bit Tuomas, This is another complicated issue. We have visited this particular piece of text before, so I'm trying to keep some of the earlier resolutions still there too... let's see if I have managed to do it right. Here's the diff: http://www.arkko.com/publications/send/issues/issue58diff.html and the new text: 7.3 Advertised Prefixes The router's certificate defines the address range(s) that it is allowed to advertise securely. A router MAY, however, advertise a combination of certified and uncertified prefixes. Uncertified prefixes are treated as insecure, i.e., processed in the same way as insecure router advertisements sent by non-SEND routers. The processing of insecure messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the insecure information. Certified prefixes fall into the following two categories: Constrained If the network operator wants to constrain which routers are allowed to route particular prefixes, routers SHOULD be configured with certificates having prefixes listed in the prefix extension. Routers so configured SHOULD advertise the prefixes which they are certified to route, or a subset thereof. Unconstrained Network operators that do not want to constrain routers this way SHOULD configure routers with certificates containing either the null prefix or no prefix extension at all. Upon processing a Prefix Information option within a Router Advertisement, nodes SHOULD verify that the prefix specified in this option falls within the range defined by the certificate, if the certificate contains a prefix extension. Options failing this check are treated as containing uncertified prefixes. Nodes SHOULD use one of the certified prefixes for stateless autoconfiguration. If none of the advertised prefixes match, the host SHOULD use a different advertising router as its default router, if available. If the node is performing stateful autoconfiguration, it SHOULD check the address provided by the DHCP server against the certified prefixes and SHOULD NOT use the address if the prefix is not certified. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Sun Feb 15 14:21:16 2004 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 OAA20552 for ; Sun, 15 Feb 2004 14:21:15 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1FJLCqY017995 for ; Sun, 15 Feb 2004 20:21:12 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 15 Feb 2004 20:21:12 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJVFG5N; Sun, 15 Feb 2004 20:21:12 +0100 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 i1FJL8wg027768; Sun, 15 Feb 2004 20: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 i1FJJcIt023364; Sun, 15 Feb 2004 20:19:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1FJJcjI023363; Sun, 15 Feb 2004 20:19:38 +0100 (MET) 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 i1FJJbIt023359 for ; Sun, 15 Feb 2004 20:19:37 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep21-app.kolumbus.fi with ESMTP id <20040215191936.VIU27281.fep21-app.kolumbus.fi@kolumbus.fi>; Sun, 15 Feb 2004 21:19:36 +0200 Message-ID: <402FC5D3.5070307@kolumbus.fi> Date: Sun, 15 Feb 2004 21:17:39 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola , SEND WG Subject: issue 53 -- i18n requirements for FQDNs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 15 Feb 2004 19:21:12.0691 (UTC) FILETIME=[DFB1B430:01C3F3F8] Content-Transfer-Encoding: 7bit Pekka, > Looking up RFC 3280, from the Trust Anchor option > (6.2.3), it strikes me that the FQDN part (at least) may be something > that may be subject to the i18n requirements for strings in the > specifications (something that always comes up in IESG review, and is > in ID nits). I know very little about this myself, but this may be > something that a subject matter expert from apps area (for example) > might be able to help with. I'm not an expert on this either, but it seems that the FQDN internationalization cab be solved rather easily. Specifically, RFC 3490 defines internationalized domain names (IDNs) through ToAscii and FromAscii operations that map international names to good old FQDNs and map. Protocols with with FQDN slots can most of the time operate without awareness of IDNs. So here are my suggested text modifications. Add to Section 6.2.3 under "Name": In the FQDN case the Name field is an "IDN-unaware domain name slot" as defined in [RFC3490]. That is, it can contain only ASCII characters. An implementation MAY support internationalized domain names (IDNs) using the ToASCII operation; see [RFC3490] for more information. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 16 03:57:50 2004 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 DAA06316 for ; Mon, 16 Feb 2004 03:57:49 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1G8vnYG029723 for ; Mon, 16 Feb 2004 09:57:49 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 09:57:48 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FBM77580; Mon, 16 Feb 2004 09:49:40 +0100 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 i1G8nawg026377; Mon, 16 Feb 2004 09:49:37 +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 i1G8lJIt014364; Mon, 16 Feb 2004 09:47:19 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1G8lJvZ014363; Mon, 16 Feb 2004 09:47:19 +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 i1G8lIIt014347 for ; Mon, 16 Feb 2004 09:47:18 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep02-app.kolumbus.fi with ESMTP id <20040216084718.DFFS1464.fep02-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 10:47:18 +0200 Message-ID: <40308324.7090509@kolumbus.fi> Date: Mon, 16 Feb 2004 10:45:24 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Pekka Nikander , SEND WG Subject: issue 54 - pekka's technical issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Feb 2004 08:57:48.0674 (UTC) FILETIME=[F3936620:01C3F46A] Content-Transfer-Encoding: 7bit Thanks for the comments. I think I took into account all of them except for the following: - Pad length being unnecessary. The pad lengths are explicit since there are variable length fields. For instance, the Trust Anchor option has a name which may end at an 8-octet boundary. We could pad with zero bytes, but I feel better about an explicit pad length field. Similarly, the Signature and Certificate options have complicated ASN.1 data, and it may be easier to have an explicit field than to determine it from the encoding of a field. - Nonces being required for senders but the lack of a nonce can in some cases be ignored by receivers. I was unsure about this one. Perhaps Pekka N can explain as this part of the text came from him, I think. But I would classify this under "be conservative what you send, liberal what you accept". - IPR notices applying to an old draft version and name. I know. I can not speak for others but I like to avoid going to the IPR department more often than really necessary ;-). Since we are about to finish the SEND protocol and there are no more draft renamings (I hope!) I now go and ask for an update of the IPR notice too. See the new text in http://www.arkko.com/publications/send/issues/issue54diff.html -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 16 03:58:13 2004 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 DAA06376 for ; Mon, 16 Feb 2004 03:58:12 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1G8wCqY004345 for ; Mon, 16 Feb 2004 09:58:13 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 09:58:12 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FBM776S3; Mon, 16 Feb 2004 09:52:21 +0100 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 i1G8qKwg026507; Mon, 16 Feb 2004 09:52:21 +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 i1G8onIt015097; Mon, 16 Feb 2004 09:50:49 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1G8onfC015096; Mon, 16 Feb 2004 09:50:49 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1G8omIt015091 for ; Mon, 16 Feb 2004 09:50:48 +0100 (MET) Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id F334B1C; Mon, 16 Feb 2004 11:03:33 +0200 (EET) In-Reply-To: <40308324.7090509@kolumbus.fi> References: <40308324.7090509@kolumbus.fi> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <35EADAC0-605D-11D8-A37D-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Pekka Savola , SEND WG From: Pekka Nikander Subject: Re: issue 54 - pekka's technical issues Date: Mon, 16 Feb 2004 10:50:46 +0200 To: Jari Arkko X-Mailer: Apple Mail (2.612) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Feb 2004 08:58:12.0440 (UTC) FILETIME=[01BDCD80:01C3F46B] Content-Transfer-Encoding: 7bit > - Nonces being required for senders but the lack of a nonce can in > some cases be ignored by receivers. I was unsure about this > one. Perhaps Pekka N can explain as this part of the text came from > him, I think. But I would classify this under "be conservative what > you send, liberal what you accept". I'm sorry but I don't remember the details any more, and don't have time to dive in right now. I guess your explanation, Jari, is the right one. --Pekka N. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 16 05:21:14 2004 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 FAA09706 for ; Mon, 16 Feb 2004 05:21:14 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1GALBYG023560 for ; Mon, 16 Feb 2004 11:21:15 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 11:21:11 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJH81A9; Mon, 16 Feb 2004 11:22:24 +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 i1GAL9XA019883; Mon, 16 Feb 2004 11:21:10 +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 i1GAIwIt009201; Mon, 16 Feb 2004 11:18:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1GAIwS5009197; Mon, 16 Feb 2004 11:18:58 +0100 (MET) 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 i1GAIvIt009181 for ; Mon, 16 Feb 2004 11:18:57 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep01-app.kolumbus.fi with ESMTP id <20040216101856.KCMV9750.fep01-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 12:18:56 +0200 Message-ID: <4030989E.6050509@kolumbus.fi> Date: Mon, 16 Feb 2004 12:17:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG CC: Pekka Savola , James Kempf , Tuomas Aura Subject: send draft 04 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Feb 2004 10:21:11.0092 (UTC) FILETIME=[993FCF40:01C3F476] Content-Transfer-Encoding: 7bit Hello, I have closed all raised issues now. There were a few question marks along the way, which I resolved the way I thought was reasonable. It is possible that original issue submitters don't agree, I guess we'll have to see about that later. However, I need to submit this soon. You have 20 minutes before this goes in ;-) The issues, the new draft, and differences can be see in http://www.arkko.com/publications/send/issues/ http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt http://www.arkko.com/publications/send/drafts/draft-send-ndoptdiff.html --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Mon Feb 16 06:41:40 2004 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 GAA12355 for ; Mon, 16 Feb 2004 06:41:40 -0500 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1GBffqY023795 for ; Mon, 16 Feb 2004 12:41:42 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 12:41:40 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJH85S3; Mon, 16 Feb 2004 12:42:54 +0100 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 i1GBfUwg006380; Mon, 16 Feb 2004 12:41:31 +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 i1GBdDIt000347; Mon, 16 Feb 2004 12:39:13 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1GBdDw6000346; Mon, 16 Feb 2004 12:39:13 +0100 (MET) 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 i1GBdCIt000342 for ; Mon, 16 Feb 2004 12:39:12 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep21-app.kolumbus.fi with ESMTP id <20040216113912.MMGF27281.fep21-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 13:39:12 +0200 Message-ID: <4030AB6E.9020101@kolumbus.fi> Date: Mon, 16 Feb 2004 13:37:18 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG CC: Pekka Savola , James Kempf , Tuomas Aura Subject: Re: send draft 04 References: <4030989E.6050509@kolumbus.fi> In-Reply-To: <4030989E.6050509@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 16 Feb 2004 11:41:40.0930 (UTC) FILETIME=[D80E9A20:01C3F481] Content-Transfer-Encoding: 7bit After a few spelling error corrections, draft 04 has now been submitted. Here are the final files: http://www.arkko.com/publications/send/issues/ http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt http://www.arkko.com/publications/send/drafts/draft-send-ndoptdiff.html http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-04.txt --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Wed Feb 18 10:20:31 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19541 for ; Wed, 18 Feb 2004 10:20:30 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1IFKVAh000011 for ; Wed, 18 Feb 2004 16:20:31 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Feb 2004 16:20:31 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ2VRX6; Wed, 18 Feb 2004 16:21:52 +0100 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 i1IFKSwg022348; Wed, 18 Feb 2004 16:20:28 +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 i1IFFMIt001467; Wed, 18 Feb 2004 16:15:22 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1IFFMhY001463; Wed, 18 Feb 2004 16:15:22 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep22-app.kolumbus.fi (fep22-0.kolumbus.fi [193.229.0.60]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1IFFLIt001439 for ; Wed, 18 Feb 2004 16:15:21 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep22-app.kolumbus.fi with ESMTP id <20040218151521.OGOA3524.fep22-app.kolumbus.fi@kolumbus.fi> for ; Wed, 18 Feb 2004 17:15:21 +0200 Message-ID: <40338113.7010506@kolumbus.fi> Date: Wed, 18 Feb 2004 17:13:23 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: (fwd) draft-04 I-D announcement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 18 Feb 2004 15:20:31.0121 (UTC) FILETIME=[BF164010:01C3F632] Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : SEcure Neighbor Discovery (SEND) Author(s) : J. Arkko Filename : draft-ietf-send-ndopt-04.txt Pages : 59 Date : 2004-2-18 IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine each the link-layer addresses of the nodes on the link, to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike to the original NDP specifications, these mechanisms do not make use of IPsec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-04.txt -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Feb 19 09:50:43 2004 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 JAA20797 for ; Thu, 19 Feb 2004 09:50:42 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1JEogqY013263 for ; Thu, 19 Feb 2004 15:50:42 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 15:50:42 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FGMCLYV2; Thu, 19 Feb 2004 15:51:32 +0100 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 i1JEmWwg024470; Thu, 19 Feb 2004 15:48:32 +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 i1JEjmIt008958; Thu, 19 Feb 2004 15:45:48 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1JEjmFi008957; Thu, 19 Feb 2004 15:45:48 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1JEjbIt008583 for ; Thu, 19 Feb 2004 15:45:42 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1JEjL921649; Thu, 19 Feb 2004 16:45:21 +0200 Date: Thu, 19 Feb 2004 16:45:21 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: SEND WG Subject: Re: issue 52 - nd vs. send response model In-Reply-To: <402FD430.401@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 19 Feb 2004 14:50:42.0372 (UTC) FILETIME=[BF529040:01C3F6F7] Sorry for not being able to answer straight away.. On Sun, 15 Feb 2004, Jari Arkko wrote: > > The SEND model requires the model that if a host sends a solicitation, > > the router must remember and respect that solicitation, even if it wanted to > > respond using multicast to all the nodes. That is, if the algorithm is set > > so that if a host sends a solicitation, the router always replies with a > > multicast "non-solicited response" in return, there must be both the nonce > > and timestamp to the multicast advertisement. > > > > I don't have strong objections to this model, but I just thought it might be > > something that some implementations (if those exist, not sure) might find > > objectionable. > > I agree that there is a difference. > > But I'm not sure the difference is that great. I mean, you can still > send a multicast response. And in this case the solicited/non-solicited > difference is just whether you have one or two additional ND options > in there. And other hosts that receive this can still process them > securely or do their own solicitation if timestamp was insufficient. Yep, I agree that this difference is not significant. It's just something an implementation might do, so it may be worth spelling out.. > The only thing that is needed implementation-wise is for the multicast > RA code piece to know whether it needs to include a Nonce. But I would > expect most implementations to have some idea on why they are sending > the RA. If not, a new parameter has to be added to the function call. > > In any case, I added this text to Section 5.3.3: > > Note that routers may decide to send a multicast > advertisement to all nodes instead of a response to a > specific host. In such case the router MAY still include the > nonce value for the host that triggered the multicast > advertisement. This seems basically good -- with the caveat that if the router does not include the nonce, the advertisement may end up being ignored by SEND nodes, right? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Feb 19 09:56:10 2004 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 JAA21087 for ; Thu, 19 Feb 2004 09:56:09 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1JEu9YG020908 for ; Thu, 19 Feb 2004 15:56:09 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 15:56:08 +0100 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 FGALHPXK; Thu, 19 Feb 2004 15:56:08 +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 i1JEu7XA002542; Thu, 19 Feb 2004 15:56:07 +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 i1JEtvIt011307; Thu, 19 Feb 2004 15:55:57 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1JEtvj5011306; Thu, 19 Feb 2004 15:55:57 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1JEttIt011301 for ; Thu, 19 Feb 2004 15:55:55 +0100 (MET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1JEtsf21756; Thu, 19 Feb 2004 16:55:54 +0200 Date: Thu, 19 Feb 2004 16:55:54 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: Pekka Nikander , SEND WG Subject: Re: issue 54 - pekka's technical issues In-Reply-To: <40308324.7090509@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk X-OriginalArrivalTime: 19 Feb 2004 14:56:08.0878 (UTC) FILETIME=[81EF6CE0:01C3F6F8] Hi, On Mon, 16 Feb 2004, Jari Arkko wrote: > Thanks for the comments. I think I took into account all of > them except for the following: > > - Pad length being unnecessary. The pad lengths are explicit since > there are variable length fields. For instance, the Trust Anchor > option has a name which may end at an 8-octet boundary. We could pad > with zero bytes, but I feel better about an explicit pad length > field. Similarly, the Signature and Certificate options have > complicated ASN.1 data, and it may be easier to have an explicit > field than to determine it from the encoding of a field. I'm not sure if I understand your reasoning. You seem to be saying that it's important to get the exact length of the ASN.1 encoded data, before decoding the data. Note that you can already get the rough estimate -- which is enough e.g. for buffer allocation purposes, I'd guess -- from Length field; this will include 0-7 bytes of zero padding at the end. I certainly don't see problems with implicit zero padding when the data falls on alignment boundaries; I think using such is extremely commonplace in IETF specs. So, I still think that Pad Length appears to be unnecessary. On the other hand, it MIGHT be necessary if you would have to be able to allocate the exact size of memory for storing the data before decoding the data. But 0-7 bytes of overhead here doesn't seem to be worth the trouble.. > - Nonces being required for senders but the lack of a nonce can in > some cases be ignored by receivers. I was unsure about this > one. Perhaps Pekka N can explain as this part of the text came from > him, I think. But I would classify this under "be conservative what > you send, liberal what you accept". Fine with me. > - IPR notices applying to an old draft version and name. I know. I > can not speak for others but I like to avoid going to the IPR > department more often than really necessary ;-). Since we are about > to finish the SEND protocol and there are no more draft renamings (I > hope!) I now go and ask for an update of the IPR notice too. OK. Note that I'm actually hoping that there would NOT be IPR claims anymore -- as CGA stuff has been moved to a separate document, there shouldn't be any, right? If there is, it would be helpful to know which sections these pertain to (CGA parts or something else). So, this is IMHO actually a pretty important thing to do. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Feb 19 10:14:49 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22523 for ; Thu, 19 Feb 2004 10:14:48 -0500 (EST) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1JFEnAh000229 for ; Thu, 19 Feb 2004 16:14:49 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 16:14:49 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FGMCMA0H; Thu, 19 Feb 2004 16:16:14 +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 i1JFEkXA002737; Thu, 19 Feb 2004 16:14:46 +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 i1JFCsIt015988; Thu, 19 Feb 2004 16:12:54 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1JFCsGc015987; Thu, 19 Feb 2004 16:12:54 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep20-app.kolumbus.fi (fep20-0.kolumbus.fi [193.229.0.47]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1JFCrIt015983 for ; Thu, 19 Feb 2004 16:12:53 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040219151252.HJRW15980.fep20-app.kolumbus.fi@kolumbus.fi>; Thu, 19 Feb 2004 17:12:52 +0200 Message-ID: <4034D1FC.6040802@kolumbus.fi> Date: Thu, 19 Feb 2004 17:10:52 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: SEND WG Subject: Re: issue 52 - nd vs. send response model 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 X-OriginalArrivalTime: 19 Feb 2004 15:14:49.0424 (UTC) FILETIME=[1DD52D00:01C3F6FB] Content-Transfer-Encoding: 7bit Pekka Savola wrote: >>In any case, I added this text to Section 5.3.3: >> >> Note that routers may decide to send a multicast >> advertisement to all nodes instead of a response to a >> specific host. In such case the router MAY still include the >> nonce value for the host that triggered the multicast >> advertisement. > > > This seems basically good -- with the caveat that if the router does > not include the nonce, the advertisement may end up being ignored by > SEND nodes, right? Right. Add "Omitting the nonce value may, however, cause the host to ignore the router's advertisement, unless the clocks in these nodes are sufficiently synchronized so that timestamps can be relied on." Assigned issue #67. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jari.arkko@lmf.ericsson.se Thu Feb 19 10:53:15 2004 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 KAA24457 for ; Thu, 19 Feb 2004 10:53:14 -0500 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1JFrFYG000604 for ; Thu, 19 Feb 2004 16:53:15 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 16:53:14 +0100 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 FGAL2HSS; Thu, 19 Feb 2004 16:53:14 +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 i1JFrDXA016703; Thu, 19 Feb 2004 16:53:13 +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 i1JFp2It026734; Thu, 19 Feb 2004 16:51:02 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i1JFp1hG026731; Thu, 19 Feb 2004 16:51:01 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep20-app.kolumbus.fi (fep20-0.kolumbus.fi [193.229.0.47]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i1JFp0It026683 for ; Thu, 19 Feb 2004 16:51:01 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040219155100.HPXY15980.fep20-app.kolumbus.fi@kolumbus.fi>; Thu, 19 Feb 2004 17:51:00 +0200 Message-ID: <4034DAEC.7030202@kolumbus.fi> Date: Thu, 19 Feb 2004 17:49:00 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: SEND WG Subject: Re: issue 54 - pekka's technical issues 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 X-OriginalArrivalTime: 19 Feb 2004 15:53:14.0547 (UTC) FILETIME=[7BCB0830:01C3F700] Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Hi, > > On Mon, 16 Feb 2004, Jari Arkko wrote: > >>Thanks for the comments. I think I took into account all of >>them except for the following: >> >>- Pad length being unnecessary. The pad lengths are explicit since >> there are variable length fields. For instance, the Trust Anchor >> option has a name which may end at an 8-octet boundary. We could pad >> with zero bytes, but I feel better about an explicit pad length >> field. Similarly, the Signature and Certificate options have >> complicated ASN.1 data, and it may be easier to have an explicit >> field than to determine it from the encoding of a field. > > > I'm not sure if I understand your reasoning. You seem to be saying > that it's important to get the exact length of the ASN.1 encoded data, > before decoding the data. Note that you can already get the rough > estimate -- which is enough e.g. for buffer allocation purposes, I'd > guess -- from Length field; this will include 0-7 bytes of zero > padding at the end. > > I certainly don't see problems with implicit zero padding when the > data falls on alignment boundaries; I think using such is extremely > commonplace in IETF specs. > > So, I still think that Pad Length appears to be unnecessary. On the > other hand, it MIGHT be necessary if you would have to be able to > allocate the exact size of memory for storing the data before decoding > the data. But 0-7 bytes of overhead here doesn't seem to be worth the > trouble.. My thinking was not based on buffer allocations. I agree that those are a non-issue. I was mainly thinking of how to find the end of a field followed by implicit padding. For instance, I'm was sure if the zero byte appears in some international character set schemes. But I guess not, that would break all C programs ;-) Anyway, zeros can appear in ASN.1 and binary encoded data. The question is thefore which of the following cases we have: (1) Variable length field has no length indication, explicitly or implicitly. In this case we must provide the length field either for this or for the padding that cames after it. (2) There is length information embedded in e.g. the ASN.1 encoding. In this case we can have either (a) length in the ASN.1 level only or (b) length in both the ASN.1 and our packet level. I think you are saying that you'd prefer (2a) over (2b). I think I agree on that now. I just would like to be assured that we don't have case (1) anywhere. Anyone familiar with the encoding of digital signatures care to comment? >>- Nonces being required for senders but the lack of a nonce can in >> some cases be ignored by receivers. I was unsure about this >> one. Perhaps Pekka N can explain as this part of the text came from >> him, I think. But I would classify this under "be conservative what >> you send, liberal what you accept". > > > Fine with me. Great! >>- IPR notices applying to an old draft version and name. I know. I > > So, this is IMHO actually a pretty important thing to do. I have requested an update. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.