From jari.arkko@lmf.ericsson.se Mon Sep 1 02:57:27 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04158 for ; Mon, 1 Sep 2003 02:57:26 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h816qUAv010580; Mon, 1 Sep 2003 08:52:31 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Q9LPTVTB; Mon, 1 Sep 2003 08:52:30 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h816qTxa023986; Mon, 1 Sep 2003 08:52:29 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h816nvme012744; Mon, 1 Sep 2003 08:49:57 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h816nvI0012742; Mon, 1 Sep 2003 08:49:57 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mx.laposte.net (mx.laposte.net [213.30.181.11]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h816nume012734 for ; Mon, 1 Sep 2003 08:49:56 +0200 (MET DST) Received: from gbl-dhcp-198-236.europe.research.sun.com (194.2.198.236) by mx.laposte.net (6.0.053) (authenticated as julien.laganier@laposte.net) id 3F4B3BA4001991E1; Mon, 1 Sep 2003 08:49:44 +0200 From: Julien Laganier To: "James Kempf" , Subject: Re: Issue 14: Is CGA-only RD protection useful? Date: Mon, 1 Sep 2003 08:48:19 +0200 User-Agent: KMail/1.5.3 References: <030401c36b3a$b57a1d20$806015ac@dclkempt40> In-Reply-To: <030401c36b3a$b57a1d20$806015ac@dclkempt40> Cc: alper@docomolabs-usa.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200309010848.19638.julien.laganier@laposte.net> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 25 August 2003 20:57, James Kempf wrote: > Issue 14 received some discussion in Vienna. The question was raised by one > of the reviewers whether having CGA-only protection on RAs would be > sufficient for securing router discovery. This is independent of whether a > router would use CGA for neighbor discovery. (...) > The protection provided by CGAs is fairly simple: a receiver of a message > signed by the sender and verifiable with the sender's public key has the > assurance that the message was, in fact, sent from the CGA. > > In the absence of any network element or any additional processing between > the router and the host, CGAs would seem insufficient to address all the > threats above, though they would address 2, since the victim could clearly > identify that the bogus RA did not issue from the legitimate default > router. A malicious host could construct a CGA from its public key and use > its private key to sign a bogus RA. The RA would be verifiable as issuing > from the correct IPv6 address, but the RA would contain bogus information > designed to launch an attack. Since there is no IP network element between > the host and the router in the standard IP subnet architecture, this would > suggest that CGA-only RD authentication is not sufficient to address all > the threats. > > If, however, there exists a Layer 2 network element between the host and > the router that is programmable such that it can perform sufficient Layer 3 > processing to cryptographically verify the RA signature and filter on the > CGA, then CGA-only RA security may be useful. The Layer 2 network element > could be programmed with an ACL of CGAs for known good routers, and only > pass RAs for those whose CGAs match the signatures and the ACL. Depending > on the Layer 2 technology and the network element, some part of the subnet > may still be vulnerable. For example, if the Layer 2 technology was > multi-access prior to the filtering device, some number of hosts may be > exposed to the bogus RA. Note that such a filtering device would still be > subject to attack if CGAs were not employed, since the device could not > verify the RA as issuing from the source address, providing an opening for > an attacker. Another benefits of CGA-only protection for RA can be some sort of opportunistic security: If there is several on-link routers that send RA's, the node has the ability to distinguish them based on their CGA's. Hence it may be possible of classifying contradictory routers and try to measure the connectivity they provide to select best performers and ignore their contradictors. For example if two routers advertize a default route, a node may try to communicate with a trusted remote host (its HA for instance) to see which of the two routers really forward packets to its HA. It is certainly not very secure, but by leveraging on the routing infrastructure it may be better than nothing (for example when there is no certs for DCC, like in ad-hoc set-up). Therefore, I suggest that the WG follows the following direction: > B) As a practical matter, some Layer 2 technologies of interest support > such filtering devices, and adding the kind of Layer 3 filtering and > network management functions described above to such devices for CGA-only > protection is not all that difficult. Since a CGA-only solution may be > simpler from a deployment and network management perspective in some > networks than requiring routers to have certificates, the CGA-only solution > should be fully articulated in a separate section in the draft. And perhaps mentions that measuring connectivity as a way of using CGA-only RA's protection in ad-hoc set-up? Thanks, --julien -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Sep 7 20:38:37 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22044 for ; Sun, 7 Sep 2003 20:38:37 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h880YZAv012745; Mon, 8 Sep 2003 02:34:35 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNQGV5B; Mon, 8 Sep 2003 02:35:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h880YOxR016573; Mon, 8 Sep 2003 02:34:26 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h880UWme026371; Mon, 8 Sep 2003 02:30:32 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h880UVgv026367; Mon, 8 Sep 2003 02:30:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h880USme026332 for ; Mon, 8 Sep 2003 02:30:30 +0200 (MET DST) Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L0F2XON8KC8WWKCH@vaxh.its.monash.edu.au> for IETF-SEND@standards.ericsson.net; Mon, 8 Sep 2003 10:24:05 +1000 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 1304E23C005; Mon, 08 Sep 2003 10:24:05 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id EDE6216400E; Mon, 08 Sep 2003 10:24:04 +1000 (EST) Date: Mon, 08 Sep 2003 10:24:04 +1000 From: Greg Daley Subject: Re: Issue 14: Is CGA-only RD protection useful? To: James Kempf Cc: Alper Yegin , IETF-SEND@standards.ericsson.net Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F5BCC24.2000905@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <003f01c36cad$b1de6530$806015ac@dclkempt40> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, Sorry for my long delay in responding. I think that we have to avoid using CGA only RAs at all costs. The issue is that the Host doesn't know that the RA is genuine, rather than that the network doesn't, therefore any solutions whereby devices in the network access list RAs from known good CGA sources do not address the issue: That the RA doesn't contain enough information when it arrives at the MN to guarantee its validity. One difficulty comes in several wireless environements where a host is on the same cell as an attacker and the RA is visible directly from the wireless link. While this is not necessarily unsolvable in current wireless systems, it is irksome to have to worry about wireless link effects in a security system. More importantly, when a host moves to another cell which doesn't support this filtering. How do we know that we're only receiving white-listed RAs? The RA has to contain some authentication information to communicate its authoritas to the host. This is where the concept of Delegation Chains emerged from in the first place. Please don't put CGA only RAs into a solution. I think it's a solution looking for a problem. Greg (I think that's a vote for A) -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 8 11:04:49 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29024 for ; Mon, 8 Sep 2003 11:04:49 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h88Ex3Av017986; Mon, 8 Sep 2003 16:59:03 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNCMSKL; Mon, 8 Sep 2003 17:00:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h88EwlxR025123; Mon, 8 Sep 2003 16:58:47 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88ErZme024114; Mon, 8 Sep 2003 16:53:35 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h88ErZA7024111; Mon, 8 Sep 2003 16:53:35 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-1.kolumbus.fi [193.229.5.121]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88ErXme024097 for ; Mon, 8 Sep 2003 16:53:33 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep21-app.kolumbus.fi with ESMTP id <20030908145333.QZYY17285.fep21-app.kolumbus.fi@kolumbus.fi>; Mon, 8 Sep 2003 17:53:33 +0300 Message-ID: <3F5C9733.1020408@kolumbus.fi> Date: Mon, 08 Sep 2003 17:50:27 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: greg.daley@eng.monash.edu.au, Alper Yegin , IETF-SEND@standards.ericsson.net Subject: Re: Issue 14: Is CGA-only RD protection useful? References: <003f01c36cad$b1de6530$806015ac@dclkempt40> <3F5BCC24.2000905@eng.monash.edu.au> In-Reply-To: <3F5BCC24.2000905@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I don't really believe in the filtering approach. The main reason in my opinion for the possible use of CGAs for RAs would be the opportunistic security that was mentioned by Julien. However, at this point we do not really have a specific mechanism on the table to handle all the details of this opportunistic scheme. We had some proposals before the WG was formed, but nothing very detailed. Anyway, while this is certainly useful, it is also something that we could easily do later. So here's what I would propose: I think in Vienna we agreed that its OK to use CGA with certs for RAs, e.g. to avoid stealing the other routers address. But for the CGA-only case, we should leave it out from the spec. If we want to, we can revisit this and create an "ad hoc network SEND extension" later. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 8 11:16:44 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29397 for ; Mon, 8 Sep 2003 11:16:43 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h88FDb31013284; Mon, 8 Sep 2003 17:13:37 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNWX6PP; Mon, 8 Sep 2003 17:13:27 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h88FDNxR026120; Mon, 8 Sep 2003 17:13:23 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88FA7me027009; Mon, 8 Sep 2003 17:10:07 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h88FA7hV027005; Mon, 8 Sep 2003 17:10:07 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-1.kolumbus.fi [193.229.5.121]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88FA6me026992 for ; Mon, 8 Sep 2003 17:10:06 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep21-app.kolumbus.fi with ESMTP id <20030908151005.RELM17285.fep21-app.kolumbus.fi@kolumbus.fi>; Mon, 8 Sep 2003 18:10:05 +0300 Message-ID: <3F5C9B13.1020405@kolumbus.fi> Date: Mon, 08 Sep 2003 18:06:59 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: SEND WG Subject: Re: issue 18: aaa interactions References: <200308220814.h7M8EhHN010627@givry.rennes.enst-bretagne.fr> In-Reply-To: <200308220814.h7M8EhHN010627@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > Now, I've been thinking about this a little bit. > If this is *only* about the discovery of the cert chains > > => no, my idea is that there are some interactions between AAA systems > and SEND, and the discovery of the cert chains should likely be one > of them. Fair enough. I agree that there might be more such interactions. (Of course, we need to decide what to write in the current document.) > via AAA, then it might be that, for instance, the 802.11 > link layer authentication process has already learned > something about the network's certificates. For instance, > if 802.11 is running EAP TLS, and the authentication is > terminated directly at the AP/router, then the host already > > => you don't need a "termination": local SEND and local AAA > can share some parts of the chains, the root for instance. Yes. > has the cert chain from a trusted root to the router. > > In any case, to move forward my proposal is that we simply > add some text explaining that as a side effect of attaching > > => I'd like to see the acronym AAA somewhere. Sufficient as an example? I may have trouble putting in anything else than an example, given that we don't have specific SEND-related procedures for AAA. But we can certainly write something about certificate chain or partial chain sharing with network access AAA. Would that work for you? --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 8 11:21:08 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29479 for ; Mon, 8 Sep 2003 11:21:07 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h88FIZ31014366; Mon, 8 Sep 2003 17:18:36 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNQ386P; Mon, 8 Sep 2003 17:19:55 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h88FIYxa027203; Mon, 8 Sep 2003 17:18:34 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88FFjme028535; Mon, 8 Sep 2003 17:15:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h88FFj14028534; Mon, 8 Sep 2003 17:15:45 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-1.kolumbus.fi [193.229.5.121]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88FFime028524 for ; Mon, 8 Sep 2003 17:15:44 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep21-app.kolumbus.fi with ESMTP id <20030908151543.RFZF17285.fep21-app.kolumbus.fi@kolumbus.fi>; Mon, 8 Sep 2003 18:15:43 +0300 Message-ID: <3F5C9C65.20901@kolumbus.fi> Date: Mon, 08 Sep 2003 18:12:37 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: ietf-send@standards.ericsson.net Subject: Re: Issue 21: RA source is Link Local References: <027101c36b2a$c2e7b770$806015ac@dclkempt40> In-Reply-To: <027101c36b2a$c2e7b770$806015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James Kempf wrote: > RFC 2461 requires that RAs be sent with a Link Local address. Issue 21 is > whether the same restriction should be put on DCA. > > Proposed solution: yes. Agreed. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 8 11:26:17 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29546 for ; Mon, 8 Sep 2003 11:26:16 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h88FNdAv024431; Mon, 8 Sep 2003 17:23:39 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNQ30WM; Mon, 8 Sep 2003 17:24:59 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h88FNbxR026775; Mon, 8 Sep 2003 17:23:37 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88FKOme029258; Mon, 8 Sep 2003 17:20:24 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h88FKORR029257; Mon, 8 Sep 2003 17:20:24 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-1.kolumbus.fi [193.229.5.121]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88FKNme029250 for ; Mon, 8 Sep 2003 17:20:23 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep21-app.kolumbus.fi with ESMTP id <20030908152022.RHHN17285.fep21-app.kolumbus.fi@kolumbus.fi>; Mon, 8 Sep 2003 18:20:22 +0300 Message-ID: <3F5C9D7C.4000900@kolumbus.fi> Date: Mon, 08 Sep 2003 18:17:16 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: James Kempf , ietf-send@standards.ericsson.net Subject: Re: Issue 21: RA source is Link Local References: <027101c36b2a$c2e7b770$806015ac@dclkempt40> <3F4AF7DD.2010608@eng.monash.edu.au> <00b601c36bea$9fd8a300$806015ac@dclkempt40> <3F529686.50205@eng.monash.edu.au> In-Reply-To: <3F529686.50205@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Greg Daley wrote: > I'd prefer that there's really only one mechanism > required to ensure link-only reach of the DCA, though, > if it is sufficient. I think we are doing more than just ensuring the packets don't go out of the link. We are also trying to design the protocol so that it deviates from IPv6 as little as possible. So, while technically not really so useful, the link local rule is there just to follow the other RD messaging model of the router. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 8 11:29:24 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29631 for ; Mon, 8 Sep 2003 11:29:23 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h88FQo31016057; Mon, 8 Sep 2003 17:26:54 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNCM6ZH; Mon, 8 Sep 2003 17:27:59 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h88FQnxR026947; Mon, 8 Sep 2003 17:26:49 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88FO1me029705; Mon, 8 Sep 2003 17:24:01 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h88FO1Fm029704; Mon, 8 Sep 2003 17:24:01 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-1.kolumbus.fi [193.229.5.121]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88FO0me029696 for ; Mon, 8 Sep 2003 17:24:00 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep21-app.kolumbus.fi with ESMTP id <20030908152359.RIIE17285.fep21-app.kolumbus.fi@kolumbus.fi>; Mon, 8 Sep 2003 18:23:59 +0300 Message-ID: <3F5C9E55.3000603@kolumbus.fi> Date: Mon, 08 Sep 2003 18:20:53 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: ietf-send@standards.ericsson.net Subject: Re: Issue 24: Does 802.1X help against issues not handled in SEND? References: <024801c36836$562e6670$806015ac@dclkempt40> In-Reply-To: <024801c36836$562e6670$806015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James Kempf wrote: > Issue 24 was raised by one of the reviewers: > > >>> - 13.1 Threats to the Local Link Not Covered by SEND (comment) >>> >>> To protect against such attacks, >>> link layer security MUST be used. An example of such for 802 type >>> networks is port-based access control [34]. >> >> => can you explain how 802.1X or any link-layer security can help here? >> I claim that you have no way in the layer 2 or 3 themselves to protect >> the layer 2 - layer 3 address binding! The only thing that SEND gives >> is the attacker must be a node one trusts. > > > Specifically, the attack that is mentioned in the Security Considerations > section is: > > >> On an insecure link layer that >> allows nodes to spoof the link layer address of other nodes, an >> attacker could disrupt IP service by sending out a Neighbor >> Advertisement having the source address on the link layer frame of a >> victim, a valid CGA with valid AH signature corresponding to itself, >> and a Target Link-layer Address extension corresponding to the >> victim. The attacker could then proceed to cause a traffic stream to >> bombard the victim in a DoS attack. > > > The 802.1x standard [0] provides a mechanism by which a host can be > authenticated to a particular point of attachment to a LAN (called a "port" > in the standard). If the MAC on frames sent by a host does not correspond to > the MAC of the host originally authenticated to this port, then the point of > attachment drops the frames. Authorization to use the port is determined by > the MAC address of the host that originally authenticated to the port. The > way 802.1x protects against this attack is that, if a host authenticated to > a particular port attempts to spoof the MAC address of another host, the > port will drop the frames. Naturally, this requires that all ports by which > hosts can attach to the LAN use 802.1x authentication. In addition, this > won't work for shared media such as multiple hosts authenticated through the > same 802.11 AP (which acts as a single port for all hosts), but it will work > on 802.3 switched LANs. > > 802.1x does not provide protection for the layer 2 frame - layer 3 packet > address binding in traffic (that is, real time filtering to check this > binding), and neither does SEND. 802.1x provides authentication and > filtering of MAC address to port, SEND provides protection for the layer 2 - > layer 3 binding *information* in the ND packet, via the CGA address > (authorization to use the address via the public key) and the signature on > the packet (authentication of contents as from authorized IP address > possessor). > > IEEE is additionally starting some work on secure link layer (see: > http://www.ieee802.org/linksec/ > for more information) that might result in modifications to the 802 link > security architecture. These may possibly eliminate any residual threats. > > Comments? I agree with everything you have said above. But was there any proposed document change due to this? --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 8 11:46:54 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01761 for ; Mon, 8 Sep 2003 11:46:53 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h88Fhu31019549; Mon, 8 Sep 2003 17:44:00 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNCNA5G; Mon, 8 Sep 2003 17:45:05 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h88FhpxR028075; Mon, 8 Sep 2003 17:43:51 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88Fecme002753; Mon, 8 Sep 2003 17:40:38 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h88FecjN002752; Mon, 8 Sep 2003 17:40:38 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-1.kolumbus.fi [193.229.5.121]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88Febme002748 for ; Mon, 8 Sep 2003 17:40:37 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep21-app.kolumbus.fi with ESMTP id <20030908154037.RNEV17285.fep21-app.kolumbus.fi@kolumbus.fi>; Mon, 8 Sep 2003 18:40:37 +0300 Message-ID: <3F5CA23B.8070903@kolumbus.fi> Date: Mon, 08 Sep 2003 18:37:31 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi Eronen CC: SEND WG Subject: issue 10: sa configuration details Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pasi, In your review you made some comments about the SA configurations for SEND, and I sent in an initial response. I'm not sure I saw an answer to your (or it got lost among the Re: Approved e-mails). Anyway, you can review the discussion from http://www.piuha.net/~jarkko/publications/send/issues/issue10.txt And here's what I would propose: (1) Modify section 5.2.3 (draft-arkko-send-ndopt) so that it allows more than one trusted root. (2) Specify the "minbits" only for the final CGA keys (and hence restricted for RSA only). Avoid talking about the key sizes of trusted roots and intermediaries; proper key size usage is just one of the things that we expect from our CAs. We don't need to specify that in the protocol. Does this work for you? --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 8 14:21:01 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12178 for ; Mon, 8 Sep 2003 14:21:00 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h88IFdAv024336; Mon, 8 Sep 2003 20:15:39 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNC3KHH; Mon, 8 Sep 2003 20:16:49 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h88IFKxR006204; Mon, 8 Sep 2003 20:15:22 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88IBqme029801; Mon, 8 Sep 2003 20:11:52 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h88IBp2K029800; Mon, 8 Sep 2003 20:11:51 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88IBome029796 for ; Mon, 8 Sep 2003 20:11:50 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep06-app.kolumbus.fi with ESMTP id <20030908181044.YLA2570.fep06-app.kolumbus.fi@kolumbus.fi>; Mon, 8 Sep 2003 21:10:44 +0300 Message-ID: <3F5CC5AC.8090200@kolumbus.fi> Date: Mon, 08 Sep 2003 21:08:44 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont , SEND WG Subject: issue 23: mld details Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Francis, I'm trying to close the issue where you requested additional details on how MLD packets are sent: http://www.piuha.net/~jarkko/publications/send/issues/issue23.txt The clarification you requested was source address of MLD packets. Given the decision in IETF-57 about "ND layer" security, we appear to not have any new addresses. Thus I consider this issue closed. Unless you had some additional MLD interactions in mind? --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 8 14:25:39 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12405 for ; Mon, 8 Sep 2003 14:25:38 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h88INRAv025565; Mon, 8 Sep 2003 20:23:28 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNC3NF0; Mon, 8 Sep 2003 20:24:37 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h88INMxR006641; Mon, 8 Sep 2003 20:23:22 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88IKVme001877; Mon, 8 Sep 2003 20:20:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h88IKVLd001876; Mon, 8 Sep 2003 20:20:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h88IKTme001870 for ; Mon, 8 Sep 2003 20:20:29 +0200 (MET DST) Message-ID: <03a601c37635$e92bec60$956015ac@dclkempt40> From: "James Kempf" To: "Jari Arkko" Cc: References: <024801c36836$562e6670$806015ac@dclkempt40> <3F5C9E55.3000603@kolumbus.fi> Subject: Re: Issue 24: Does 802.1X help against issues not handled in SEND? Date: Mon, 8 Sep 2003 11:20:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I think the relevent text in this email could be included in the Security Considerations section. I interpert the reviewers' comments to mean the current text is not enough to clarify the point. jak ----- Original Message ----- From: "Jari Arkko" To: "James Kempf" Cc: Sent: Monday, September 08, 2003 8:20 AM Subject: Re: Issue 24: Does 802.1X help against issues not handled in SEND? > James Kempf wrote: > > Issue 24 was raised by one of the reviewers: > > > > > >>> - 13.1 Threats to the Local Link Not Covered by SEND (comment) > >>> > >>> To protect against such attacks, > >>> link layer security MUST be used. An example of such for 802 type > >>> networks is port-based access control [34]. > >> > >> => can you explain how 802.1X or any link-layer security can help here? > >> I claim that you have no way in the layer 2 or 3 themselves to protect > >> the layer 2 - layer 3 address binding! The only thing that SEND gives > >> is the attacker must be a node one trusts. > > > > > > Specifically, the attack that is mentioned in the Security Considerations > > section is: > > > > > >> On an insecure link layer that > >> allows nodes to spoof the link layer address of other nodes, an > >> attacker could disrupt IP service by sending out a Neighbor > >> Advertisement having the source address on the link layer frame of a > >> victim, a valid CGA with valid AH signature corresponding to itself, > >> and a Target Link-layer Address extension corresponding to the > >> victim. The attacker could then proceed to cause a traffic stream to > >> bombard the victim in a DoS attack. > > > > > > The 802.1x standard [0] provides a mechanism by which a host can be > > authenticated to a particular point of attachment to a LAN (called a "port" > > in the standard). If the MAC on frames sent by a host does not correspond to > > the MAC of the host originally authenticated to this port, then the point of > > attachment drops the frames. Authorization to use the port is determined by > > the MAC address of the host that originally authenticated to the port. The > > way 802.1x protects against this attack is that, if a host authenticated to > > a particular port attempts to spoof the MAC address of another host, the > > port will drop the frames. Naturally, this requires that all ports by which > > hosts can attach to the LAN use 802.1x authentication. In addition, this > > won't work for shared media such as multiple hosts authenticated through the > > same 802.11 AP (which acts as a single port for all hosts), but it will work > > on 802.3 switched LANs. > > > > 802.1x does not provide protection for the layer 2 frame - layer 3 packet > > address binding in traffic (that is, real time filtering to check this > > binding), and neither does SEND. 802.1x provides authentication and > > filtering of MAC address to port, SEND provides protection for the layer 2 - > > layer 3 binding *information* in the ND packet, via the CGA address > > (authorization to use the address via the public key) and the signature on > > the packet (authentication of contents as from authorized IP address > > possessor). > > > > IEEE is additionally starting some work on secure link layer (see: > > http://www.ieee802.org/linksec/ > > for more information) that might result in modifications to the 802 link > > security architecture. These may possibly eliminate any residual threats. > > > > Comments? > > I agree with everything you have said above. But was there any > proposed document change due to this? > > --Jari > > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Sep 10 12:59:16 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08072 for ; Wed, 10 Sep 2003 12:59:15 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8AGuC31014578; Wed, 10 Sep 2003 18:56:12 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNR2DWQ; Wed, 10 Sep 2003 18:57:37 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8AGtxxR027395; Wed, 10 Sep 2003 18:56:00 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8AGq8me020334; Wed, 10 Sep 2003 18:52:08 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8AGq8sM020333; Wed, 10 Sep 2003 18:52:08 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8AGq6me020328 for ; Wed, 10 Sep 2003 18:52:07 +0200 (MET DST) Message-ID: <015401c377bb$e6974990$956015ac@dclkempt40> From: "James Kempf" To: Subject: Resolution for Issue 24: Does 802.1X help against issues not handled by SEND Date: Wed, 10 Sep 2003 09:52:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Suggested resolution for Issue 24 is to include the following text as the second paragraph in the Security Considerations section: Specifically, the 802.1x standard [ref] provides a mechanism by which a host can be authenticated to a particular point of attachment to a LAN (called a "port" in the standard). If the MAC on frames sent by a host does not correspond to the MAC of the host originally authenticated to this port, then the point of attachment drops the frames. Authorization to use the port is determined by the MAC address of the host that originally authenticated to the port. The way 802.1x protects against this attack is that, if a host authenticated to a particular port attempts to spoof the MAC address of another host, the port will drop the frames. Naturally, this requires that all ports by which hosts can attach to the LAN use 802.1x authentication, and that all hosts physically attach through a port, as is the case with 802.3 switched LAN. For shared media such as multiple hosts authenticated through the same 802.11 AP (which acts as a single port for all hosts) other measures are necessary, since an attacker on the wireless link can spoof the MAC address of a victim on the same wireless link. 802.1x does not provide protection for the layer 2 frame - layer 3 packet address binding in traffic (that is, real time filtering to check this binding), and neither does SEND. 802.1x provides authentication and filtering of MAC address to port, SEND provides protection for the layer 2 - layer 3 binding information in the Neighbor Discovery packet, via the CGA address (authorization to use the address via the public key) and the signature on the packet (authentication of contents as from authorized IP address possessor). jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Sep 10 13:09:37 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08419 for ; Wed, 10 Sep 2003 13:09:36 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8AH8631016288; Wed, 10 Sep 2003 19:08:07 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNR2G64; Wed, 10 Sep 2003 19:09:32 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8AH7xxR028013; Wed, 10 Sep 2003 19:07:59 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8AH4dme023246; Wed, 10 Sep 2003 19:04:39 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8AH4YWR023245; Wed, 10 Sep 2003 19:04:34 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8AH4Vme023241 for ; Wed, 10 Sep 2003 19:04:32 +0200 (MET DST) Message-ID: <017001c377bd$a37b58c0$956015ac@dclkempt40> From: "James Kempf" To: Cc: "Russ Housley" Subject: Resolution of Issue 20: Francis Dupont's certificate issue and the general issue of a Certificate Profile Date: Wed, 10 Sep 2003 10:04:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit The email on proposed solutions to Issue 20 generated no comment from the WG. In the interest of having a unified IETF certificate profile for routing certificates, I'd suggest we go forward with proposal E: Support delegation through using the mechanism described in draft-ietf-pkix-x509, with perhaps some minor specification of conventions to satisfy SEND requirements. This will set up a normative reference dependency between the SEND drafts and draft-ietf-pkix-x509, requiring that draft to advance to PS before SEND does. Since I took the action item in Vienna to look into the cert profile, I will study draft-ietf-pkix-x509 and see whether any additional specification is required for SEND. If so, I will provide Jari with text describing it. If not, the section on the SEND certificate profile will have a single sentence, referring to draft-ietf-pkix-x509. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Sep 10 13:13:04 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08503 for ; Wed, 10 Sep 2003 13:13:03 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8AHB131016618; Wed, 10 Sep 2003 19:11:02 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SKNXLQM9; Wed, 10 Sep 2003 19:11:01 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8AHB0xR028182; Wed, 10 Sep 2003 19:11:00 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8AH8Cme023639; Wed, 10 Sep 2003 19:08:12 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8AH87SI023638; Wed, 10 Sep 2003 19:08:07 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8AH85me023622 for ; Wed, 10 Sep 2003 19:08:05 +0200 (MET DST) Message-ID: <017b01c377be$22bdedf0$956015ac@dclkempt40> From: "James Kempf" To: References: <003f01c36cad$b1de6530$806015ac@dclkempt40> <3F5BCC24.2000905@eng.monash.edu.au> <3F5C9733.1020408@kolumbus.fi> Subject: Proposed Resolution for Issue 14: Is CGA-only RD protection useful? Date: Wed, 10 Sep 2003 10:08:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit This issue generated lots of technical interesting technical discussion. I'd like to suggest that we resolve the issue with Jari's proposal: So here's what I would propose: I think in Vienna we agreed that its OK to use CGA with certs for RAs, e.g. to avoid stealing the other router's address. But for the CGA-only case, we should leave it out from the spec. If we want to, we can revisit this and create an "ad hoc network SEND extension" later. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 15 14:16:24 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16484 for ; Mon, 15 Sep 2003 14:16:23 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8FIB931029322; Mon, 15 Sep 2003 20:11:09 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SYV17HP1; Mon, 15 Sep 2003 20:11:21 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8FIB7xa007469; Mon, 15 Sep 2003 20:11:07 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8FI4tme002109; Mon, 15 Sep 2003 20:04:55 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8FI4tsL002108; Mon, 15 Sep 2003 20:04:55 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8FI4qme002103 for ; Mon, 15 Sep 2003 20:04:53 +0200 (MET DST) Message-ID: <037e01c37bb3$e5c9dcc0$956015ac@dclkempt40> From: "James Kempf" To: Subject: Resolution for Issue 21: RA Source is Link Local Date: Mon, 15 Sep 2003 11:05:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit There was some technical discussion about this but concensus seems to be having the SEND document specify Link Local to be consistent with RFC 2461 is appropriate. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 15 16:39:22 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25522 for ; Mon, 15 Sep 2003 16:39:21 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8FKZmAv017238; Mon, 15 Sep 2003 22:35:48 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SY7QKYGJ; Mon, 15 Sep 2003 22:37:25 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8FKZZxR022534; Mon, 15 Sep 2003 22:35:36 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8FKWHme028456; Mon, 15 Sep 2003 22:32:17 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8FKWH3X028455; Mon, 15 Sep 2003 22:32:17 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8FKWFme028438 for ; Mon, 15 Sep 2003 22:32:15 +0200 (MET DST) Message-ID: <043901c37bc8$7c31f3f0$956015ac@dclkempt40> From: "James Kempf" To: Subject: Issue 8: Certificate details review by Pasi and Valtteri Date: Mon, 15 Sep 2003 13:32:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Issue 8 concerns feedback from review board members Pasi and Valtteri, and it contains a variety of subissues. Considering we've decided to go with draft-ietf-pkix-x509-as-extn-01.txt instead of attribute certificates, some of the subissues have been superceded. I list the subissues below together with suggested resolutions. Please send comments and preferences if you have any. If you want to have deeper discussion on a particular subissue, please start a separate thread with the subissue number in the title. jak ------------------------------------------------ Issue 8a: "The certificate transport is relatively straight-forward, but the description of certificate chains could benefit from some clarifications and examples showing at least one valid certificate chain." Suggested resolution: Since jak has been primarily been handling certificates, he will try to come up with an example. Issue 8b: "Also, if certificates are used for both RD and non-CGA ND, any differences should be described (e.g., in the ND case, would a PKC chain ending in an iPAddress subjectAltName be sufficient, or do we also need the AC?)" Suggested resolution: 1) The example doesn't apply, since PKCs with the IP prefix and address range extensions as per draft-ietf-pkix-x509-as-extn will be used. 2) At the Vienna meeting, the WG decided to move non-CGA ND out of the base spec, since there are no longer any IPR considerations for CGA, so the issue doesn't apply to the base spec. Issue 8c: "Especially the selection of Attribute Authorities (valid AC issuers) seems a bit strange. The "trusted root" refers to valid PKC issuers, right? And then all CAs (PKC issuers) in the PKC path (from the trust anchor to the router's PKC) are also considered AAs. Unfortunately, RFC 3281 (section 4.5) explicitly forbids this! If this is done anyway, it should be at least well explained and justified. Another aspect that requires clarification is the requirements placed on the PKC chain. At the minimum, the spec should say what requirements are placed on subjectName, subjectAltName, and keyUsage. Preferably the spec should also give some recommendations for interoperability (see draft-ietf-ipsec-pki-profile-02 for example). Also, when specifying this, the SEND spec should probably refer to the PKIX profile (RFC 3280) rather than X.509 itself." Suggested resolution: Superceded by using draft-ietf-pkix-x509-as-extn. Issue 8d: "o Section 6.3 (editorial): In PKIX-speak, the correct term would probably be 'trust anchor', not 'trusted root'." Suggested resolution: Jari has said in an initial followup email that he will make the change. Issue 8e: "o Sections 6.3 and 6.6 (technical): Presumably, the 'trusted root' should contain the issuer of the first certificate in the chain But for X.509 certs, that's a Distinguished Name, not FQDN. So should the "trusted root" option contain a DER-encoded Issuer DN instead of FQDN? Using AltSubjectName (correct spelling is subjectAltName, BTW) seems to make it more difficult for the router to decide which certificate to send, since its own certificate doesn't necessarily have the CA's dNSName (though it may be included in issuerAltName extension). o Section 6.5.1: The definition of the Holder field is a bit vague, and goes against the recommendations of RFC3281 (if this intentional, at least the reasons for doing so should be documented). Our interpretation is that RFC3281, in this particular scenario would strongly recommend using the baseCertificateID syntax (instead of entityName or objectDigestInfo). Also, even if entityName or objectDigestInfo is used, RFC3281 recommends using only one of them, and recommends using only one entityName (not multiple), and says that if entityName is used, it MUST match the PKC certificate. o Section 6.5.1: If objectDigestInfo is used with digestedObjectType=publicKey, RFC3281 already specifies how objectDigest field must be calculated (section 7.3)." Suggested resolution: These issues are superceded by use of draft-ietf-pkix-x509-as-extn. Issue 8f: "o Section 6.5.1: Normative reference to an expired Internet-Draft (for the AuthorizedSubnetPrefix) probably isn't a good idea. Since it seems that the pkix-x509-ipaddr-as-extn draft is dead, either the relevant definitions should be copied here, or documented in a new, separate internet draft." Suggested resolution: The draft is not dead, it just passed through WG Last Call in the PKIX WG, and will be the basis for a certificate hierarchy for routing address range delegations, including for SEND, when it is approved by the IESG. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Sep 19 12:51:14 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14153 for ; Fri, 19 Sep 2003 12:51:08 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8JGmSAv002187; Fri, 19 Sep 2003 18:48:28 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SZF002YD; Fri, 19 Sep 2003 18:48:47 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8JGmRxa019591; Fri, 19 Sep 2003 18:48:27 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8JGixme008536; Fri, 19 Sep 2003 18:44:59 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8JGiwiK008535; Fri, 19 Sep 2003 18:44:58 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8JGiume008464 for ; Fri, 19 Sep 2003 18:44:57 +0200 (MET DST) Received: (qmail 18345 invoked from network); 19 Sep 2003 16:44:54 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail7.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Sep 2003 16:44:54 -0000 Date: Fri, 19 Sep 2003 09:44:53 -0700 Subject: Re: Issue 22: Part I: Handling ND cache getting full Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: SEND WG , Francis Dupont To: Pekka Nikander From: Jonathan Wood In-Reply-To: <3F6AD470.2030807@ericsson.com> Message-Id: <9824D422-EAC0-11D7-8725-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, September 19, 2003, at 03:03 AM, Pekka Nikander wrote: > > Now, while I agree that Francis' suggestion makes it clearer > when to accept new packets, I don't immediately see how it > helps with the cache getting full. On the other hand, if > we start dropping the cache entries with the oldest RDlast, > and at the same time temporarily reduce Delta so much that > the dropped entries would not be accepted again, that might > help. > I agree that this would help in a non-attack case, where you have a host talking with many other hosts with poorly sync'd clocks. However... Maybe I just need some coffee this morning, but I still don't see how this would prevent an attack. Even if you reduce the delta to a pretty small value, on many link layers an attacker should still be able to flush a victim's cache in less than 1 second, (for example, by using a large number of pre-computed CGAs and flooding the victim with NS msgs) and then execute a replay attack. What am I missing? -Jon -------------------------------------------------------------------- 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 Sep 20 09:37:53 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03327 for ; Sat, 20 Sep 2003 09:37:47 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8KDV731012698; Sat, 20 Sep 2003 15:31:08 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SZGAG8G8; Sat, 20 Sep 2003 15:31:29 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8KDV6xa026676; Sat, 20 Sep 2003 15:31:06 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8KDRQme009892; Sat, 20 Sep 2003 15:27:26 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8KDRQDt009877; Sat, 20 Sep 2003 15:27:26 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-1.kolumbus.fi [193.229.5.121]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8KDROme009856 for ; Sat, 20 Sep 2003 15:27:24 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep21-app.kolumbus.fi with ESMTP id <20030920132724.RYSA17285.fep21-app.kolumbus.fi@kolumbus.fi>; Sat, 20 Sep 2003 16:27:24 +0300 Message-ID: <3F6C54F0.9000504@kolumbus.fi> Date: Sat, 20 Sep 2003 16:24:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG , Francis Dupont Subject: Re: Issue 22: Part I: Handling ND cache getting full References: <3F6AD470.2030807@ericsson.com> <3F6ADD6D.30407@ericsson.com> In-Reply-To: <3F6ADD6D.30407@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > new message. However, the new message will not pass > the check since apparently her clock has drifted more than > what is allowed. That is, (RDnew - RDlast) is small due > to the replayed message from which RDlast was recorded, > but TSnew - TSlast will be much larger, since TSlast was > the timestamp in the replayed message. > > Consequently, I propose that we remove the latter check > from the second rule, allowing TSnew to be any much larger > than TSlast. I don't see this opening any new attacks, > and it fixes the scenario above. At first I thought it was more serious, but the rule for new nodes limits the starting time to be within Delta of the real time. If that had not been the case, an attacker could have replayed any old message, and made it impossible for the real node to communicate using its current time value. Still, even with the new node rule we have the possibility that the Delta difference is larger than the Drift difference, making the attack you mention possible. I agree about the the fix that you propose. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Sep 20 09:49:33 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03579 for ; Sat, 20 Sep 2003 09:49:32 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8KDlw31013828; Sat, 20 Sep 2003 15:47:58 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SYVYKZ8T; Sat, 20 Sep 2003 15:50:05 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8KDlvxa026845; Sat, 20 Sep 2003 15:47:57 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8KDiime009028; Sat, 20 Sep 2003 15:44:44 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8KDihuK009022; Sat, 20 Sep 2003 15:44:43 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-1.kolumbus.fi [193.229.5.121]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8KDigme008992 for ; Sat, 20 Sep 2003 15:44:42 +0200 (MET DST) Received: from kolumbus.fi ([62.248.171.109]) by fep21-app.kolumbus.fi with ESMTP id <20030920134442.SBAP17285.fep21-app.kolumbus.fi@kolumbus.fi>; Sat, 20 Sep 2003 16:44:42 +0300 Message-ID: <3F6C58FF.3060102@kolumbus.fi> Date: Sat, 20 Sep 2003 16:41:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: SEND WG , Francis Dupont Subject: Re: Issue 22: Part 2: Timestamp Delta time References: <3F6ADBE9.6010209@ericsson.com> In-Reply-To: <3F6ADBE9.6010209@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Issue 22 deals with timestamp validity period and avoiding a > cache filling DoS attack. For background, see > http://www.arkko.com/publications/send/issues/issue22.txt > > My (perhaps flawed) analysis of the issue boils down to > two points: > > 1. The value for the timestamp delta > > 2. What to do if the ND cache becomes full > > I'll describe these separate messages, focusing on the > the Delta time here. > ----------------------------------------------------------------- > > The current specifications states the following > > > Recommended default value for the allowed Delta is 3,600 seconds. > > Francis Dupond made a comment that this is far too large. > > The function of the Delta value can be described as follows: > > - A larger Delta allows hosts with differently running > clocks to communicate, while a small Delta requires > better clock synchronization. > > - A larger Delta potentially requires more memory, since > it may require the host to remember more other hosts. > > - A larger Delta exposes the host to replay attacks in the > case that its cache becomes full, thereby requiring it > to accept ND messages from new hosts. > > The situation that seems to be most worrisome is one where > an attacker fulfils the cache, thereby forcing the host to > drop some cache entries, and then launches a replay attack. > > It looks like the suggestion in the Part 1 message of this > issue plugs the attack. If so, the exact value of Delta > is not a concern from the memory usage and DoS/replay attack > point of view. I agree with Jon that it seems like it is still possible to fill the cache. The point is that attackers can come up with new (perhaps precomputed) CGA addresses, and the timestamp cache needs to be per source in multicast messages. Tuomas' CGA generation formula does prevent the attack if Sec > 0, but we may not be able to rely on that, or can we? But there seems to be two ways to deal with unbounded caches, like the ones that exist for tracking something related to a the source address of a packet. 1. Throw out entries. 2. Reduce the allowed clock difference. In the past, I have assumed we are doing #2. Though I can't claim I have thought it through fully. Here's what #2 would do: if there is no lack of space, accept all messages and store all cache entries that have used a timestamp within Delta. If you can store only half of the entries that would be required for this, reduce Delta to half and remove those entries that were furthest away from the node's own time. If the attacker is sending you a constant stream of messages from new source addresses with exactly the right time, reduce Delta to 0. At this point, you can still communicate with legitimate peers, but only if they have exactly the same clock as you do. When new space becomes available, Delta can again be increased. Does this work? You tell me... --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 22 07:39:45 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10664 for ; Mon, 22 Sep 2003 07:39:45 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8J8T531004465; Fri, 19 Sep 2003 10:29:05 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SY7RYNBG; Fri, 19 Sep 2003 10:30:55 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8J8SmxR006104; Fri, 19 Sep 2003 10:28:48 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8Pome000218; Fri, 19 Sep 2003 10:25:50 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8J8Popi000215; Fri, 19 Sep 2003 10:25:50 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8Pnme000200 for ; Fri, 19 Sep 2003 10:25:49 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 67B4425 for ; Fri, 19 Sep 2003 11:39:10 +0300 (EEST) Message-ID: <3F6ABD8D.2030001@ericsson.com> Date: Fri, 19 Sep 2003 11:25:49 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Test6, please ignore Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit [I have had lots of trouble sending mail to this mailing list. Expect a number of tests to see if things work now. --Pekka] -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 22 07:39:44 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10662 for ; Mon, 22 Sep 2003 07:39:42 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8J8TN31004543; Fri, 19 Sep 2003 10:29:23 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SY7RYND7; Fri, 19 Sep 2003 10:31:13 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8J8TMxR006133; Fri, 19 Sep 2003 10:29:22 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8QSme000677; Fri, 19 Sep 2003 10:26:28 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8J8QSKX000667; Fri, 19 Sep 2003 10:26:28 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8QQme000640 for ; Fri, 19 Sep 2003 10:26:27 +0200 (MET DST) Received: from hut.fi (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 48E0325 for ; Fri, 19 Sep 2003 11:39:48 +0300 (EEST) Message-ID: <3F6ABDB3.6090607@hut.fi> Date: Fri, 19 Sep 2003 11:26:27 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Test8, please ignore Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit [I have had lots of trouble sending mail to this mailing list. Expect a number of tests to see if things work now. --Pekka] -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 22 08:21:47 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11996 for ; Mon, 22 Sep 2003 08:21:47 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8JA7R31004057; Fri, 19 Sep 2003 12:07:31 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SY7RZT9W; Fri, 19 Sep 2003 12:09:18 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8JA7DxR011387; Fri, 19 Sep 2003 12:07:14 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8JA3Tme012809; Fri, 19 Sep 2003 12:03:29 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8JA3TkG012802; Fri, 19 Sep 2003 12:03:29 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8JA3Rme012788 for ; Fri, 19 Sep 2003 12:03:27 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id ABFE926; Fri, 19 Sep 2003 13:16:48 +0300 (EEST) Message-ID: <3F6AD470.2030807@ericsson.com> Date: Fri, 19 Sep 2003 13:03:28 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Francis Dupont Subject: Issue 22: Part I: Handling ND cache getting full Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Issue 22 deals with timestamp validity period and avoiding a cache filling DoS attack. For background, see http://www.arkko.com/publications/send/issues/issue22.txt My (perhaps flawed) analysis of the issue boils down to two points: 1. The value for the timestamp delta 2. What to do if the ND cache becomes full I'll describe these separate messages, focusing on the full cache situation here. ----------------------------------------------------------------- The current specifications states the following > o If the cache becomes full, the receiver SHOULD temporarily reduce > the Delta value for that source address so that all messages > within that value can still be stored. Francis Dupont has proposed an alternative method for handling the situation. Trying to rephrase his suggestion: o Per each peer, store the following information: * the receive time of the last received ND message (RDlast) * the time stamp in the last received ND message (TSlast) o When a message is received from a new peer, i.e. one that is not stored in the cache, the received timestamp is checked and the packet is accepted if the timestamp is recent enough: -Delta < RDnew - TSnew < +Delta where RDnew is the local time of the received packet delivery and TSnew is the timestamp in the new packet. A new cache entry is created if the other checks, including the signature check, are passed. o When a message is received from a known peer, i.e. one that has an entry in the cache, the time stamp is checked against the last received message: TSnew > TSlast + (RDnew - RDlast) x (1 - drift) TSnew < TSlast + (RDnew - RDlast) x (1 + drift) The suggested value for /drift/ is 10%, allowing clock skew of at most 10% between the hosts. If TSnew < TSlast, which is possible if packets arrive rapidly and out of order, TSlast MUST NOT be updated, i.e., the stored TSlast for a given host MUST NOT ever decrease. Now, while I agree that Francis' suggestion makes it clearer when to accept new packets, I don't immediately see how it helps with the cache getting full. On the other hand, if we start dropping the cache entries with the oldest RDlast, and at the same time temporarily reduce Delta so much that the dropped entries would not be accepted again, that might help. Opinions? Any flaws in my analysis? --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 22 08:29:00 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10666 for ; Mon, 22 Sep 2003 07:39:46 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8J8f231008113; Fri, 19 Sep 2003 10:41:02 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SY7RYR7L; Fri, 19 Sep 2003 10:42:52 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8J8eqxR006716; Fri, 19 Sep 2003 10:40:52 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8bVme009814; Fri, 19 Sep 2003 10:37:31 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8J8bVEb009810; Fri, 19 Sep 2003 10:37:31 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8bTme009800 for ; Fri, 19 Sep 2003 10:37:29 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id E388C26 for ; Fri, 19 Sep 2003 11:50:50 +0300 (EEST) Message-ID: <3F6AC04A.6070601@ericsson.com> Date: Fri, 19 Sep 2003 11:37:30 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Re: V2: IETF57 SEND WG meeting summary References: <3F1535AD.1040108@nomadiclab.com> In-Reply-To: <3F1535AD.1040108@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit [An old message re-resent; this never came through.] This is an update to the IETF57 SEND WG meeting summary, tracking process. > Action items > ------------ > > AP1. Re-charter > AP owner: Chairs > Target date: July 18 Late. Pending AD approval. > AP2. ML discussion: Should we allow CGA only RD? > - the WG decided that CGA + certs is to be used for RD > - it is unclear weather we should allow CGA only RD > (http://www.piuha.net/~jarkko/publications/send/issues/issue14.txt) > AP owner: Chairs > Target date: to completed before mid August Completed: CGA only RD not in spec. > AP3. Suggestion to the ML: Revised timestamp format > (http://www.piuha.net/~jarkko/publications/send/issues/issue6.txt) > AP owner: Jari Arkko > Target date: mid August Completed: Adopted Michael Richardson's proposal. > AP4. Proposal for dealing with AC certificates in RD > (http://www.piuha.net/~jarkko/publications/send/issues/issue8.txt) > AP owner: James Kempf and Pekka Nikander > Target date: early September Completed: While issue 8 is formally open, this AP itself seems to be completed with the resolution of issue 20. > AP5. Next version of draft-ietf-send-cga > AP owner: Tuomas Aura > Target date: early August Completed: Thanks, Tuomas! > AP6. Next version of draft-arkko-send-ndopts, as a WG draft > draft-ietf-send-ndopts-00.txt > AP owner: Jari Arkko > Target date: end of August Late. Pending rechartering (AP1). > AP7. WG LC on draft-ietf-send-cga > AP owner: Chairs > Target date: September On time. Open. > AP8. WG LC on draft-ietf-send-ndopts > AP owner: Chairs > Target date: October On time. Open. > AP9. Get a new document editor for draft-arkko-send-ndopts > starting from September; Jari Arkko will have an > extended leave > AP owner: Chairs > Target date: beginning of September Late. I have promised to take over from Jari, if needed, but I'd prefer to see someone else to volunteer. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 22 08:29:01 2003 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10668 for ; Mon, 22 Sep 2003 07:39:46 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8J8bn31007122; Fri, 19 Sep 2003 10:37:49 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SYVF5D09; Fri, 19 Sep 2003 10:38:14 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8J8bhxR006533; Fri, 19 Sep 2003 10:37:43 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8Yeme007856; Fri, 19 Sep 2003 10:34:40 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8J8Ye34007853; Fri, 19 Sep 2003 10:34:40 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8Ybme007828 for ; Fri, 19 Sep 2003 10:34:37 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id E450225 for ; Fri, 19 Sep 2003 11:47:58 +0300 (EEST) Message-ID: <3F6ABF9D.2030603@ericsson.com> Date: Fri, 19 Sep 2003 11:34:37 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-send@standards.ericsson.net Subject: Re: Resolution of Issue 20: Francis Dupont's certificate issue and the general issue of a Certificate Profile References: <017001c377bd$a37b58c0$956015ac@dclkempt40> In-Reply-To: <017001c377bd$a37b58c0$956015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit [An old message resent; this never game through.] James Kempf wrote: > The email on proposed solutions to Issue 20 generated no > comment from the WG. After having thought about this for quite a while, and considering the long and short term pros and cons of different approaches, I have come to the following conclusions: > A) We could ignore prefix delegation and even prefix certification ' > entirely, and just have the host certify the router's identity. A) would be pretty bad from the security point of view, and it would not fulfil many of the goals in the psreq draft. > B) We could ignore prefix delegation but provide support for prefix > certification by using Attribute Certificates, B) would be acceptable to me. On the other hand, we would have to understand the scalability consequences. > C) We could support delegation using a parallel Attribute > Certificate chain, along with the Identity Certificate chain. C) would be close to the "right" approach, but result in very complex operations in the hosts. I don't like that kind of unnecessary complexity. > D) We could talk to Russ and Steve Bellovin about opening up > RFC 3281 to allow Attribute Certificate chains to support > prefix delegation certification. In my opinion, D) would be the architecturally right choice. However, this would take quite a long time, and might even fail. > E) We could support delegation through using the mechanism > described in draft-ietf-pkix-x509, Even though I don't like E) from an architectural point of view, it looks acceptable. It is simple enough to define, simple enough to implement, secure, and scales appropriately. It also delegates the hard problem of setting up the infrastructure to another WG. > In the interest of having a unified IETF certificate profile for routing > certificates, I'd suggest we go forward with proposal E: > > Support delegation through using the mechanism described in > draft-ietf-pkix-x509, with perhaps some minor specification of conventions > to satisfy SEND requirements. Based on my conclusions above, I find this proposal good. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 22 12:46:52 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24591 for ; Mon, 22 Sep 2003 12:46:46 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8J8PuAv010578; Fri, 19 Sep 2003 10:25:57 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SZF05AF6; Fri, 19 Sep 2003 10:26:15 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8J8Ptxa007329; Fri, 19 Sep 2003 10:25:55 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8M1me027423; Fri, 19 Sep 2003 10:22:01 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8J8M0dO027420; Fri, 19 Sep 2003 10:22:00 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8J8Lwme027381 for ; Fri, 19 Sep 2003 10:21:58 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id E213B25 for ; Fri, 19 Sep 2003 11:35:19 +0300 (EEST) Message-ID: <3F6ABCA7.6030209@ericsson.com> Date: Fri, 19 Sep 2003 11:21:59 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Test6, please ignore Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit [I have had lots of trouble sending mail to this mailing list. Expect a number of tests to see if things work now. --Pekka] -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 22 15:49:51 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05875 for ; Mon, 22 Sep 2003 15:49:45 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8JActAv021121; Fri, 19 Sep 2003 12:38:56 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SY7RZ07F; Fri, 19 Sep 2003 12:40:46 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8JAcsxa010561; Fri, 19 Sep 2003 12:38:54 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8JAZOme001392; Fri, 19 Sep 2003 12:35:24 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8JAZNNM001388; Fri, 19 Sep 2003 12:35:23 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8JAZLme001373 for ; Fri, 19 Sep 2003 12:35:21 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 9A96B26; Fri, 19 Sep 2003 13:48:42 +0300 (EEST) Message-ID: <3F6ADBE9.6010209@ericsson.com> Date: Fri, 19 Sep 2003 13:35:21 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Francis Dupont Subject: Issue 22: Part 2: Timestamp Delta time Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Issue 22 deals with timestamp validity period and avoiding a cache filling DoS attack. For background, see http://www.arkko.com/publications/send/issues/issue22.txt My (perhaps flawed) analysis of the issue boils down to two points: 1. The value for the timestamp delta 2. What to do if the ND cache becomes full I'll describe these separate messages, focusing on the the Delta time here. ----------------------------------------------------------------- The current specifications states the following > Recommended default value for the allowed Delta is 3,600 seconds. Francis Dupond made a comment that this is far too large. The function of the Delta value can be described as follows: - A larger Delta allows hosts with differently running clocks to communicate, while a small Delta requires better clock synchronization. - A larger Delta potentially requires more memory, since it may require the host to remember more other hosts. - A larger Delta exposes the host to replay attacks in the case that its cache becomes full, thereby requiring it to accept ND messages from new hosts. The situation that seems to be most worrisome is one where an attacker fulfils the cache, thereby forcing the host to drop some cache entries, and then launches a replay attack. It looks like the suggestion in the Part 1 message of this issue plugs the attack. If so, the exact value of Delta is not a concern from the memory usage and DoS/replay attack point of view. Hence, it looks like that the default value for Delta becomes mostly a policy issue. On the other hand, there seems to be some possible replay attack scenarios against nodes that arrive to a new link. (More on that on a separate message). Anyway, I suggest that if we can change the caching algorithm so that the default Delta value is a pure policy issue, we would keep 3600 seconds or even use a larger value. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 22 16:37:32 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09200 for ; Mon, 22 Sep 2003 16:37:27 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8JAj9Av023179; Fri, 19 Sep 2003 12:45:09 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SZF06TDM; Fri, 19 Sep 2003 12:45:27 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8JAitxR013158; Fri, 19 Sep 2003 12:44:55 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8JAfqme004784; Fri, 19 Sep 2003 12:41:52 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8JAfpAw004777; Fri, 19 Sep 2003 12:41:51 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8JAfnme004758 for ; Fri, 19 Sep 2003 12:41:49 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id C8E4B26; Fri, 19 Sep 2003 13:55:10 +0300 (EEST) Message-ID: <3F6ADD6D.30407@ericsson.com> Date: Fri, 19 Sep 2003 13:41:49 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Cc: Francis Dupont Subject: Re: Issue 22: Part I: Handling ND cache getting full References: <3F6AD470.2030807@ericsson.com> In-Reply-To: <3F6AD470.2030807@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit It is silly to reply to oneself, but I noticed a potential problem after sending the initial message. > o When a message is received from a new peer, i.e. one > that is not stored in the cache, the received timestamp > is checked and the packet is accepted if the timestamp > is recent enough: > > -Delta < RDnew - TSnew < +Delta > .... > o When a message is received from a known peer, i.e. one > that has an entry in the cache, the time stamp is > checked against the last received message: > > TSnew > TSlast + (RDnew - RDlast) x (1 - drift) > TSnew < TSlast + (RDnew - RDlast) x (1 + drift) Doesn't this open a potential replay attack against a new node that arrives to a link. Let us assume that an attacker is on the link, and collects ND messages. Let us further assume that one node on the link, say Alice, changes its link layer address. Now a new node, say Bob arrives to the link, within the Delta time from Alice changing her address. If the attacker notices Bob arriving before Alice, it can Alice's earlier recorded message that still uses the old link layer address. This causes Bob to record TSlast and RDlast from the message, together with the old link layer address When Alice now notices Bob's arrival, she will send a new message. However, the new message will not pass the check since apparently her clock has drifted more than what is allowed. That is, (RDnew - RDlast) is small due to the replayed message from which RDlast was recorded, but TSnew - TSlast will be much larger, since TSlast was the timestamp in the replayed message. Consequently, I propose that we remove the latter check from the second rule, allowing TSnew to be any much larger than TSlast. I don't see this opening any new attacks, and it fixes the scenario above. --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Sep 24 14:01:05 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29086 for ; Wed, 24 Sep 2003 14:01:04 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8OHvkAv023038; Wed, 24 Sep 2003 19:57:46 +0200 (MEST) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id TNZNLJQ0; Wed, 24 Sep 2003 19:58:19 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8OHvdxR016094; Wed, 24 Sep 2003 19:57:40 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8OHs0me021131; Wed, 24 Sep 2003 19:54:00 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8OHs0xu021130; Wed, 24 Sep 2003 19:54:00 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from webmail.speakeasy.net (webmail2.speakeasy.net [216.254.0.82]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8OHrwme021102 for ; Wed, 24 Sep 2003 19:53:58 +0200 (MET DST) Received: (qmail 24314 invoked from network); 24 Sep 2003 17:53:42 -0000 Received: from localhost (HELO webmail2) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 24 Sep 2003 17:53:42 -0000 Received: from 66.93.135.225 (unverified [66.93.135.225]) by webmail2 (VisualMail 4.0) with WEBMAIL id 1581; Wed, 24 Sep 2003 17:53:42 +0000 From: jonwood@speakeasy.net To: "Pekka Nikander" , "Jari Arkko" Cc: "Jonathan Wood" , "SEND WG" , "Francis Dupont" Importance: Normal Sensitivity: Normal Message-ID: X-Mailer: Mintersoft VisualMail, Build 4.0.111601 X-Originating-IP: [66.93.135.225] Date: Wed, 24 Sep 2003 17:53:42 +0000 Subject: Re: Issue 22: Part 2: Timestamp Delta time MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Pekka Nikander > > From this point of view, it is clearly better to be very > selective in how to throw out entries. Reducing Delta > is very discriminative against those hosts that have a > large clock difference, while an attacker can reduce its > clock difference into arbitrarily small. Throwing out old > entries just because their clock difference is large seems > like a bad approach. I agree. > > In my opinion, the exact algorithm for expiring cache entries > in the case of a full cache is clearly a local policy issue, > and should not be specified in the document. However, it might > be a good idea to give some guidance for implementors. > > It also looks like that all the previous ideas of reducing > Delta are really bad, since the attacker can easily select > its own Delta, and make it whatever small. A better idea > seems to be to have a separate cache space for new entries and > old entries, and under an attack more eagerly drop new cache > entries than old ones. One could track traffic, and only allow > those new entries that receive genuine traffic to be converted > into old cache entries. > > It also looks like a good idea to consider the sec parameter > when forcing cache entries out, and let those entries with > a larger sec a higher chance of staying in. > While such a scheme would make attacks harder, it would not fully prevent them. For example, an attacker could send a little traffic (i.e. a ping or TCP syn) after each NS to trick the victim into promoting its cache entry to the old cache. I think it is becoming apparent that a method that will fully prevent replay attacks will be very complex to implement and administer. Perhaps we should drop the cache idea altogether, and just use timestamp delta checking? The security provided, while not perfect, could still be reasonably good (depending on the local policy). It would also be very simple for locals admins to understand and tweak. Jon -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Sep 25 20:55:34 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00444 for ; Thu, 25 Sep 2003 20:55:34 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8Q0r6Av011128; Fri, 26 Sep 2003 02:53:07 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id TN5T8PSM; Fri, 26 Sep 2003 02:55:22 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8Q0r5xa000854; Fri, 26 Sep 2003 02:53:05 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8Q0nZme025054; Fri, 26 Sep 2003 02:49:35 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8Q0nZex025053; Fri, 26 Sep 2003 02:49:35 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8Q0nWme025048 for ; Fri, 26 Sep 2003 02:49:33 +0200 (MET DST) Received: (qmail 2964 invoked from network); 26 Sep 2003 00:49:31 -0000 Received: from unknown (HELO speakeasy.net) ([66.93.135.225]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Sep 2003 00:49:31 -0000 Date: Thu, 25 Sep 2003 17:49:30 -0700 Subject: Re: Issue 22: Part 2: Timestamp Delta time Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jari Arkko , SEND WG , Francis Dupont To: Pekka Nikander From: Jonathan Wood In-Reply-To: <3F729DCA.4030405@ericsson.com> Message-Id: <49C4346C-EFBB-11D7-9F74-0003930D291E@speakeasy.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > > On the other hand, I think we can leave all these concerns > as SHOULD, and leave the implementation the freedom to ignore > them and just use e.g. Delta, if really needed. > This pretty much works for me. Right now my feeling is that the complexity of developing a reasonably effective cache scheme would outweigh its security benefits, so I would be a little happier with "MAY" rather than "SHOULD". Jon -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Sep 29 06:32:36 2003 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03564 for ; Mon, 29 Sep 2003 06:32:35 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8TAThAv008414; Mon, 29 Sep 2003 12:29:46 +0200 (MEST) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id TN54896M; Mon, 29 Sep 2003 12:32:12 +0200 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.9/8.12.9) with ESMTP id h8TATfxa010667; Mon, 29 Sep 2003 12:29:41 +0200 (MEST) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8TAPjme011874; Mon, 29 Sep 2003 12:25:45 +0200 (MET DST) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.9/8.12.9/Submit) id h8TAPipb011873; Mon, 29 Sep 2003 12:25:44 +0200 (MET DST) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.9/8.12.9/unixcenter-xnetx-1.0) with ESMTP id h8TAPhme011869 for ; Mon, 29 Sep 2003 12:25:43 +0200 (MET DST) Received: from ericsson.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 4156A1C for ; Mon, 29 Sep 2003 13:39:02 +0300 (EEST) Message-ID: <3F7808AA.5000308@ericsson.com> Date: Mon, 29 Sep 2003 13:25:46 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: Tentative SEND WG agenda for Minneapolis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Below is the tentative agenda for Minneapolis. If you think we should discuss something additional, please contact the chairs. 5 Agenda bashing Chairs 5 Draft status Chairs 5 Significant changes after Vienna Chairs 15 Implementation report Jonathan Wood 20 Open issues Jari Arkko --Pekka Nikander -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------