From jari.arkko@lmf.ericsson.se Tue Jan 13 00:48:00 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14367 for ; Tue, 13 Jan 2004 00:47:58 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i05InY8K015824; Mon, 5 Jan 2004 19:49:35 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBQAKTC; Mon, 5 Jan 2004 19:50:32 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i05InQwg012935; Mon, 5 Jan 2004 19:49:26 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i05IjmIt008631; Mon, 5 Jan 2004 19:45:48 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i05IjmPg008630; Mon, 5 Jan 2004 19:45:48 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i05IjjIt008623 for ; Mon, 5 Jan 2004 19:45:46 +0100 (MET) Message-ID: <017101c3d3bc$28053c50$5b6015ac@dclkempt40> From: "James Kempf" To: "Gregory Daley" , Cc: , References: <358c7335fa63.35fa63358c73@mail1.monash.edu.au> Subject: Re: issue 44 - host to check its own address against router cert prefixes? Date: Mon, 5 Jan 2004 10:45:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Jari/Greg/Mohan, Interesting conversation. > > Router selection depends on many factors, including > > > > - Router Information (RI) options for the destination address > > (draft-ietf-ipv6-router-selection-02.txt) > > - Prf field in the RA (same draft) > > - Router lifetime value as per RFC 2461. > > - Trustworthiness of the given router, handled by the usual SEND > > mechanisms. > > - Routing rights/expected ingress filtering behaviour, which is > > where this discussion started. > > > > The first three factors exist even in non-SEND hosts. Router lifetime > > has higher priority than the RI option or Prf values, i.e., a router > > with a zero lifetime does not get selected as a default router for > > anything regardless of any attractive RI options it might have. And > > specific information carried in RI, I think, has higher priority than > > the default router priority Prf. > > > > General trustworthiness of a router is an on/off kind of thing, > > similar to the router lifetime zero check. This means that it has > > higher priority than the other checks; a bad router will not be > > selected for anything. > > > > The interesting part is the routing rights issue. This is in fact the > > same thing as the expected ingress filtering; one of the questions we > > are debating is what kind of ingress filtering we should expect from > > routers when there are at present no explicit protocol means to > > determine this. > > > > I think James argued convincingly that the certs have routing rights > > information. The remaining questions are: > > > > (1) Are the routing rights same for all routers on the link? > > > > If they are not, then there is a need to change default router > > selection algorithms. Note that this is necessary regardless of > > SEND; ingress filtering by itself will already cause this. > > > > If the rights are the same for all routers, then current > > algorithms and SEND draft text are sufficient. > > I really don't care what preferences or other > parameters routers advertise their > capabilities as for default router selecation, so > long as they are certified to route the prefix > which I have as my source address. > > The trust which the host has of the delegation/certifcation > should be sufficient to determine if the router is considered > OK for routing. > > If there's no delegated authority for a particular prefix > in the DCA, there shouldn't be any default routing > through that router, regardless of the RA contents. > Yes, I agree with Greg here. The certificate contains the prefixes which the router is authorized to filter. Exactly how advertising is done is a question of how the ISP wants to configure their routers. > > > > (2) Are the advertised prefixes the same as the routing rights? > > > > I don't they need to be. Clearly, we are not going to drop a RA > > just because it contains less prefixes than the router's cert. > > > > Advertised prefixes should be a subset of routing rights. > > I think that for a particular security domain (for example > a set of access networks) a router may be default for, > I'd consider having a single 'default routing' certificate > over those prefixes in the domain (which may be on several > of the router's interfaces). > > In this case, the router's advertisment on a particular > interface will not contain all of the prefixes, although the > DCA would. I'd guess that this could be a fairly > common deployment scenario for wireless access networks. > > If this raises sacreligious horror in anyone, I'll be > happy to recant if someone will tell me why this is bad. > Actually, this sounds as if it could be a very common case for ISPs - the cert contains a collection of prefixes covering a number of subnets. > > > (3) What is the priority between the routing rights information and > > other factors? > > > > Both routing rights and route information option, if not obeyed, > > can lead to dropped packets. Ingress filtering can drop packets > > with inappropriate source addresses, and disobeying a route > > information option can lead to a packet being sent to the wrong > > interface and network, with no guarantee that this networks can > > actually route the packet. So I would say that both factors are > > crucial. Inconsistency is possible, but is a configuration > > problem. Even without SEND, this can occur: host picks wrong > > source address, follows RI, packet discarded (either router config > > problem or host address source selection table config problem). > > > > I'd actually guess that the routing rights guarantee > that the router will not apply ingress filtering to your > packet _if_ on that interface, it advertises that prefix. > Yes, I think that is accurate. However, I don't think the converse is implied, that is, if the router doesn't advertise the prefix but it is in the certificate, that the router won't filter. So I suppose the route MUST filter on what it advertises, and SHOULD filter on what's in the certificate if other routers on the link advertise other prefixes. This would allow the case that Mohan is concerned about. If other routers on the link don't advertise other prefixes, then the router SHOULD restrict filtering to what it advertises. Hmm, is this opening up things too much from a security standpoint? > Assuming otherwise means one of two things: > > Hosts may choose to send to a router with a prefix it > are authorized to route, on an interface relevant to a different > prefix (... should this packet be ingress filtered?). > > Or > > Authorization must be done on a per-interface basis > through certification of a CGA or otherwise. > (This is OK, but I guess there's could be a lot of > certificates if this was done naively). > > Certainly it's worth taking this to the IPv6 list, > but I'd guess we'd have to be clear about how these > certificates are interpreted and authorized. > > > Is there a need to talk about this in the IPv6 list? James? Let's run it by the ADs first. I'll ask. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jan 13 16:05:55 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12950 for ; Tue, 13 Jan 2004 16:05:53 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id i04BE9I2025025; Sun, 4 Jan 2004 12:14:09 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJAGLSAB; Sun, 4 Jan 2004 12:14:08 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i04BE8XA014101; Sun, 4 Jan 2004 12:14:08 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i04BDAIt011509; Sun, 4 Jan 2004 12:13:10 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i04BD984011508; Sun, 4 Jan 2004 12:13:09 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i04BD6It011492 for ; Sun, 4 Jan 2004 12:13:07 +0100 (MET) Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L50LU6BN2S8X1MPR@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Sun, 4 Jan 2004 22:06:24 +1100 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 92E0F158002; Sun, 04 Jan 2004 22:06:22 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by broink.its.monash.edu.au (Postfix) with ESMTP id 82ECE120002; Sun, 04 Jan 2004 22:06:22 +1100 (EST) Date: Sun, 04 Jan 2004 22:06:22 +1100 From: Gregory Daley Subject: Re: issue 44 - host to check its own address against router cert prefixes? To: jari.arkko@kolumbus.fi Cc: ietf-send@standards.ericsson.net, kempf@docomolabs-usa.com, mohanp@sbcglobal.net Message-id: <358c7335fa63.35fa63358c73@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Jari, Sorry I've dropped out of the conversation for a while, but I've been looking at some of these issues a recently, so I've got some ideas. ----- Original Message ----- From: jari.arkko@kolumbus.fi Date: Saturday, January 3, 2004 1:05 am Subject: Re: issue 44 - host to check its own address against router cert prefixes? > Router selection depends on many factors, including > > - Router Information (RI) options for the destination address > (draft-ietf-ipv6-router-selection-02.txt) > - Prf field in the RA (same draft) > - Router lifetime value as per RFC 2461. > - Trustworthiness of the given router, handled by the usual SEND > mechanisms. > - Routing rights/expected ingress filtering behaviour, which is > where this discussion started. > > The first three factors exist even in non-SEND hosts. Router lifetime > has higher priority than the RI option or Prf values, i.e., a router > with a zero lifetime does not get selected as a default router for > anything regardless of any attractive RI options it might have. And > specific information carried in RI, I think, has higher priority than > the default router priority Prf. > > General trustworthiness of a router is an on/off kind of thing, > similar to the router lifetime zero check. This means that it has > higher priority than the other checks; a bad router will not be > selected for anything. > > The interesting part is the routing rights issue. This is in fact the > same thing as the expected ingress filtering; one of the questions we > are debating is what kind of ingress filtering we should expect from > routers when there are at present no explicit protocol means to > determine this. > > I think James argued convincingly that the certs have routing rights > information. The remaining questions are: > > (1) Are the routing rights same for all routers on the link? > > If they are not, then there is a need to change default router > selection algorithms. Note that this is necessary regardless of > SEND; ingress filtering by itself will already cause this. > > If the rights are the same for all routers, then current > algorithms and SEND draft text are sufficient. I really don't care what preferences or other parameters routers advertise their capabilities as for default router selecation, so long as they are certified to route the prefix which I have as my source address. The trust which the host has of the delegation/certifcation should be sufficient to determine if the router is considered OK for routing. If there's no delegated authority for a particular prefix in the DCA, there shouldn't be any default routing through that router, regardless of the RA contents. > > (2) Are the advertised prefixes the same as the routing rights? > > I don't they need to be. Clearly, we are not going to drop a RA > just because it contains less prefixes than the router's cert. > > Advertised prefixes should be a subset of routing rights. I think that for a particular security domain (for example a set of access networks) a router may be default for, I'd consider having a single 'default routing' certificate over those prefixes in the domain (which may be on several of the router's interfaces). In this case, the router's advertisment on a particular interface will not contain all of the prefixes, although the DCA would. I'd guess that this could be a fairly common deployment scenario for wireless access networks. If this raises sacreligious horror in anyone, I'll be happy to recant if someone will tell me why this is bad. > (3) What is the priority between the routing rights information and > other factors? > > Both routing rights and route information option, if not obeyed, > can lead to dropped packets. Ingress filtering can drop packets > with inappropriate source addresses, and disobeying a route > information option can lead to a packet being sent to the wrong > interface and network, with no guarantee that this networks can > actually route the packet. So I would say that both factors are > crucial. Inconsistency is possible, but is a configuration > problem. Even without SEND, this can occur: host picks wrong > source address, follows RI, packet discarded (either router config > problem or host address source selection table config problem). > > Is there a need to talk about this in the IPv6 list? James? I'd actually guess that the routing rights guarantee that the router will not apply ingress filtering to your packet _if_ on that interface, it advertises that prefix. Assuming otherwise means one of two things: Hosts may choose to send to a router with a prefix it are authorized to route, on an interface relevant to a different prefix (... should this packet be ingress filtered?). Or Authorization must be done on a per-interface basis through certification of a CGA or otherwise. (This is OK, but I guess there's could be a lot of certificates if this was done naively). Certainly it's worth taking this to the IPv6 list, but I'd guess we'd have to be clear about how these certificates are interpreted and authorized. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 14 06:16:16 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11696 for ; Wed, 14 Jan 2004 06:16:11 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EBDdAh003224; Wed, 14 Jan 2004 12:13:39 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDFM1LG; Wed, 14 Jan 2004 12:13:39 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EBDcXA013203; Wed, 14 Jan 2004 12:13:38 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EBCVIt004367; Wed, 14 Jan 2004 12:12:31 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EBCV7L004366; Wed, 14 Jan 2004 12:12:31 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EBCTIt004361 for ; Wed, 14 Jan 2004 12:12:30 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.109]) by fep21-app.kolumbus.fi with ESMTP id <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi>; Wed, 14 Jan 2004 13:12:29 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: , , Subject: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 14 Jan 2004 13:12:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit I have reviewed this thread again, and I have made a few conclusions: o It seems that we agree about Greg's scenario where a router may get a single certificate that covers more one of its interfaces. This is important for practical purposes. It implies that the set of prefixes in the RA may be a subset of the prefixes in the cert. o There is a related non-SEND issue: an ingress filtering and default router problem exists even if you do not consider SEND at all. This has to do with the relationship of ingress filtering and default router selection. If put my cable and DSL boxes on the same network at home, hosts will route my packets more or less randomly through both routers -- but since the ISPs employ ingress filtering, packets with a source prefix from the other ISP will be dropped. Therefore, hosts should send packets with a prefix P preferrably through routers that are somehow known to recognize the prefix P. Router selection draft does not appear to help here, because it only deals with destination prefixes, not source prefixes. I am not aware of any other IPv6 feature which would help either. In the long run, this means that IPv6/multi6/send/someone has to solve this, probably even for the case that SEND is not used. o The key question is whether the default router selection should be modified in SEND or not? Draft 01 does not modify this behaviour. It simply says that if the advertised and certified prefixes don't match, another default router should be used. This still leaves the possibility that the routers ingress filter aggressively according to their own advertised prefixes, and packets sent with other prefixes from the link are dropped. But as Greg pointed out, the SEND certs ensure that advertisements are right, and if you see an advertisement from the router then you are sure that it will not ingress filter those prefixes. If we stick with this, it implies that SEND solves the problem only partially, i.e., we ensure that the advertisements and other options are authenticated and authorized. But we do not modify the default router selection, that would have to be done by someone else. I think that would be appropriate, particularly when such modification outside SEND could be used without SEND. If this looks reasonable, then the following modifications in the draft are needed: If the network operator wants to constrain which routers support particular prefixes, routers SHOULD be configured with certificates having prefixes listed in the prefix extension. Routers so configured MUST advertise exactly the prefixes for which they are certified. => If the network operator wants to constrain which routers support particular prefixes, routers SHOULD be configured with certificates having prefixes listed in the prefix extension. Routers so configured MUST advertise the prefixes for which they are certified, or a subset thereof. See also the diffs at: http://www.arkko.com/publications/send/issues/issue47diff.html I have a -02 strawman available at: http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt In addition, we need to work in ipv6/multi6/somewhere on the ingress filtering problem. Comments? -------------------------------------------------------------------- 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 Jan 14 07:36:00 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15402 for ; Wed, 14 Jan 2004 07:35:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0ECXrqY016318; Wed, 14 Jan 2004 13:33:53 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBS2A6Q; Wed, 14 Jan 2004 13:35:23 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0ECXqXA014805; Wed, 14 Jan 2004 13:33:52 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0ECX8It026226; Wed, 14 Jan 2004 13:33:08 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0ECX8I5026225; Wed, 14 Jan 2004 13:33:08 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ftmail.lab.flarion.com (mail.flarion.com [63.103.94.23]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0ECX6It026221 for ; Wed, 14 Jan 2004 13:33:07 +0100 (MET) Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jan 2004 07:33:05 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04208A@ftmail.lab.flarion.com> From: Soliman Hesham To: "'jari.arkko@kolumbus.fi'" , ietf-send@standards.ericsson.net Cc: kempf@docomolabs-usa.com, pekkas@netcore.fi, greg.daley@eng.monash.edu.au Subject: RE: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 14 Jan 2004 07:33:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk > o There is a related non-SEND issue: an ingress filtering > and default > router problem exists even if you do not consider SEND at all. > This has to do with the relationship of ingress filtering and > default router selection. If put my cable and DSL boxes on the > same network at home, hosts will route my packets more or less > randomly through both routers -- but since the ISPs employ > ingress filtering, packets with a source prefix from the other > ISP will be dropped. Therefore, hosts should send packets with a > prefix P preferrably through routers that are somehow known to > recognize the prefix P. > > Router selection draft does not appear to help here, because > it only deals with destination prefixes, not source prefixes. > I am not aware of any other IPv6 feature which would help > either. > > In the long run, this means that IPv6/multi6/send/someone has > to solve this, probably even for the case that SEND is not > used. => We seem to have this discussion roughly twice a year in different WGs :) The core of the problem is that a multi-addressed host, has no way of knowing the backhaul connectivity of the default router. I think that it might have been an oversight to not include the source address in the next hop determination algorithm, in addition to assuming that routers will only advertise prefixes that they won't ingress filter. In any case, this is going to affect any multihomed link, i.e. that has more than one router connected to different networks. Does anyone know where this should be addressed? IPv6 WG?? It affects PANA, nemo, multi6, IPv6 ....etc IMHO SEND is not the right place for this as we need a complete solution for IPv6. Hesham **************************************************************************** ******************************************* This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ******************************************* -------------------------------------------------------------------- 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 Jan 14 08:36:39 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16897 for ; Wed, 14 Jan 2004 08:36:38 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EDY1YG016662; Wed, 14 Jan 2004 14:34:02 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDFNJHQ; Wed, 14 Jan 2004 14:34:01 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EDY0XA015861; Wed, 14 Jan 2004 14:34:00 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EDXIIt012232; Wed, 14 Jan 2004 14:33:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EDXIRR012231; Wed, 14 Jan 2004 14:33:18 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep20-app.kolumbus.fi (fep20-0.kolumbus.fi [193.229.0.47]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EDXGIt012227 for ; Wed, 14 Jan 2004 14:33:17 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.110]) by fep20-app.kolumbus.fi with ESMTP id <20040114133316.SGOT15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi>; Wed, 14 Jan 2004 15:33:16 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: CC: Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 14 Jan 2004 15:33:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040114133316.SGOT15980.fep20-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hesham, I agree with what you say. I think your comments also point to the direction that I'm proposing we take, i.e., SEND ensures that certs and advertisements agree, but that the rest of the problem is dealt with separately. --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 Jan 14 08:36:59 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16918 for ; Wed, 14 Jan 2004 08:36:58 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EDZXYG017066; Wed, 14 Jan 2004 14:35:33 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJAJBR1L; Wed, 14 Jan 2004 14:35:32 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EDZVXA015915; Wed, 14 Jan 2004 14:35:31 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EDZKIt012651; Wed, 14 Jan 2004 14:35:20 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EDZKNE012650; Wed, 14 Jan 2004 14:35:20 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ftmail.lab.flarion.com (mail.flarion.com [63.103.94.23]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EDZJIt012646 for ; Wed, 14 Jan 2004 14:35:19 +0100 (MET) Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jan 2004 08:35:19 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04208C@ftmail.lab.flarion.com> From: Soliman Hesham To: "'jari.arkko@kolumbus.fi'" Cc: ietf-send@standards.ericsson.net Subject: RE: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 14 Jan 2004 08:35:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Hi Jari, Yes. I just wanted to see if we can solve this general problem somewhere. Perhaps this should be brought up beyond this WG. Hesham > -----Original Message----- > From: jari.arkko@kolumbus.fi [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, January 14, 2004 8:33 AM > To: H.Soliman@flarion.com > Cc: ietf-send@standards.ericsson.net > Subject: Re: moving on with issue 47 (routing vs. > advertisement rights) > > > > Hi Hesham, > > I agree with what you say. I think your comments > also point to the direction that I'm proposing we > take, i.e., SEND ensures that certs and advertisements > agree, but that the rest of the problem is dealt > with separately. > > --Jari > > **************************************************************************** ******************************************* This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. **************************************************************************** ******************************************* -------------------------------------------------------------------- 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 Jan 14 11:23:14 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25799 for ; Wed, 14 Jan 2004 11:23:13 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EGJGAh003872; Wed, 14 Jan 2004 17:19:17 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBSJ9FY; Wed, 14 Jan 2004 17:20:47 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EGJEwg009992; Wed, 14 Jan 2004 17:19:14 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EGIPIt025952; Wed, 14 Jan 2004 17:18:25 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EGIP3G025951; Wed, 14 Jan 2004 17:18:25 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EGIMIt025946 for ; Wed, 14 Jan 2004 17:18:23 +0100 (MET) Message-ID: <074901c3daba$10f85bf0$606015ac@dclkempt40> From: "James Kempf" To: , Cc: , References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 14 Jan 2004 08:18:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Jari, I agree with the change. Wrt. getting further work on the ingress filtering issue, when I do the document writeup for the INT area ADs I will mention that the WG considered this problem and decided it was out of scope for SEND, but believe it should be addressed in another WG and not simply dropped. jak ----- Original Message ----- From: To: Cc: ; ; Sent: Wednesday, January 14, 2004 3:12 AM Subject: moving on with issue 47 (routing vs. advertisement rights) > I have reviewed this thread again, and I have made a few > conclusions: > > o It seems that we agree about Greg's scenario where a router may > get a single certificate that covers more one of its interfaces. > This is important for practical purposes. It implies that the set > of prefixes in the RA may be a subset of the prefixes in the > cert. > > o There is a related non-SEND issue: an ingress filtering and default > router problem exists even if you do not consider SEND at all. > This has to do with the relationship of ingress filtering and > default router selection. If put my cable and DSL boxes on the > same network at home, hosts will route my packets more or less > randomly through both routers -- but since the ISPs employ > ingress filtering, packets with a source prefix from the other > ISP will be dropped. Therefore, hosts should send packets with a > prefix P preferrably through routers that are somehow known to > recognize the prefix P. > > Router selection draft does not appear to help here, because > it only deals with destination prefixes, not source prefixes. > I am not aware of any other IPv6 feature which would help > either. > > In the long run, this means that IPv6/multi6/send/someone has > to solve this, probably even for the case that SEND is not > used. > > o The key question is whether the default router selection should > be modified in SEND or not? > > Draft 01 does not modify this behaviour. It simply says that > if the advertised and certified prefixes don't match, another > default router should be used. This still leaves the possibility > that the routers ingress filter aggressively according to their > own advertised prefixes, and packets sent with other prefixes > from the link are dropped. But as Greg pointed out, the SEND > certs ensure that advertisements are right, and if you see an > advertisement from the router then you are sure that it will > not ingress filter those prefixes. > > If we stick with this, it implies that SEND solves the problem > only partially, i.e., we ensure that the advertisements and > other options are authenticated and authorized. But we do not > modify the default router selection, that would have to be done > by someone else. > > I think that would be appropriate, particularly when such > modification outside SEND could be used without SEND. > > If this looks reasonable, then the following modifications in > the draft are needed: > > If the network operator wants to constrain which routers support > particular prefixes, routers SHOULD be configured with certificates > having prefixes listed in the prefix extension. Routers so > configured MUST advertise exactly the prefixes for which they are > certified. > > => > > If the network operator wants to constrain which routers support > particular prefixes, routers SHOULD be configured with certificates > having prefixes listed in the prefix extension. Routers so > configured MUST advertise the prefixes for which they are > certified, or a subset thereof. > > See also the diffs at: > > http://www.arkko.com/publications/send/issues/issue47diff.html > > I have a -02 strawman available at: > > http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt > > In addition, we need to work in ipv6/multi6/somewhere on the > ingress filtering problem. > > Comments? > > > -------------------------------------------------------------------- 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 Jan 14 11:24:37 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25928 for ; Wed, 14 Jan 2004 11:24:36 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EGMTYG023964; Wed, 14 Jan 2004 17:22:29 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBSJ0D8; Wed, 14 Jan 2004 17:23:59 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EGMSwg010200; Wed, 14 Jan 2004 17:22:28 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EGMJIt026763; Wed, 14 Jan 2004 17:22:19 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EGMJIr026762; Wed, 14 Jan 2004 17:22:19 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EGMHIt026744 for ; Wed, 14 Jan 2004 17:22:17 +0100 (MET) Message-ID: <076c01c3daba$9b1fa360$606015ac@dclkempt40> From: "James Kempf" To: "Soliman Hesham" , , Cc: , References: <9E3BA3946476AD4EB94672712B12A85F04208A@ftmail.lab.flarion.com> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 14 Jan 2004 08:22:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > In any case, this is going to affect any multihomed link, > i.e. that has more than one router connected to different > networks. Does anyone know where this should be addressed? > IPv6 WG?? It affects PANA, nemo, multi6, IPv6 ....etc > Not sure. IPv6 is trying to finish up, so it might not be the right place. I'll raise the issue with the ADs and make sure it doesn't drop, then see what they say. Perhaps even a small, focussed, short term WG, like SEND. > IMHO SEND is not the right place for this as we need a > complete solution for IPv6. > I agree. 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 Jan 14 13:38:23 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02233 for ; Wed, 14 Jan 2004 13:38:23 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EIa0YG009389; Wed, 14 Jan 2004 19:36:01 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR3HRW7A; Wed, 14 Jan 2004 19:38:32 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EIZkwg018535; Wed, 14 Jan 2004 19:35:47 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EIYwIt001818; Wed, 14 Jan 2004 19:34:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EIYwMB001816; Wed, 14 Jan 2004 19:34:58 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i0EIYuIt001812 for ; Wed, 14 Jan 2004 19:34:57 +0100 (MET) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 14 Jan 2004 18:34:55 -0000 Message-ID: <006b01c3dacd$1dc50d70$c91167c0@adithya> From: "Mohan Parthasarathy" To: , Cc: , , References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 14 Jan 2004 10:34:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Jari, I looked at the latest version you posted below. A couple of questions.. In section 6.1.1, The X.509 IP address extension MUST contain at least one addressesOrRanges element. This element MUST contain an addressPrefix element with an IPv6 address prefix for a prefix the router or the intermediate entity is authorized to advertise. If the entity is allowed to route any prefix, the used IPv6 address prefix is the null prefix, 0/0. - The first part says nothing about routing for the prefix. It says ".. authorized to advertise". If we don't want to use it for routing at all, then can we be explicit ? Or i am confused with the resolution here, as the next line talks about routing for the prefix also. In any case, it should be explicitly stated here. - If the IPv6 address prefix is the null prefix, then you can't validate the prefix like other prefixes, right ? If we can't, we should mention this explicitly. In section 7.3, If the network operator wants to constrain which routers support particular prefixes, routers SHOULD be configured with certificates having prefixes listed in the prefix extension. Routers so configured MUST advertise the prefixes for which they are certified, or a subset thereof. The use of the word "support" is confusing in the first line. Did you mean "support routing .." ? Network operators that do not want to constrain particular routers to specific prefixes SHOULD configure routers with certificates containing either the null prefix or no prefix extension at all. Did you mean "routers to route specific prefixes" ? thanks mohan > I have reviewed this thread again, and I have made a few > conclusions: > > o It seems that we agree about Greg's scenario where a router may > get a single certificate that covers more one of its interfaces. > This is important for practical purposes. It implies that the set > of prefixes in the RA may be a subset of the prefixes in the > cert. > > o There is a related non-SEND issue: an ingress filtering and default > router problem exists even if you do not consider SEND at all. > This has to do with the relationship of ingress filtering and > default router selection. If put my cable and DSL boxes on the > same network at home, hosts will route my packets more or less > randomly through both routers -- but since the ISPs employ > ingress filtering, packets with a source prefix from the other > ISP will be dropped. Therefore, hosts should send packets with a > prefix P preferrably through routers that are somehow known to > recognize the prefix P. > > Router selection draft does not appear to help here, because > it only deals with destination prefixes, not source prefixes. > I am not aware of any other IPv6 feature which would help > either. > > In the long run, this means that IPv6/multi6/send/someone has > to solve this, probably even for the case that SEND is not > used. > > o The key question is whether the default router selection should > be modified in SEND or not? > > Draft 01 does not modify this behaviour. It simply says that > if the advertised and certified prefixes don't match, another > default router should be used. This still leaves the possibility > that the routers ingress filter aggressively according to their > own advertised prefixes, and packets sent with other prefixes > from the link are dropped. But as Greg pointed out, the SEND > certs ensure that advertisements are right, and if you see an > advertisement from the router then you are sure that it will > not ingress filter those prefixes. > > If we stick with this, it implies that SEND solves the problem > only partially, i.e., we ensure that the advertisements and > other options are authenticated and authorized. But we do not > modify the default router selection, that would have to be done > by someone else. > > I think that would be appropriate, particularly when such > modification outside SEND could be used without SEND. > > If this looks reasonable, then the following modifications in > the draft are needed: > > If the network operator wants to constrain which routers support > particular prefixes, routers SHOULD be configured with certificates > having prefixes listed in the prefix extension. Routers so > configured MUST advertise exactly the prefixes for which they are > certified. > > => > > If the network operator wants to constrain which routers support > particular prefixes, routers SHOULD be configured with certificates > having prefixes listed in the prefix extension. Routers so > configured MUST advertise the prefixes for which they are > certified, or a subset thereof. > > See also the diffs at: > > http://www.arkko.com/publications/send/issues/issue47diff.html > > I have a -02 strawman available at: > > http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt > > In addition, we need to work in ipv6/multi6/somewhere on the > ingress filtering problem. > > Comments? > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 14 14:48:50 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06320 for ; Wed, 14 Jan 2004 14:48:49 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EJkeYG014695; Wed, 14 Jan 2004 20:46:40 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDFPYYW; Wed, 14 Jan 2004 20:46:40 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EJkawg022596; Wed, 14 Jan 2004 20:46:37 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EJjwIt021411; Wed, 14 Jan 2004 20:45:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EJjwPU021410; Wed, 14 Jan 2004 20:45:58 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EJjtIt021394 for ; Wed, 14 Jan 2004 20:45:55 +0100 (MET) Received: from kolumbus.fi ([62.248.150.81]) by fep02-app.kolumbus.fi with ESMTP id <20040114194554.UFZP15326.fep02-app.kolumbus.fi@kolumbus.fi>; Wed, 14 Jan 2004 21:45:54 +0200 Message-ID: <40059C1E.80409@kolumbus.fi> Date: Wed, 14 Jan 2004 21:44:30 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: James Kempf , ietf-send@standards.ericsson.net Subject: Re: moving on with issue 47 (routing vs. advertisement rights) References: <9E3BA3946476AD4EB94672712B12A85F04208A@ftmail.lab.flarion.com> <076c01c3daba$9b1fa360$606015ac@dclkempt40> In-Reply-To: <076c01c3daba$9b1fa360$606015ac@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 Hesham wrote: > In any case, this is going to affect any multihomed link, > i.e. that has more than one router connected to different > networks. Does anyone know where this should be addressed? > IPv6 WG?? It affects PANA, nemo, multi6, IPv6 ....etc and James wrote: > Not sure. IPv6 is trying to finish up, so it might not be the right place. > I'll raise the issue with the ADs and make sure it doesn't drop, then see > what they say. Perhaps even a small, focussed, short term WG, like SEND. I have an idea. I seem to recall that there was some effort regarding RFC 2461 updates in IPv6 WG. In fact, I think the idea was to fix all the bugs. Not taking ingress filtering in account qualifies as a bug, don't you think so? If so, we have a good candidate for the person who needs to fix this problem. Hesham, do you happen to remember who was editing RFC 2461 bis? ;-) --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 Jan 14 17:25:01 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17896 for ; Wed, 14 Jan 2004 17:24:59 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EML5YG028339; Wed, 14 Jan 2004 23:21:10 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJAJ1Z85; Wed, 14 Jan 2004 23:21:05 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EMKrwg000551; Wed, 14 Jan 2004 23:20:53 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EMK7It001647; Wed, 14 Jan 2004 23:20:07 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EMK7VK001644; Wed, 14 Jan 2004 23:20:07 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EMK5It001627 for ; Wed, 14 Jan 2004 23:20:06 +0100 (MET) Received: from kolumbus.fi ([62.248.150.81]) by fep21-app.kolumbus.fi with ESMTP id <20040114222005.LFZN27281.fep21-app.kolumbus.fi@kolumbus.fi>; Thu, 15 Jan 2004 00:20:05 +0200 Message-ID: <4005C041.8070809@kolumbus.fi> Date: Thu, 15 Jan 2004 00:18:41 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: ietf-send@standards.ericsson.net, kempf@docomolabs-usa.com, pekkas@netcore.fi, greg.daley@eng.monash.edu.au Subject: Re: moving on with issue 47 (routing vs. advertisement rights) References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> In-Reply-To: <006b01c3dacd$1dc50d70$c91167c0@adithya> 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 Mohan, > I looked at the latest version you posted below. A couple of > questions.. > > In section 6.1.1, > > The X.509 IP address extension MUST contain at least one > addressesOrRanges element. This element MUST contain an > addressPrefix element with an IPv6 address prefix for a prefix the > router or the intermediate entity is authorized to advertise. If the > entity is allowed to route any prefix, the used IPv6 address prefix > is the null prefix, 0/0. > > - The first part says nothing about routing for the prefix. It says > ".. authorized to > advertise". If we don't want to use it for routing at all, then can we be explicit ? > Or i am confused with the resolution here, as the next line talks about routing > for the prefix also. In any case, it should be explicitly stated here. I agree that this needs to fixed. I forgot this part. > - If the IPv6 address prefix is the null prefix, then you can't validate the prefix like > other prefixes, right ? If we can't, we should mention this explicitly. I'm not sure I understand this. It seems like we need to define the null prefix to be 0/0 so that any further delegation would work correctly, in case prefixes are used there and we need to ensure that delegated prefixes are subsets of the original prefixes. Note: Null prefix != empty set. Null prefix is more like the set of all possible prefixes. > In section 7.3, > > If the network operator wants to constrain which routers support > particular prefixes, routers SHOULD be configured with certificates > having prefixes listed in the prefix extension. Routers so > configured MUST advertise the prefixes for which they are certified, > or a subset thereof. > > The use of the word "support" is confusing in the first line. Did you > mean "support routing .." ? > > Network operators that do not want to constrain particular routers to > specific prefixes SHOULD configure routers with certificates > containing either the null prefix or no prefix extension at all. > > Did you mean "routers to route specific prefixes" ? I agree that these parts are confusing as well. I guess our earlier discussion with James about the routing vs. advertisement rights started from the fact that it was unclear whether the certs give routing or advertisement rights. James then argued that (a) PKIX drafts talk about routing rights and that (b) there's no real difference between routing and advertisement rights. Actually, I think advertisement rights must be a subset of routing rights (even if the advertising router does not offer itself as a default router). In the new agreement that we had, the ingress filtering problem is shifted to someone else. This implies that we have no use for the specific routing rights check. However, we still have a use for the advertisement rights check, which per above are a subset of the routing rights. In conclusion, I think the text should say the certs carry routing rights, and that advertisements must fall within the routing rights. Here's the modified draft: http://www.arkko.com/publications/send/issues/issue47diff.html http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 14 17:34:35 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18192 for ; Wed, 14 Jan 2004 17:34:34 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EMWUqY028469; Wed, 14 Jan 2004 23:32:30 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDFQ3NQ; Wed, 14 Jan 2004 23:32:30 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0EMWTXA021707; Wed, 14 Jan 2004 23:32:29 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EMW3It004927; Wed, 14 Jan 2004 23:32:03 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0EMW39A004926; Wed, 14 Jan 2004 23:32:03 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0EMW1It004922 for ; Wed, 14 Jan 2004 23:32:02 +0100 (MET) Message-ID: <13f601c3daee$2eb7e0a0$606015ac@dclkempt40> From: "James Kempf" To: "Jari Arkko" , "Mohan Parthasarathy" Cc: , , References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 14 Jan 2004 14:31:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Jari, I agree with your proposal for specifying that advertising rights are a subset of routing rights. jak ----- Original Message ----- From: "Jari Arkko" To: "Mohan Parthasarathy" Cc: ; ; ; Sent: Wednesday, January 14, 2004 2:18 PM Subject: Re: moving on with issue 47 (routing vs. advertisement rights) > Mohan, > > > I looked at the latest version you posted below. A couple of > > questions.. > > > In section 6.1.1, > > > > The X.509 IP address extension MUST contain at least one > > addressesOrRanges element. This element MUST contain an > > addressPrefix element with an IPv6 address prefix for a prefix the > > router or the intermediate entity is authorized to advertise. If the > > entity is allowed to route any prefix, the used IPv6 address prefix > > is the null prefix, 0/0. > > > > - The first part says nothing about routing for the prefix. It says > > ".. authorized to > > advertise". If we don't want to use it for routing at all, then can we be explicit ? > > Or i am confused with the resolution here, as the next line talks about routing > > for the prefix also. In any case, it should be explicitly stated here. > > I agree that this needs to fixed. I forgot this part. > > > - If the IPv6 address prefix is the null prefix, then you can't validate the prefix like > > other prefixes, right ? If we can't, we should mention this explicitly. > > I'm not sure I understand this. It seems like we need to > define the null prefix to be 0/0 so that any further delegation > would work correctly, in case prefixes are used there and we need > to ensure that delegated prefixes are subsets of the original > prefixes. > > Note: Null prefix != empty set. Null prefix is more like the set of all > possible prefixes. > > > In section 7.3, > > > > If the network operator wants to constrain which routers support > > particular prefixes, routers SHOULD be configured with certificates > > having prefixes listed in the prefix extension. Routers so > > configured MUST advertise the prefixes for which they are certified, > > or a subset thereof. > > > > The use of the word "support" is confusing in the first line. Did you > > mean "support routing .." ? > > > > Network operators that do not want to constrain particular routers to > > specific prefixes SHOULD configure routers with certificates > > containing either the null prefix or no prefix extension at all. > > > > Did you mean "routers to route specific prefixes" ? > > I agree that these parts are confusing as well. > > I guess our earlier discussion with James about the routing vs. > advertisement rights started from the fact that it was unclear > whether the certs give routing or advertisement rights. James > then argued that (a) PKIX drafts talk about routing rights and > that (b) there's no real difference between routing and advertisement > rights. Actually, I think advertisement rights must be a subset > of routing rights (even if the advertising router does not offer > itself as a default router). > > In the new agreement that we had, the ingress filtering problem > is shifted to someone else. This implies that we have no use for > the specific routing rights check. However, we still have a use > for the advertisement rights check, which per above are a subset > of the routing rights. In conclusion, I think the text should say > the certs carry routing rights, and that advertisements must fall > within the routing rights. > > Here's the modified draft: > http://www.arkko.com/publications/send/issues/issue47diff.html > http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt > > --Jari > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 14 18:51:13 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22183 for ; Wed, 14 Jan 2004 18:51:13 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0ENmbAh014499; Thu, 15 Jan 2004 00:48:37 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBSMB4W; Thu, 15 Jan 2004 00:50:09 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0ENmYwg004428; Thu, 15 Jan 2004 00:48:34 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0ENlwIt024603; Thu, 15 Jan 2004 00:47:58 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0ENlw1s024602; Thu, 15 Jan 2004 00:47:58 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0ENlvIt024598 for ; Thu, 15 Jan 2004 00:47:57 +0100 (MET) Received: from kolumbus.fi ([62.248.150.81]) by fep21-app.kolumbus.fi with ESMTP id <20040114234757.LUYK27281.fep21-app.kolumbus.fi@kolumbus.fi> for ; Thu, 15 Jan 2004 01:47:57 +0200 Message-ID: <4005D4D9.8040907@kolumbus.fi> Date: Thu, 15 Jan 2004 01:46:33 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: draft 02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I have sent draft 02 to the secretariat. I realize we are once again in a situation where its unclear if there's consensus on the final remaing issue, since the proposed resolution was posted just a small time ago, even if it seemed sensible to me. But I'll be out of town for a few days, so it had to be now or next week. Luckily, the danger of wrapping around the I-D counter on this draft is not imminent ;-) so we can issue -03 next week if necessary. The draft is at http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-02.txt http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-02.html http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-02diff.html --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 14 20:46:21 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25803 for ; Wed, 14 Jan 2004 20:46:21 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0F1iBYG014930; Thu, 15 Jan 2004 02:44:11 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBSMPRK; Thu, 15 Jan 2004 02:45:42 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0F1i9XA023568; Thu, 15 Jan 2004 02:44:09 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0F1g5It026563; Thu, 15 Jan 2004 02:42:05 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0F1g53x026562; Thu, 15 Jan 2004 02:42:05 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0F1g3It026558 for ; Thu, 15 Jan 2004 02:42:04 +0100 (MET) Received: from localhost ([130.194.13.81]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L5FF8YEHIM9KRYR2@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 15 Jan 2004 12:39:24 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 6DA2A1B000E; Thu, 15 Jan 2004 12:39:21 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 3BCF0124004; Thu, 15 Jan 2004 12:39:21 +1100 (EST) Date: Thu, 15 Jan 2004 12:39:21 +1100 From: Greg Daley Subject: Re: moving on with issue 47 (routing vs. advertisement rights) To: Jari Arkko Cc: Mohan Parthasarathy , ietf-send@standards.ericsson.net, kempf@docomolabs-usa.com, pekkas@netcore.fi Reply-to: greg.daley@eng.monash.edu.au Message-id: <4005EF49.2010905@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Jari, Jari Arkko wrote: > Mohan, > >> I looked at the latest version you posted below. A couple of >> questions.. >> >> In section 6.1.1, >> >> The X.509 IP address extension MUST contain at least one >> addressesOrRanges element. This element MUST contain an >> addressPrefix element with an IPv6 address prefix for a prefix the >> router or the intermediate entity is authorized to advertise. If the >> entity is allowed to route any prefix, the used IPv6 address prefix >> is the null prefix, 0/0. >> >> - The first part says nothing about routing for the prefix. It says >> ".. authorized to >> advertise". If we don't want to use it for routing at all, then >> can we be explicit ? >> Or i am confused with the resolution here, as the next line talks >> about routing >> for the prefix also. In any case, it should be explicitly stated >> here. > > > I agree that this needs to fixed. I forgot this part. > >> - If the IPv6 address prefix is the null prefix, then you can't >> validate the prefix like >> other prefixes, right ? If we can't, we should mention this >> explicitly. > > > I'm not sure I understand this. It seems like we need to > define the null prefix to be 0/0 so that any further delegation > would work correctly, in case prefixes are used there and we need > to ensure that delegated prefixes are subsets of the original > prefixes. > > Note: Null prefix != empty set. Null prefix is more like the set of all > possible prefixes. At a first glance this seems OK to me. (Explicitly indicating this seems like the way to go) We'll need to check with the PKIX and SxBGP people to ensure that we understand the existing semantics for using the 0/0 prefix in a certificate when the AFI is 0x0002 (IPv6) and there is no SAFI. These certificates as defined at the moment apply to all IPv6 routing (No SAFI), and so the presence of a default route authorization in a certificate for SEND could mean something else in BGP. Otherwise, we will need to define a new SAFI for last hop routing which will partition the effect of these changes to only apply to SEND (at the cost of requiring another IPAddressFamily). There is a block of SAFIs (up to 64) which is allocated as FCFS, if this helps. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jan 15 11:18:27 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13377 for ; Thu, 15 Jan 2004 11:18:25 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0FGF5YG017024; Thu, 15 Jan 2004 17:15:10 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJAJLVNP; Thu, 15 Jan 2004 17:15:05 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0FGEpwg021273; Thu, 15 Jan 2004 17:14:51 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0FGChIt018312; Thu, 15 Jan 2004 17:12:43 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0FGCgk5018311; Thu, 15 Jan 2004 17:12:42 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0FGCeIt018292 for ; Thu, 15 Jan 2004 17:12:41 +0100 (MET) Message-ID: <14e601c3db82$6cccac10$606015ac@dclkempt40> From: "James Kempf" To: , "Jari Arkko" Cc: "Mohan Parthasarathy" , , References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> <4005EF49.2010905@eng.monash.edu.au> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Thu, 15 Jan 2004 08:12:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Greg, > At a first glance this seems OK to me. > (Explicitly indicating this seems like the way to go) > > We'll need to check with the PKIX and SxBGP people > to ensure that we understand the existing semantics > for using the 0/0 prefix in a certificate when the > AFI is 0x0002 (IPv6) and there is no SAFI. > I will put them on the review list for the draft. > These certificates as defined at the moment apply > to all IPv6 routing (No SAFI), and so the presence > of a default route authorization in a certificate > for SEND could mean something else in BGP. > I don't believe networks typically do RFC 2461 Router Advertisement directly on the Internet, thus the certs applying to interfaces on which 2461 advertising is done would typically be different from the certs used for SxBGP. They both use the same extension format and I would expect that they would both use the same cert chain, however. But perhaps I am missing something. > Otherwise, we will need to define a new SAFI for > last hop routing which will partition the > effect of these changes to only apply to SEND > (at the cost of requiring another IPAddressFamily). > > There is a block of SAFIs (up to 64) which is allocated > as FCFS, if this helps. > I'm not sure I understand, could you explain more? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jan 15 13:30:21 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18635 for ; Thu, 15 Jan 2004 13:30:16 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0FIP5qY010469; Thu, 15 Jan 2004 19:25:06 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJAJMS3L; Thu, 15 Jan 2004 19:25:05 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0FIOmwg028784; Thu, 15 Jan 2004 19:24:48 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0FIO6It023335; Thu, 15 Jan 2004 19:24:06 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0FIO5jo023333; Thu, 15 Jan 2004 19:24:05 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from smtp812.mail.sc5.yahoo.com (smtp812.mail.sc5.yahoo.com [66.163.170.82]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with SMTP id i0FIO3It023310 for ; Thu, 15 Jan 2004 19:24:04 +0100 (MET) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 15 Jan 2004 18:24:02 -0000 Message-ID: <004b01c3db94$c34752e0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" Cc: , , , References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Thu, 15 Jan 2004 10:24:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > Mohan, > > > I looked at the latest version you posted below. A couple of > > questions.. > > > > In section 6.1.1, > > > > The X.509 IP address extension MUST contain at least one > > addressesOrRanges element. This element MUST contain an > > addressPrefix element with an IPv6 address prefix for a prefix the > > router or the intermediate entity is authorized to advertise. If the > > entity is allowed to route any prefix, the used IPv6 address prefix > > is the null prefix, 0/0. > > > > - The first part says nothing about routing for the prefix. It says > > ".. authorized to > > advertise". If we don't want to use it for routing at all, then can we be explicit ? > > Or i am confused with the resolution here, as the next line talks about routing > > for the prefix also. In any case, it should be explicitly stated here. > > I agree that this needs to fixed. I forgot this part. > > > - If the IPv6 address prefix is the null prefix, then you can't validate the prefix like > > other prefixes, right ? If we can't, we should mention this explicitly. > > I'm not sure I understand this. It seems like we need to > define the null prefix to be 0/0 so that any further delegation > would work correctly, in case prefixes are used there and we need > to ensure that delegated prefixes are subsets of the original > prefixes. > > Note: Null prefix != empty set. Null prefix is more like the set of all > possible prefixes. > I was trying to apply the example given in section 6.1.1. What would the certificate issued by isp_group.com have if i see a null prefix in the isp_foo.com's certificate ? Your example shows how one should do the IP address check in the certificate chain. Does it directly apply to null prefix ? > > In section 7.3, > > > > If the network operator wants to constrain which routers support > > particular prefixes, routers SHOULD be configured with certificates > > having prefixes listed in the prefix extension. Routers so > > configured MUST advertise the prefixes for which they are certified, > > or a subset thereof. > > > > The use of the word "support" is confusing in the first line. Did you > > mean "support routing .." ? > > > > Network operators that do not want to constrain particular routers to > > specific prefixes SHOULD configure routers with certificates > > containing either the null prefix or no prefix extension at all. > > > > Did you mean "routers to route specific prefixes" ? > > I agree that these parts are confusing as well. > > I guess our earlier discussion with James about the routing vs. > advertisement rights started from the fact that it was unclear > whether the certs give routing or advertisement rights. James > then argued that (a) PKIX drafts talk about routing rights and > that (b) there's no real difference between routing and advertisement > rights. Actually, I think advertisement rights must be a subset > of routing rights (even if the advertising router does not offer > itself as a default router). > I agree with this. > In the new agreement that we had, the ingress filtering problem > is shifted to someone else. This implies that we have no use for > the specific routing rights check. However, we still have a use > for the advertisement rights check, which per above are a subset > of the routing rights. In conclusion, I think the text should say > the certs carry routing rights, and that advertisements must fall > within the routing rights. > > Here's the modified draft: > http://www.arkko.com/publications/send/issues/issue47diff.html > http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt > Sounds okay now. -mohan > --Jari > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jan 15 17:46:44 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06217 for ; Thu, 15 Jan 2004 17:46:43 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0FMiIqY009017; Thu, 15 Jan 2004 23:44:18 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJAJ31AW; Thu, 15 Jan 2004 23:44:18 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0FMiCwg011312; Thu, 15 Jan 2004 23:44:12 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0FMhXIt002105; Thu, 15 Jan 2004 23:43:33 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0FMhX4o002095; Thu, 15 Jan 2004 23:43:33 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0FMhUIt002090 for ; Thu, 15 Jan 2004 23:43:31 +0100 (MET) Received: from localhost ([130.194.13.84]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L5GNCG268M9BWJOV@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Fri, 16 Jan 2004 09:42:03 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id AE26C39C00D; Fri, 16 Jan 2004 09:42:01 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 786922DC00C; Fri, 16 Jan 2004 09:42:01 +1100 (EST) Date: Fri, 16 Jan 2004 09:42:01 +1100 From: Greg Daley Subject: Re: moving on with issue 47 (routing vs. advertisement rights) To: James Kempf Cc: Jari Arkko , Mohan Parthasarathy , ietf-send@standards.ericsson.net, pekkas@netcore.fi Reply-to: greg.daley@eng.monash.edu.au Message-id: <40071739.3040505@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> <4005EF49.2010905@eng.monash.edu.au> <14e601c3db82$6cccac10$606015ac@dclkempt40> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > Greg, > > >>At a first glance this seems OK to me. >>(Explicitly indicating this seems like the way to go) >> >>We'll need to check with the PKIX and SxBGP people >>to ensure that we understand the existing semantics >>for using the 0/0 prefix in a certificate when the >>AFI is 0x0002 (IPv6) and there is no SAFI. >> > > > I will put them on the review list for the draft. > > >>These certificates as defined at the moment apply >>to all IPv6 routing (No SAFI), and so the presence >>of a default route authorization in a certificate >>for SEND could mean something else in BGP. >> > > > I don't believe networks typically do RFC 2461 Router Advertisement directly > on the Internet, thus the certs applying to interfaces on which 2461 > advertising is done would typically be different from the certs used for > SxBGP. They both use the same extension format and I would expect that they > would both use the same cert chain, however. But perhaps I am missing > something. > I think the issue is not that RA messaging will be be on the Internet, although I'd guess that the ability to route a prefix (being delegated to a particular public key) would only be signed once by a CA. Even if multiple certificates are applied to a router, I'd guess that these would be for different security domains/interfaces, so no (explicit) overlap in authorized prefixes authority would exist in any pair of a router's certificates (except when changing to new certs). The Advertisement of this prefix (say with BGP) into the routing cloud could therefore use the same certificate as SEND uses to verify authorization over routing from/to that prefix. Since the proposal is to use the Address Family (IPv6) with no sub-address family, including the 0/0 prefix may indicate that the router is allowed to advertise default routes into the routing cloud. >>Otherwise, we will need to define a new SAFI for >>last hop routing which will partition the >>effect of these changes to only apply to SEND >>(at the cost of requiring another IPAddressFamily). >> >>There is a block of SAFIs (up to 64) which is allocated >>as FCFS, if this helps. >> > > > I'm not sure I understand, could you explain more? RFC 2858 (Multiprotocol extensions for BGP) defines the AFI/SAFI notation, and how it's interpreted in BGP. This document has an IANA considerations section which allows allocation of SAFIs 64-127 as first come first served through the IANA. That is, if we need one, there's no need for IETF approval. Alternatively, SAFI can be assigned with IETF Consensus, when SEND is published. If the BGP people say it's necessary, I'd guess that it wouldn't be a problem. Details can be found at: http://www.iana.org/assignments/safi-namespace Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jan 16 16:57:58 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01512 for ; Fri, 16 Jan 2004 16:57:53 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0GLtMYG000198; Fri, 16 Jan 2004 22:55:23 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR32FBW4; Fri, 16 Jan 2004 22:58:00 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0GLtGwg016743; Fri, 16 Jan 2004 22:55:17 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0GLr4It024754; Fri, 16 Jan 2004 22:53:04 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0GLr4Jw024745; Fri, 16 Jan 2004 22:53:04 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0GLr1It024728 for ; Fri, 16 Jan 2004 22:53:02 +0100 (MET) Message-ID: <02b501c3dc7b$22818eb0$5b6015ac@dclkempt40> From: "James Kempf" To: Cc: "Jari Arkko" , "Mohan Parthasarathy" , , References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> <4005EF49.2010905@eng.monash.edu.au> <14e601c3db82$6cccac10$606015ac@dclkempt40> <40071739.3040505@eng.monash.edu.au> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Fri, 16 Jan 2004 13:53:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Greg, > Since the proposal is to use the Address Family > (IPv6) with no sub-address family, including the > 0/0 prefix may indicate that the router is > allowed to advertise default routes into the > routing cloud. > I think I understand your point now. If the border routers are configured with certificates for a particular address range, then the access routers should, logically, always be configured with certificates for a subset of the address range advertised by the border routers, not 0/0. Right? The assumption behind the 0/0 prefix extension is that the certificates in the access routers won't be used for BGP, that is, that the access routers are not participating in BGP, though that might not be a valid assumption if the access routers are termination points of an iBGP session. The primary issue here is that we would like the SEND certificates to be easily deployable without having to deploy sBGP certs, and we would like some indication that the router is allowed to route any prefix if sBGP is not deployed. If sBGP is deployed, then the SEND certificates should naturally reflect a subset of the prefixes the domain is allowed to route (which could be exactly the same as in the certificates on the border routers, if the access router is allowed to route anything). How about this: - if certificates are being used on border routers, then the SEND certs MUST contain an IP Address Delegation extension, and the advertised prefixes MUST be a subset of those advertised for the domain. - if certificates are not being used on border routers, then the SEND certs MAY omit the IP Address Delegation extension if the router is allowed to route any prefix. This would eliminate the confustion about 0/0 being a default route. I think we can word this such that we don't have any normative dependence on a particular secure BGP proposal. >Otherwise, we will need to define a new SAFI for > >>last hop routing which will partition the > >>effect of these changes to only apply to SEND > >>(at the cost of requiring another IPAddressFamily). > >> > >>There is a block of SAFIs (up to 64) which is allocated > >>as FCFS, if this helps. > >> > > > > > > I'm not sure I understand, could you explain more? > > RFC 2858 (Multiprotocol extensions for BGP) > defines the AFI/SAFI notation, and how it's > interpreted in BGP. > > This document has an IANA considerations section > which allows allocation of SAFIs 64-127 as > first come first served through the IANA. > That is, if we need one, there's no need for IETF > approval. > > Alternatively, SAFI can be assigned with IETF Consensus, > when SEND is published. If the BGP people say > it's necessary, I'd guess that it wouldn't be a problem. > > Details can be found at: > > http://www.iana.org/assignments/safi-namespace > I don't think we need a new SAFI. The forwarding being indicated by the SAFI are exactly the same as those for the BGP certs. 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 Sun Jan 18 22:18:37 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13977 for ; Sun, 18 Jan 2004 22:18:36 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0J3EMqY005356; Mon, 19 Jan 2004 04:14:22 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBTMMQH; Mon, 19 Jan 2004 04:16:08 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0J3ELXA004962; Mon, 19 Jan 2004 04:14:21 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0J39IIt004465; Mon, 19 Jan 2004 04:09:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0J39IBR004455; Mon, 19 Jan 2004 04:09:18 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0J39EIt004254 for ; Mon, 19 Jan 2004 04:09:16 +0100 (MET) Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L5KZTOY3MY901M83@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Mon, 19 Jan 2004 12:22:42 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id D739723C00C; Mon, 19 Jan 2004 12:22:41 +1100 (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 C352C164003; Mon, 19 Jan 2004 12:22:41 +1100 (EST) Date: Mon, 19 Jan 2004 12:22:41 +1100 From: Greg Daley Subject: Re: moving on with issue 47 (routing vs. advertisement rights) To: James Kempf Cc: Jari Arkko , Mohan Parthasarathy , ietf-send@standards.ericsson.net, pekkas@netcore.fi Reply-to: greg.daley@eng.monash.edu.au Message-id: <400B3161.1040805@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: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> <4005EF49.2010905@eng.monash.edu.au> <14e601c3db82$6cccac10$606015ac@dclkempt40> <40071739.3040505@eng.monash.edu.au> <02b501c3dc7b$22818eb0$5b6015ac@dclkempt40> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > Greg, > > >>Since the proposal is to use the Address Family >>(IPv6) with no sub-address family, including the >>0/0 prefix may indicate that the router is >>allowed to advertise default routes into the >>routing cloud. >> > > > I think I understand your point now. If the border routers are configured > with certificates for a particular address range, then the access routers > should, logically, always be configured with certificates for a subset of > the address range advertised by the border routers, not 0/0. Right? > > The assumption behind the 0/0 prefix extension is that the certificates in > the access routers won't be used for BGP, that is, that the access routers > are not participating in BGP, though that might not be a valid assumption if > the access routers are termination points of an iBGP session. indeed :) > The primary issue here is that we would like the SEND certificates to be > easily deployable without having to deploy sBGP certs, and we would like > some indication that the router is allowed to route any prefix if sBGP is > not deployed. If sBGP is deployed, then the SEND certificates should > naturally reflect a subset of the prefixes the domain is allowed to route > (which could be exactly the same as in the certificates on the border > routers, if the access router is allowed to route anything). > > How about this: > > - if certificates are being used on border routers, then the SEND certs MUST > contain an IP Address Delegation extension, and the advertised prefixes MUST > be a subset of those advertised for the domain. > > - if certificates are not being used on border routers, then the SEND certs > MAY omit the IP Address Delegation extension if the router is allowed to > route any prefix. > > This would eliminate the confustion about 0/0 being a default route. > > I think we can word this such that we don't have any normative dependence on > a particular secure BGP proposal. This sounds good to me. So long as the trust chain goes back to an authority we trust to make these decisions, it may be OK. > >>Otherwise, we will need to define a new SAFI for >> >>>>last hop routing which will partition the >>>>effect of these changes to only apply to SEND >>>>(at the cost of requiring another IPAddressFamily). >>>> >>>>There is a block of SAFIs (up to 64) which is allocated >>>>as FCFS, if this helps. >>>> >>> >>> >>>I'm not sure I understand, could you explain more? >> >>RFC 2858 (Multiprotocol extensions for BGP) >>defines the AFI/SAFI notation, and how it's >>interpreted in BGP. >> >>This document has an IANA considerations section >>which allows allocation of SAFIs 64-127 as >>first come first served through the IANA. >>That is, if we need one, there's no need for IETF >>approval. >> >>Alternatively, SAFI can be assigned with IETF Consensus, >>when SEND is published. If the BGP people say >>it's necessary, I'd guess that it wouldn't be a problem. >> >>Details can be found at: >> >>http://www.iana.org/assignments/safi-namespace >> > > > > I don't think we need a new SAFI. The forwarding being indicated by the SAFI > are exactly the same as those for the BGP certs. That's my belief too, so I'm glad if we're able to use the same certs. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Mon Jan 19 06:04:09 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12022 for ; Mon, 19 Jan 2004 06:04:03 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0JB0aYG028651; Mon, 19 Jan 2004 12:00:37 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR32WY35; Mon, 19 Jan 2004 12:02:39 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0JAx4wg016830; Mon, 19 Jan 2004 11:59:04 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0JAp2It017451; Mon, 19 Jan 2004 11:51:10 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0JAoJZe017319; Mon, 19 Jan 2004 11:50:19 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0JAnBIt017198 for ; Mon, 19 Jan 2004 11:49:18 +0100 (MET) Received: from [127.0.0.1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id C9E161C; Mon, 19 Jan 2004 13:01:47 +0200 (EET) In-Reply-To: <02b501c3dc7b$22818eb0$5b6015ac@dclkempt40> References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> <4005EF49.2010905@eng.monash.edu.au> <14e601c3db82$6cccac10$606015ac@dclkempt40> <40071739.3040505@eng.monash.edu.au> <02b501c3dc7b$22818eb0$5b6015ac@dclkempt40> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <95CBA3AE-4A68-11D8-86DC-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , "Mohan Parthasarathy" , , "Jari Arkko" , From: Pekka Nikander Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Mon, 19 Jan 2004 12:16:45 +0200 To: "James Kempf" X-Mailer: Apple Mail (2.609) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit James, On Jan 16, 2004, at 23:53, James Kempf wrote: > - if certificates are not being used on border routers, then the SEND > certs > MAY omit the IP Address Delegation extension if the router is allowed > to > route any prefix. I don't like this. I'm afraid that this would allow "wrong" type of certificates to be used for SEND. Maybe not a major security issue, but anyway something that should be avoided. One of the biggest problems with many of the current (and especially those build already some time ago) certificate approaches are too lax semantics. That is, it should be immediately clear from a certificate what it is good for. If a certificate does not contain an IP Address Delegation extension, some other type of certificate could be used for SEND. That may be bad. Given that, I can live with the MAY you proposed provided that there is a cross reference to the security consideration section at the spot and good explanation of the problem in the sec cons. But I still would prefer 0/0. My interpretation of the current text is that the semantics are clear, and I didn't quite understand how Greg found them confusing (sorry Greg). But I haven't been able to follow too closely. > I don't think we need a new SAFI. The forwarding being indicated by > the SAFI > are exactly the same as those for the BGP certs. Agreed. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jan 20 17:19:22 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28287 for ; Tue, 20 Jan 2004 17:19:20 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0KMGfAh006046; Tue, 20 Jan 2004 23:16:45 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBT9MYA; Tue, 20 Jan 2004 23:18:33 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0KMGeXA004456; Tue, 20 Jan 2004 23:16:40 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0KMEIIt025653; Tue, 20 Jan 2004 23:14:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0KMEIs4025652; Tue, 20 Jan 2004 23:14:18 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0KMEGIt025648 for ; Tue, 20 Jan 2004 23:14:16 +0100 (MET) Message-ID: <001c01c3dfa2$bb25d2a0$5b6015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" Cc: , "Mohan Parthasarathy" , , "Jari Arkko" , References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> <4005EF49.2010905@eng.monash.edu.au> <14e601c3db82$6cccac10$606015ac@dclkempt40> <40071739.3040505@eng.monash.edu.au> <02b501c3dc7b$22818eb0$5b6015ac@dclkempt40> <95CBA3AE-4A68-11D8-86DC-000393CE1E8C@nomadiclab.com> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Tue, 20 Jan 2004 14:14:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > I don't like this. I'm afraid that this would allow "wrong" type > of certificates to be used for SEND. Maybe not a major security > issue, but anyway something that should be avoided. > > One of the biggest problems with many of the current (and especially > those build already some time ago) certificate approaches are > too lax semantics. That is, it should be immediately clear from > a certificate what it is good for. If a certificate does not contain > an IP Address Delegation extension, some other type of certificate > could be used for SEND. That may be bad. > > Given that, I can live with the MAY you proposed provided that > there is a cross reference to the security consideration section at > the spot and good explanation of the problem in the sec cons. > > But I still would prefer 0/0. My interpretation of the current > text is that the semantics are clear, and I didn't quite understand > how Greg found them confusing (sorry Greg). But I haven't been > able to follow too closely. > Ok. What about if we say that a router MAY use a certificate with an address range extension 0/0 only if router is not part of a domain with certified delegation from IANA? Otherwise, the address range extension MUST NOT have value 0/0. This means that the router is advertising a default route (which would typically be ok for a border router) but it will not propagate outside the domain. Greg, what do you think? jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Tue Jan 20 17:29:28 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28610 for ; Tue, 20 Jan 2004 17:29:27 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0KMROqY007934; Tue, 20 Jan 2004 23:27:24 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJBT93DM; Tue, 20 Jan 2004 23:29:16 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0KMRGwg013070; Tue, 20 Jan 2004 23:27:17 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0KMPQIt028845; Tue, 20 Jan 2004 23:25:26 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0KMPQEY028844; Tue, 20 Jan 2004 23:25:26 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0KMPOIt028840 for ; Tue, 20 Jan 2004 23:25:25 +0100 (MET) Message-ID: <002601c3dfa4$5079dc60$5b6015ac@dclkempt40> From: "James Kempf" To: "James Kempf" , "Pekka Nikander" Cc: , "Mohan Parthasarathy" , , "Jari Arkko" , References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> <4005EF49.2010905@eng.monash.edu.au> <14e601c3db82$6cccac10$606015ac@dclkempt40> <40071739.3040505@eng.monash.edu.au> <02b501c3dc7b$22818eb0$5b6015ac@dclkempt40> <95CBA3AE-4A68-11D8-86DC-000393CE1E8C@nomadiclab.com> <001c01c3dfa2$bb25d2a0$5b6015ac@dclkempt40> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Tue, 20 Jan 2004 14:25:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Kempf" To: "Pekka Nikander" Cc: ; "Mohan Parthasarathy" ; ; "Jari Arkko" ; Sent: Tuesday, January 20, 2004 2:14 PM Subject: Re: moving on with issue 47 (routing vs. advertisement rights) > > > I don't like this. I'm afraid that this would allow "wrong" type > > of certificates to be used for SEND. Maybe not a major security > > issue, but anyway something that should be avoided. > > > > One of the biggest problems with many of the current (and especially > > those build already some time ago) certificate approaches are > > too lax semantics. That is, it should be immediately clear from > > a certificate what it is good for. If a certificate does not contain > > an IP Address Delegation extension, some other type of certificate > > could be used for SEND. That may be bad. > > > > Given that, I can live with the MAY you proposed provided that > > there is a cross reference to the security consideration section at > > the spot and good explanation of the problem in the sec cons. > > > > But I still would prefer 0/0. My interpretation of the current > > text is that the semantics are clear, and I didn't quite understand > > how Greg found them confusing (sorry Greg). But I haven't been > > able to follow too closely. > > > > Ok. > > What about if we say that a router MAY use a certificate with an address > range extension 0/0 only if router is not part of a domain with certified > delegation from IANA? Otherwise, the address range extension MUST NOT have > value 0/0. This means that the router is advertising a default route (which > would typically be ok for a border router) but it will not propagate outside > the domain. > > Greg, what do you think? > Sorry, I meant "would be ok for an access router" not a border router. An access router typically provides default routes for nodes on its subnet. 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 Jan 21 02:48:38 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10865 for ; Wed, 21 Jan 2004 02:48:38 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0L7jvqY018071; Wed, 21 Jan 2004 08:45:57 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDH2WKX; Wed, 21 Jan 2004 08:45:57 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0L7juXA008248; Wed, 21 Jan 2004 08:45:56 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0L7hmIt010456; Wed, 21 Jan 2004 08:43:48 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0L7hmhQ010455; Wed, 21 Jan 2004 08:43:48 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0L7hkIt010451 for ; Wed, 21 Jan 2004 08:43:47 +0100 (MET) Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 60C8B1C; Wed, 21 Jan 2004 09:56:38 +0200 (EET) In-Reply-To: <002601c3dfa4$5079dc60$5b6015ac@dclkempt40> References: <20040114111229.CITL27281.fep21-app.kolumbus.fi@mta.imail.kolumbus.fi> <006b01c3dacd$1dc50d70$c91167c0@adithya> <4005C041.8070809@kolumbus.fi> <4005EF49.2010905@eng.monash.edu.au> <14e601c3db82$6cccac10$606015ac@dclkempt40> <40071739.3040505@eng.monash.edu.au> <02b501c3dc7b$22818eb0$5b6015ac@dclkempt40> <95CBA3AE-4A68-11D8-86DC-000393CE1E8C@nomadiclab.com> <001c01c3dfa2$bb25d2a0$5b6015ac@dclkempt40> <002601c3dfa4$5079dc60$5b6015ac@dclkempt40> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8F03C321-4BE5-11D8-85D4-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , "Mohan Parthasarathy" , , "Jari Arkko" , From: Pekka Nikander Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 21 Jan 2004 09:43:52 +0200 To: "James Kempf" X-Mailer: Apple Mail (2.609) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit >>> I don't like this. I'm afraid that this would allow "wrong" type >>> of certificates to be used for SEND. Maybe not a major security >>> issue, but anyway something that should be avoided. >>> >>> Given that, I can live with the MAY you proposed provided that >>> there is a cross reference to the security consideration section at >>> the spot and good explanation of the problem in the sec cons. >>> >>> But I still would prefer 0/0. My interpretation of the current >>> text is that the semantics are clear, and I didn't quite understand >>> how Greg found them confusing (sorry Greg). But I haven't been >>> able to follow too closely. >> >> Ok. >> >> What about if we say that a router MAY use a certificate with an >> address range extension 0/0 only if router is not part of a domain >> with certified delegation from IANA? Otherwise, the address range >> extension MUST NOT have value 0/0. I'd prefer a SHOULD NOT. I do see valid operational reasons for 0/0. If a site does have a certified delegation from IANA, that delegation basically limits the address range. Quoting the draft: > If an addressPrefix or addressRange is not contained within the > delegating authority's prefixes or ranges, the client MAY attempt to > take an intersection of the ranges/prefixes, and use that > intersection. If the addressPrefix in the certificate is the null > prefix, 0/0, such an intersection SHOULD be used. (In that case the > intersection is the parent prefix or range.) In other words, a 0/0 certificate with a parent certificate basically means that the address range from the parent certificate is used. I admit that the text may be confusing and hard to read for anyone that haven't happened to read anything about the tag intersections in SPKI (on which the text is based), and probably should be reworded. Unfortunately I don't have cycles right now to suggest rewording. >> This means that the router is >> advertising a default route (which would typically be ok for a >> border router) but it will not propagate outside the domain. > > Sorry, I meant "would be ok for an access router" not a border router. > An > access router typically provides default routes for nodes on its > subnet. I didn't understand this part. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 21 03:39:44 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12221 for ; Wed, 21 Jan 2004 03:39:43 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0L8atqY001330; Wed, 21 Jan 2004 09:36:56 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR3J230T; Wed, 21 Jan 2004 09:39:46 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0L8amwg005396; Wed, 21 Jan 2004 09:36:50 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0L8YmIt024502; Wed, 21 Jan 2004 09:34:48 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0L8Yl9O024501; Wed, 21 Jan 2004 09:34:47 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep22-app.kolumbus.fi (fep22-0.kolumbus.fi [193.229.0.60]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0L8YjIt024497 for ; Wed, 21 Jan 2004 09:34:45 +0100 (MET) Received: from mta.imail.kolumbus.fi ([193.229.5.108]) by fep22-app.kolumbus.fi with ESMTP id <20040121083445.OEGQ3524.fep22-app.kolumbus.fi@mta.imail.kolumbus.fi> for ; Wed, 21 Jan 2004 10:34:45 +0200 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) From: To: Subject: Re: I-D ACTION:draft-ietf-send-ndopt-01.txt Date: Wed, 21 Jan 2004 10:34:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040121083445.OEGQ3524.fep22-app.kolumbus.fi@mta.imail.kolumbus.fi> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Note that this is the announcement for the previous version of the draft, submitted Dec 31st. The announcement for the -02 version should come at some point as well. --Jari --------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : SEcure Neighbor Discovery (SEND) Author(s) : J. Arkko Filename : draft-ietf-send-ndopt-01.txt Pages : 54 Date : 2004-1-20 -------------------------------------------------------------------- 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 Jan 21 07:22:59 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17716 for ; Wed, 21 Jan 2004 07:22:58 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0LCKiqY005386; Wed, 21 Jan 2004 13:20:44 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DKJGZ0DX; Wed, 21 Jan 2004 13:20:44 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0LCKhXA012192; Wed, 21 Jan 2004 13:20:43 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0LCIcIt026223; Wed, 21 Jan 2004 13:18:38 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0LCIcPu026222; Wed, 21 Jan 2004 13:18:38 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0LCIaIt026218 for ; Wed, 21 Jan 2004 13:18:37 +0100 (MET) Received: from localhost ([130.194.13.85]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L5OFAKIQTU934Q3M@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Wed, 21 Jan 2004 23:17:49 +1100 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 49974158003; Wed, 21 Jan 2004 23:17:47 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by broink.its.monash.edu.au (Postfix) with ESMTP id 363C8120002; Wed, 21 Jan 2004 23:17:47 +1100 (EST) Date: Wed, 21 Jan 2004 23:17:47 +1100 From: Gregory Daley Subject: Re: moving on with issue 47 (routing vs. advertisement rights) To: Pekka Nikander Cc: James Kempf , ietf-send@standards.ericsson.net, Mohan Parthasarathy , greg.daley@eng.monash.edu.au, Jari Arkko , pekkas@netcore.fi Message-id: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Pekka and James, ----- Original Message ----- From: Pekka Nikander Date: Wednesday, January 21, 2004 6:43 pm Subject: Re: moving on with issue 47 (routing vs. advertisement rights) > >>> I don't like this. I'm afraid that this would allow "wrong" type > >>> of certificates to be used for SEND. Maybe not a major security > >>> issue, but anyway something that should be avoided. > >>> > >>> Given that, I can live with the MAY you proposed provided that > >>> there is a cross reference to the security consideration > section at > >>> the spot and good explanation of the problem in the sec cons. > >>> > >>> But I still would prefer 0/0. My interpretation of the current > >>> text is that the semantics are clear, and I didn't quite > understand>>> how Greg found them confusing (sorry Greg). But I > haven't been > >>> able to follow too closely. > >> > >> Ok. > >> > >> What about if we say that a router MAY use a certificate with an > >> address range extension 0/0 only if router is not part of a domain > >> with certified delegation from IANA? Otherwise, the address range > >> extension MUST NOT have value 0/0. > > I'd prefer a SHOULD NOT. I do see valid operational reasons for 0/0. > > If a site does have a certified delegation from IANA, that delegation > basically limits the address range. Quoting the draft: > > > If an addressPrefix or addressRange is not contained within the > > delegating authority's prefixes or ranges, the client MAY > attempt to > > take an intersection of the ranges/prefixes, and use that > > intersection. If the addressPrefix in the certificate is the > null> prefix, 0/0, such an intersection SHOULD be used. (In > that case the > > intersection is the parent prefix or range.) > > In other words, a 0/0 certificate with a parent certificate basically > means that the address range from the parent certificate is used. > > I admit that the text may be confusing and hard to read for anyone > that haven't happened to read anything about the tag intersections > in SPKI (on which the text is based), and probably should be reworded. > > Unfortunately I don't have cycles right now to suggest rewording. Fair enough. I'll try to work out if there's _really_ an issue as opposed to if there may be an issue. > >> This means that the router is > >> advertising a default route (which would typically be ok for a > >> border router) but it will not propagate outside the domain. > > > > Sorry, I meant "would be ok for an access router" not a border > router. > > An > > access router typically provides default routes for nodes on its > > subnet. > > I didn't understand this part. I'll get back to you with a problem breakdown, which should clear up the issue (or whether there is one). Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 21 12:07:16 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00126 for ; Wed, 21 Jan 2004 12:07:15 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0LH4FYG024172; Wed, 21 Jan 2004 18:04:15 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR3JMTCL; Wed, 21 Jan 2004 18:07:07 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0LH46wg001709; Wed, 21 Jan 2004 18:04:07 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0LH3IIt012792; Wed, 21 Jan 2004 18:03:18 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0LH3IAC012791; Wed, 21 Jan 2004 18:03:18 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0LH3FIt012787 for ; Wed, 21 Jan 2004 18:03:16 +0100 (MET) Message-ID: <007501c3e040$7284cb20$5b6015ac@dclkempt40> From: "James Kempf" To: "Gregory Daley" , "Pekka Nikander" Cc: , "Mohan Parthasarathy" , , "Jari Arkko" , References: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 21 Jan 2004 09:03:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Greg, Since you raised the issue about the wording in draft 02, it would be helpful if you could suggest some text to resolve it. We would like to send the draft to WG Last Call and to the review board as soon as possible, so it would be most helpful if you could post something to the list in the next couple days. I think we are otherwise in agreement on basic technical points. Thanx. jak ----- Original Message ----- From: "Gregory Daley" To: "Pekka Nikander" Cc: "James Kempf" ; ; "Mohan Parthasarathy" ; ; "Jari Arkko" ; Sent: Wednesday, January 21, 2004 4:17 AM Subject: Re: moving on with issue 47 (routing vs. advertisement rights) > Hi Pekka and James, > > ----- Original Message ----- > From: Pekka Nikander > Date: Wednesday, January 21, 2004 6:43 pm > Subject: Re: moving on with issue 47 (routing vs. advertisement rights) > > > >>> I don't like this. I'm afraid that this would allow "wrong" type > > >>> of certificates to be used for SEND. Maybe not a major security > > >>> issue, but anyway something that should be avoided. > > >>> > > >>> Given that, I can live with the MAY you proposed provided that > > >>> there is a cross reference to the security consideration > > section at > > >>> the spot and good explanation of the problem in the sec cons. > > >>> > > >>> But I still would prefer 0/0. My interpretation of the current > > >>> text is that the semantics are clear, and I didn't quite > > understand>>> how Greg found them confusing (sorry Greg). But I > > haven't been > > >>> able to follow too closely. > > >> > > >> Ok. > > >> > > >> What about if we say that a router MAY use a certificate with an > > >> address range extension 0/0 only if router is not part of a domain > > >> with certified delegation from IANA? Otherwise, the address range > > >> extension MUST NOT have value 0/0. > > > > I'd prefer a SHOULD NOT. I do see valid operational reasons for 0/0. > > > > If a site does have a certified delegation from IANA, that delegation > > basically limits the address range. Quoting the draft: > > > > > If an addressPrefix or addressRange is not contained within the > > > delegating authority's prefixes or ranges, the client MAY > > attempt to > > > take an intersection of the ranges/prefixes, and use that > > > intersection. If the addressPrefix in the certificate is the > > null> prefix, 0/0, such an intersection SHOULD be used. (In > > that case the > > > intersection is the parent prefix or range.) > > > > In other words, a 0/0 certificate with a parent certificate basically > > means that the address range from the parent certificate is used. > > > > I admit that the text may be confusing and hard to read for anyone > > that haven't happened to read anything about the tag intersections > > in SPKI (on which the text is based), and probably should be reworded. > > > > Unfortunately I don't have cycles right now to suggest rewording. > > Fair enough. > > I'll try to work out if there's _really_ an issue > as opposed to if there may be an issue. > > > >> This means that the router is > > >> advertising a default route (which would typically be ok for a > > >> border router) but it will not propagate outside the domain. > > > > > > Sorry, I meant "would be ok for an access router" not a border > > router. > > > An > > > access router typically provides default routes for nodes on its > > > subnet. > > > > I didn't understand this part. > > I'll get back to you with a problem breakdown, > which should clear up the issue (or whether there > is one). > > > Greg > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 21 19:40:09 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19568 for ; Wed, 21 Jan 2004 19:40:07 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0M0aqYG003841; Thu, 22 Jan 2004 01:36:53 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDHPSHF; Thu, 22 Jan 2004 01:36:52 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0M0apXA021100; Thu, 22 Jan 2004 01:36:51 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0M0ZnIt014916; Thu, 22 Jan 2004 01:35:49 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0M0Zn9a014915; Thu, 22 Jan 2004 01:35:49 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0M0ZkIt014910 for ; Thu, 22 Jan 2004 01:35:47 +0100 (MET) Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L5P453FCOM902W2P@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 22 Jan 2004 11:08:49 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id AA09B23C003; Thu, 22 Jan 2004 11:08:48 +1100 (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 8DA19164010; Thu, 22 Jan 2004 11:08:48 +1100 (EST) Date: Thu, 22 Jan 2004 11:08:48 +1100 From: Greg Daley Subject: Re: moving on with issue 47 (routing vs. advertisement rights) To: James Kempf Cc: Pekka Nikander , ietf-send@standards.ericsson.net, Mohan Parthasarathy , Jari Arkko , pekkas@netcore.fi Reply-to: greg.daley@eng.monash.edu.au Message-id: <400F1490.2000709@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: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> <007501c3e040$7284cb20$5b6015ac@dclkempt40> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > Hi Greg, > > Since you raised the issue about the wording in draft 02, it would be > helpful if you could suggest some text to resolve it. We would like to send > the draft to WG Last Call and to the review board as soon as possible, so it > would be most helpful if you could post something to the list in the next > couple days. > > I think we are otherwise in agreement on basic technical points. > > Thanx. > How about the following text? The above check SHOULD be done for all certificates in the chain. If any of the checks fail, the client MUST NOT accept the certificate. The client also needs to perform validation of advertised prefixes as discussed in Advertised Prefixes. + Care should be taken if the certificates used in SEND are + re-used to provide routing authorization in other circumstances + (for example with dynamic routing protocols). It is currently + unclear if the presence of a (0/0) addressPrefix element which is + not a subset of the CA's authorized prefixes would cause + verification or routing problems with other protocols. + Since it is possible that some PKC certificates used with SEND do not immediately contain the X.509 IP address extension element, an implementation MAY contain facilities that allow the prefix and range --- I'm not sure how s-bgp handles things for iBGP, and the papers seem to concentrate on path verification for eBGP... Greg. -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Wed Jan 21 20:05:03 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20149 for ; Wed, 21 Jan 2004 20:05:03 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0M12oAh005940; Thu, 22 Jan 2004 02:02:50 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDHPV99; Thu, 22 Jan 2004 02:02:49 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0M12iwg026611; Thu, 22 Jan 2004 02:02:44 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0M129It022134; Thu, 22 Jan 2004 02:02:09 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0M1284o022133; Thu, 22 Jan 2004 02:02:08 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0M126It022111 for ; Thu, 22 Jan 2004 02:02:07 +0100 (MET) Message-ID: <021901c3e083$5d90e3a0$5b6015ac@dclkempt40> From: "James Kempf" To: Cc: "Pekka Nikander" , , "Mohan Parthasarathy" , "Jari Arkko" , References: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> <007501c3e040$7284cb20$5b6015ac@dclkempt40> <400F1490.2000709@eng.monash.edu.au> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Wed, 21 Jan 2004 17:02:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > How about the following text? > > The above check SHOULD be done for all certificates in the chain. If any > of the checks fail, the client MUST NOT accept the certificate. The > client also needs to perform validation of advertised prefixes as > discussed in Advertised Prefixes. > > + Care should be taken if the certificates used in SEND are > + re-used to provide routing authorization in other circumstances > + (for example with dynamic routing protocols). It is currently > + unclear if the presence of a (0/0) addressPrefix element which is > + not a subset of the CA's authorized prefixes would cause > + verification or routing problems with other protocols. > + I'd suggest: Care should be taken if the certificates used in SEND are re-used to provide routing authorization in other circumstances (for example with routing gateway protocols), since it is currently unclear if the presense of a (0/0) addressPrefix element which is not a subset of the CA's authorized prefixes would cause verification or routing problems with other protocols. Consequently, it is recommended that SEND certificates containing a (0/0) prefix SHOULD only be used for SEND. > Since it is possible that some PKC certificates used with SEND do not > immediately contain the X.509 IP address extension element, an > implementation MAY contain facilities that allow the prefix and range > > I'm not sure how s-bgp handles things for iBGP, and the papers seem to > concentrate on path verification for eBGP... > OK. jak -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jan 22 00:39:37 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27083 for ; Thu, 22 Jan 2004 00:39:36 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0M5biAh024402; Thu, 22 Jan 2004 06:37:44 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DKJG0T24; Thu, 22 Jan 2004 06:37:43 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0M5bVwg005168; Thu, 22 Jan 2004 06:37:31 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0M5aeIt004074; Thu, 22 Jan 2004 06:36:40 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0M5aevP004073; Thu, 22 Jan 2004 06:36:40 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0M5acIt004068 for ; Thu, 22 Jan 2004 06:36:38 +0100 (MET) Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L5P9XRYIKG8X2FL6@vaxh.its.monash.edu.au> for ietf-send@standards.ericsson.net; Thu, 22 Jan 2004 13:55:30 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 74DAD39C004; Thu, 22 Jan 2004 13:55:29 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 401012DC012; Thu, 22 Jan 2004 13:55:29 +1100 (EST) Date: Thu, 22 Jan 2004 13:55:29 +1100 From: Greg Daley Subject: Re: moving on with issue 47 (routing vs. advertisement rights) To: James Kempf Cc: Pekka Nikander , ietf-send@standards.ericsson.net, Mohan Parthasarathy , Jari Arkko , pekkas@netcore.fi Reply-to: greg.daley@eng.monash.edu.au Message-id: <400F3BA1.8070509@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: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> <007501c3e040$7284cb20$5b6015ac@dclkempt40> <400F1490.2000709@eng.monash.edu.au> <021901c3e083$5d90e3a0$5b6015ac@dclkempt40> Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: >>How about the following text? >> >>The above check SHOULD be done for all certificates in the chain. If any >>of the checks fail, the client MUST NOT accept the certificate. The >>client also needs to perform validation of advertised prefixes as >>discussed in Advertised Prefixes. >> >>+ Care should be taken if the certificates used in SEND are >>+ re-used to provide routing authorization in other circumstances >>+ (for example with dynamic routing protocols). It is currently >>+ unclear if the presence of a (0/0) addressPrefix element which is >>+ not a subset of the CA's authorized prefixes would cause >>+ verification or routing problems with other protocols. >>+ > > > I'd suggest: > > Care should be taken if the certificates used in SEND are re-used > to provide routing authorization in other circumstances > (for example with routing gateway protocols), since it is > currently unclear if the presense of a (0/0) addressPrefix element > which is not a subset of the CA's authorized prefixes would > cause verification or routing problems with other protocols. > Consequently, it is recommended that SEND certificates > containing a (0/0) prefix SHOULD only be used for SEND. > That's better, thanks. Greg -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jan 22 02:52:22 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12525 for ; Thu, 22 Jan 2004 02:52:21 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0M7nOAh008713; Thu, 22 Jan 2004 08:49:25 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR3JQP92; Thu, 22 Jan 2004 08:52:18 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0M7nNXA023140; Thu, 22 Jan 2004 08:49:23 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0M7mSIt010438; Thu, 22 Jan 2004 08:48:28 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0M7mSGq010437; Thu, 22 Jan 2004 08:48:28 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0M7mRIt010418 for ; Thu, 22 Jan 2004 08:48:27 +0100 (MET) Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 979291C; Thu, 22 Jan 2004 10:01:18 +0200 (EET) In-Reply-To: <021901c3e083$5d90e3a0$5b6015ac@dclkempt40> References: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> <007501c3e040$7284cb20$5b6015ac@dclkempt40> <400F1490.2000709@eng.monash.edu.au> <021901c3e083$5d90e3a0$5b6015ac@dclkempt40> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <61282535-4CAF-11D8-85D4-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , "Mohan Parthasarathy" , , "Jari Arkko" , From: Pekka Nikander Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Thu, 22 Jan 2004 09:48:34 +0200 To: "James Kempf" X-Mailer: Apple Mail (2.609) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit On Jan 22, 2004, at 3:02, James Kempf wrote: > > I'd suggest: > > Care should be taken if the certificates used in SEND are re-used > to provide routing authorization in other circumstances > (for example with routing gateway protocols), since it is > currently unclear if the presense of a (0/0) addressPrefix element > which is not a subset of the CA's authorized prefixes would > cause verification or routing problems with other protocols. > Consequently, it is recommended that SEND certificates > containing a (0/0) prefix SHOULD only be used for SEND. Looks good. Minor textual modifications: Care should be taken if the certificates used in SEND are re-used to provide routing authorization in other circumstances (for example with routing gateway protocols), since it is currently unclear if the presense of a (0/0) addressPrefix element, which is not a subset of the CA's authorized prefixes, would cause verification or routing problems with other protocols. Consequently, it is RECOMMENDED that SEND certificates containing a (0/0) prefix are only used for SEND. --Pekka -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Thu Jan 22 12:01:20 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29620 for ; Thu, 22 Jan 2004 12:01:13 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0MGwUqY022082; Thu, 22 Jan 2004 17:58:31 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJB4PK4Z; Thu, 22 Jan 2004 18:00:30 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0MGwTXA016629; Thu, 22 Jan 2004 17:58:29 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0MGuBIt006059; Thu, 22 Jan 2004 17:56:11 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0MGuBnu006058; Thu, 22 Jan 2004 17:56:11 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0MGu9It006022 for ; Thu, 22 Jan 2004 17:56:10 +0100 (MET) Message-ID: <005401c3e108$a9425330$5b6015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" Cc: , "Mohan Parthasarathy" , , "Jari Arkko" , References: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> <007501c3e040$7284cb20$5b6015ac@dclkempt40> <400F1490.2000709@eng.monash.edu.au> <021901c3e083$5d90e3a0$5b6015ac@dclkempt40> <61282535-4CAF-11D8-85D4-000393CE1E8C@nomadiclab.com> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Thu, 22 Jan 2004 08:56:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > > Care should be taken if the certificates used in SEND are re-used > > to provide routing authorization in other circumstances > > (for example with routing gateway protocols), since it is > > currently unclear if the presense of a (0/0) addressPrefix element > > which is not a subset of the CA's authorized prefixes would > > cause verification or routing problems with other protocols. > > Consequently, it is recommended that SEND certificates > > containing a (0/0) prefix SHOULD only be used for SEND. > > Looks good. > > Minor textual modifications: > > Care should be taken if the certificates used in SEND are re-used > to provide routing authorization in other circumstances > (for example with routing gateway protocols), since it is > currently unclear if the presense of a (0/0) addressPrefix element, > which is not a subset of the CA's authorized prefixes, would > cause verification or routing problems with other protocols. > Consequently, it is RECOMMENDED that SEND certificates > containing a (0/0) prefix are only used for SEND. > Well, according to RFC 2119 SHOULD and RECOMMENDED essentially mean the same thing as far as normative language goes: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. so I'm fine with that. If there are no other issues, then I'd suggest that Jari put this text into a 03 draft along with a few editorial changes we've been accumulating. We can start WG Last Call as soon as he's got the draft complete and available. 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 Fri Jan 23 02:48:12 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16855 for ; Fri, 23 Jan 2004 02:48:10 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0N7jXAh017732; Fri, 23 Jan 2004 08:45:33 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR3JZ9QR; Fri, 23 Jan 2004 08:48:29 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0N7jVXA027082; Fri, 23 Jan 2004 08:45:31 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0N7eYIt014454; Fri, 23 Jan 2004 08:40:34 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0N7eYBf014453; Fri, 23 Jan 2004 08:40:34 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0N7eXIt014449 for ; Fri, 23 Jan 2004 08:40:33 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep21-app.kolumbus.fi with ESMTP id <20040123074033.JUDM27281.fep21-app.kolumbus.fi@kolumbus.fi>; Fri, 23 Jan 2004 09:40:33 +0200 Message-ID: <4010CF9D.7000504@kolumbus.fi> Date: Fri, 23 Jan 2004 09:39:09 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-send@standards.ericsson.net CC: James Kempf , Pekka Nikander , Greg Daley Subject: Re: moving on with issue 47 (routing vs. advertisement rights) References: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> <007501c3e040$7284cb20$5b6015ac@dclkempt40> <400F1490.2000709@eng.monash.edu.au> <021901c3e083$5d90e3a0$5b6015ac@dclkempt40> <61282535-4CAF-11D8-85D4-000393CE1E8C@nomadiclab.com> <005401c3e108$a9425330$5b6015ac@dclkempt40> In-Reply-To: <005401c3e108$a9425330$5b6015ac@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 So the currently proposed resolution is to warn the reader about the use of 0/0 in certs that are used also by other applications than SEND. This appears right, but I wonder if it is the whole solution. Let me explain. We started this thread from the semantics of the certificate extensions, and what SEND protocol precisely does with a given prefix. Greg brought up the issue of what happens if 0/0 is included for SEND purposes and the same certificate is used in BGP, even if the router in question is not supposed to advertise a default route. The current text proposal fixes this issue, but I wonder if there's another, more general problem behind the 0/0 case. For SEND, it is required that the advertised prefixes are a subset of certified prefixes: Padv <= Pcert. The sets need not be equal, but any "slack" Pcert-Padv creates an opportunity for the routers to advertise prefixes that they are really not authorized to advertise. 0/0 is the extreme case of such slack. Similar rules apply to other applications such as secure BGP. However, there is no guarantee that the rules are exactly similar. For instance, I can imagine an application where certificates are used as the sole means of carrying prefix information; in that case the certificates would have to contain exactly the right information. Why are the requirements different in different applications? One reason is the protocol mechanisms, such as whether the certificates are or are not used as the sole means of conveying the given information. Another reason is that the security impacts are different. In SEND, a certificate that gives too many rights leads only to a local problem in the area of the ill behaving router. In BGP, one ill behaving router could potentially make the whole network route incorrectly. In any case, I think there is a potential problem in the different requirements that the applications set, even outside 0/0. Basically, if the same certificate is used for different applications, one needs to ensure that the prefix contents are appropriate for all of them. As an example, if my router has only IPv4 connectivity to the Internet and tunnels IPv6 over it, it might be that the BGP certificates should contain only IPv4 prefixes while the SEND certificates should contain the tunneled IPv6 prefixes. In conclusion, I would like to make the warning text a bit more general than just about 0/0. Here's the proposal: Care should be taken if the certificates used in SEND are re-used to provide authorization in other circumstances, for example with routing gateway protocols. It is necessary to ensure that the authorization information is appropriate for all applications. SEND certificates may authorize a larger set of prefixes than the router is really authorized to advertise on a given interface. For instance, SEND allows the use of the null prefix. This prefix might cause verification or routing problems in other applications. It is RECOMMENDED that SEND certificates containing the null prefix are only used for SEND. --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Fri Jan 23 02:56:48 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17655 for ; Fri, 23 Jan 2004 02:56:47 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0N7t2qY019249; Fri, 23 Jan 2004 08:55:02 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJB4TWPT; Fri, 23 Jan 2004 08:57:03 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0N7sQwg000488; Fri, 23 Jan 2004 08:54:35 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0N7oGIt017305; Fri, 23 Jan 2004 08:50:16 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0N7oG6L017304; Fri, 23 Jan 2004 08:50:16 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0N7oFIt017300 for ; Fri, 23 Jan 2004 08:50:15 +0100 (MET) Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 59F021C; Fri, 23 Jan 2004 10:03:06 +0200 (EET) In-Reply-To: <4010CF9D.7000504@kolumbus.fi> References: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> <007501c3e040$7284cb20$5b6015ac@dclkempt40> <400F1490.2000709@eng.monash.edu.au> <021901c3e083$5d90e3a0$5b6015ac@dclkempt40> <61282535-4CAF-11D8-85D4-000393CE1E8C@nomadiclab.com> <005401c3e108$a9425330$5b6015ac@dclkempt40> <4010CF9D.7000504@kolumbus.fi> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-send@standards.ericsson.net, James Kempf , Greg Daley From: Pekka Nikander Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Fri, 23 Jan 2004 09:50:21 +0200 To: Jari Arkko X-Mailer: Apple Mail (2.609) Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit > In conclusion, I would like to make the warning text a bit > more general than just about 0/0. > > Here's the proposal: > > Care should be taken if the certificates used in SEND are re-used > to provide authorization in other circumstances, for example > with routing gateway protocols. It is necessary to ensure that the > authorization information is appropriate for all applications. SEND > certificates may authorize a larger set of prefixes than the router > is really authorized to advertise on a given interface. For instance, > SEND allows the use of the null prefix. This prefix might cause > verification > or routing problems in other applications. It is RECOMMENDED that SEND > certificates containing the null prefix are only used for SEND. Ok to me. --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 Fri Jan 23 11:40:09 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10751 for ; Fri, 23 Jan 2004 11:40:08 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0NGb7Ah009057; Fri, 23 Jan 2004 17:37:08 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZD2A209; Fri, 23 Jan 2004 17:37:07 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0NGawwg029592; Fri, 23 Jan 2004 17:36:58 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0NGXVIt006705; Fri, 23 Jan 2004 17:33:31 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0NGXVai006704; Fri, 23 Jan 2004 17:33:31 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0NGXTIt006688 for ; Fri, 23 Jan 2004 17:33:29 +0100 (MET) Message-ID: <00db01c3e1ce$a6f78de0$5b6015ac@dclkempt40> From: "James Kempf" To: , Cc: "Pekka Nikander" , "Greg Daley" References: <9bc4a49c1058.9c10589bc4a4@mail1.monash.edu.au> <007501c3e040$7284cb20$5b6015ac@dclkempt40> <400F1490.2000709@eng.monash.edu.au> <021901c3e083$5d90e3a0$5b6015ac@dclkempt40> <61282535-4CAF-11D8-85D4-000393CE1E8C@nomadiclab.com> <005401c3e108$a9425330$5b6015ac@dclkempt40> <4010CF87.2020901@piuha.net> Subject: Re: moving on with issue 47 (routing vs. advertisement rights) Date: Fri, 23 Jan 2004 08:33:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Looks fine to me. Greg, what do you think? jak ----- Original Message ----- From: "Jari Arkko" To: Cc: "James Kempf" ; "Pekka Nikander" ; "Greg Daley" Sent: Thursday, January 22, 2004 11:38 PM Subject: Re: moving on with issue 47 (routing vs. advertisement rights) > > So the currently proposed resolution is to warn the reader > about the use of 0/0 in certs that are used also by other > applications than SEND. This appears right, but I wonder > if it is the whole solution. > > Let me explain. We started this thread from the semantics > of the certificate extensions, and what SEND protocol > precisely does with a given prefix. Greg brought up the > issue of what happens if 0/0 is included for SEND purposes > and the same certificate is used in BGP, even if the router > in question is not supposed to advertise a default route. > The current text proposal fixes this issue, but I wonder > if there's another, more general problem behind the 0/0 > case. > > For SEND, it is required that the advertised prefixes > are a subset of certified prefixes: Padv <= Pcert. The > sets need not be equal, but any "slack" Pcert-Padv creates > an opportunity for the routers to advertise prefixes > that they are really not authorized to advertise. 0/0 is > the extreme case of such slack. Similar rules apply to > other applications such as secure BGP. However, there > is no guarantee that the rules are exactly similar. For > instance, I can imagine an application where certificates > are used as the sole means of carrying prefix information; > in that case the certificates would have to contain exactly > the right information. > > Why are the requirements different in different applications? > One reason is the protocol mechanisms, such as whether > the certificates are or are not used as the sole means of > conveying the given information. Another reason is that > the security impacts are different. In SEND, a certificate > that gives too many rights leads only to a local problem in > the area of the ill behaving router. In BGP, one ill behaving > router could potentially make the whole network route incorrectly. > > In any case, I think there is a potential problem in the > different requirements that the applications set, even outside > 0/0. Basically, if the same certificate is used for different > applications, one needs to ensure that the prefix contents > are appropriate for all of them. As an example, if my router > has only IPv4 connectivity to the Internet and tunnels IPv6 over > it, it might be that the BGP certificates should contain only IPv4 > prefixes while the SEND certificates should contain the tunneled > IPv6 prefixes. > > In conclusion, I would like to make the warning text a bit > more general than just about 0/0. > > Here's the proposal: > > Care should be taken if the certificates used in SEND are re-used > to provide authorization in other circumstances, for example > with routing gateway protocols. It is necessary to ensure that the > authorization information is appropriate for all applications. SEND > certificates may authorize a larger set of prefixes than the router > is really authorized to advertise on a given interface. For instance, > SEND allows the use of the null prefix. This prefix might cause verification > or routing problems in other applications. It is RECOMMENDED that SEND > certificates containing the null prefix are only used for SEND. > > --Jari > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jan 24 09:20:32 2004 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09852 for ; Sat, 24 Jan 2004 09:20:31 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0OEH9qY018906; Sat, 24 Jan 2004 15:17:09 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DKJH4NF5; Sat, 24 Jan 2004 15:17:09 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0OEH8XA011455; Sat, 24 Jan 2004 15:17:08 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0OEEoIt003625; Sat, 24 Jan 2004 15:14:50 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0OEEos2003616; Sat, 24 Jan 2004 15:14:50 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0OEEmIt003612 for ; Sat, 24 Jan 2004 15:14:48 +0100 (MET) Received: from localhost ([130.194.13.81]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L5SLXNGJOI91WEBU@vaxc.its.monash.edu.au> for ietf-send@standards.ericsson.net; Sat, 24 Jan 2004 23:11:22 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id C11861B000C; Sat, 24 Jan 2004 23:11:21 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by kapow.its.monash.edu.au (Postfix) with ESMTP id A4996124004; Sat, 24 Jan 2004 23:11:21 +1100 (EST) Date: Sat, 24 Jan 2004 23:11:21 +1100 From: Gregory Daley Subject: Re: moving on with issue 47 (routing vs. advertisement rights) To: James Kempf Cc: jarkko@piuha.net, ietf-send@standards.ericsson.net, Pekka Nikander , Greg Daley Message-id: MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT Hi, Thanks Jari for getting to the deeper meat of the issue. The proposed text is sufficient. Greg. ----- Original Message ----- From: James Kempf Date: Saturday, January 24, 2004 3:33 am Subject: Re: moving on with issue 47 (routing vs. advertisement rights) > Looks fine to me. Greg, what do you think? > > jak > > ----- Original Message ----- > From: "Jari Arkko" > To: > Cc: "James Kempf" ; "Pekka Nikander" > ; "Greg Daley" > Sent: Thursday, January 22, 2004 > 11:38 PM > Subject: Re: moving on with issue 47 (routing vs. advertisement > rights) > > > > > So the currently proposed resolution is to warn the reader > > about the use of 0/0 in certs that are used also by other > > applications than SEND. This appears right, but I wonder > > if it is the whole solution. > > > > Let me explain. We started this thread from the semantics > > of the certificate extensions, and what SEND protocol > > precisely does with a given prefix. Greg brought up the > > issue of what happens if 0/0 is included for SEND purposes > > and the same certificate is used in BGP, even if the router > > in question is not supposed to advertise a default route. > > The current text proposal fixes this issue, but I wonder > > if there's another, more general problem behind the 0/0 > > case. > > > > For SEND, it is required that the advertised prefixes > > are a subset of certified prefixes: Padv <= Pcert. The > > sets need not be equal, but any "slack" Pcert-Padv creates > > an opportunity for the routers to advertise prefixes > > that they are really not authorized to advertise. 0/0 is > > the extreme case of such slack. Similar rules apply to > > other applications such as secure BGP. However, there > > is no guarantee that the rules are exactly similar. For > > instance, I can imagine an application where certificates > > are used as the sole means of carrying prefix information; > > in that case the certificates would have to contain exactly > > the right information. > > > > Why are the requirements different in different applications? > > One reason is the protocol mechanisms, such as whether > > the certificates are or are not used as the sole means of > > conveying the given information. Another reason is that > > the security impacts are different. In SEND, a certificate > > that gives too many rights leads only to a local problem in > > the area of the ill behaving router. In BGP, one ill behaving > > router could potentially make the whole network route incorrectly. > > > > In any case, I think there is a potential problem in the > > different requirements that the applications set, even outside > > 0/0. Basically, if the same certificate is used for different > > applications, one needs to ensure that the prefix contents > > are appropriate for all of them. As an example, if my router > > has only IPv4 connectivity to the Internet and tunnels IPv6 over > > it, it might be that the BGP certificates should contain only IPv4 > > prefixes while the SEND certificates should contain the tunneled > > IPv6 prefixes. > > > > In conclusion, I would like to make the warning text a bit > > more general than just about 0/0. > > > > Here's the proposal: > > > > Care should be taken if the certificates used in SEND are re-used > > to provide authorization in other circumstances, for example > > with routing gateway protocols. It is necessary to ensure that the > > authorization information is appropriate for all applications. SEND > > certificates may authorize a larger set of prefixes than the router > > is really authorized to advertise on a given interface. For > instance,> SEND allows the use of the null prefix. This prefix > might cause > verification > > or routing problems in other applications. It is RECOMMENDED that > SEND> certificates containing the null prefix are only used for SEND. > > > > --Jari > > > > > > -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sat Jan 24 14:13:24 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18731 for ; Sat, 24 Jan 2004 14:13:24 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0OJBCYG009461; Sat, 24 Jan 2004 20:11:13 +0100 (MET) Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DKJHVWPY; Sat, 24 Jan 2004 20:11:12 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0OJBCXA012627; Sat, 24 Jan 2004 20:11:12 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0OJ97It021169; Sat, 24 Jan 2004 20:09:07 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0OJ978o021166; Sat, 24 Jan 2004 20:09:07 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep22-app.kolumbus.fi (fep22-0.kolumbus.fi [193.229.0.60]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0OJ96It021161 for ; Sat, 24 Jan 2004 20:09:06 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep22-app.kolumbus.fi with ESMTP id <20040124190905.KJRE3524.fep22-app.kolumbus.fi@kolumbus.fi> for ; Sat, 24 Jan 2004 21:09:05 +0200 Message-ID: <4012C27C.1000602@kolumbus.fi> Date: Sat, 24 Jan 2004 21:07:40 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: draft 03 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 Draft -03 has been sent to the I-D directories. Before it is announced you can find it at: http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-03.txt http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-03.html http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-03diff.html http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-03cb.txt Note: the currently available official version is -01, submitted Dec 31, announced Jan 20. Version -02 has not been announced yet, so now we have two unannounced versions in the I-D queue ;-) --Jari -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html -------------------------------------------------------------------- From jari.arkko@lmf.ericsson.se Sun Jan 25 21:20:04 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00486 for ; Sun, 25 Jan 2004 21:20:03 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0Q2GvAh004071; Mon, 26 Jan 2004 03:16:57 +0100 Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DKJH8LDA; Mon, 26 Jan 2004 03:16:57 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0Q2Gkwg007651; Mon, 26 Jan 2004 03:16:47 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0Q2EEIt021697; Mon, 26 Jan 2004 03:14:14 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0Q2EEkY021696; Mon, 26 Jan 2004 03:14:14 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0Q2ECIt021692 for ; Mon, 26 Jan 2004 03:14:12 +0100 (MET) Message-ID: <00f101c3e3b2$26ed0fe0$606015ac@dclkempt40> From: "James Kempf" To: "SEND WG" References: <4012C27C.1000602@kolumbus.fi> Subject: Announcing WG Last Call for draft-ietf-send-ndopt Date: Sun, 25 Jan 2004 18:14:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit Folks, This is an announcement of Last Call for draft-ietf-send-ndopt-03.txt. We've been having a problem with the ID editor being somewhat behind in their posting for drafts, so Jari has posted the draft and diffs at the following URLs: http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-03.txt http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-03.html http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-03diff.html http://www.arkko.com/publications/send/drafts/draft-ietf-send-ndopt-03cb.txt WG Last Call starts today and runs until Feb. 8. Provided Jari can manage any edits coming out of the Last Call, we will try to submit the draft prior to the Feb. 16 deadline, even though we will not be meeting in Seoul. This will give the IESG the opportunity to consider the draft there, if they have time. 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 Jan 28 16:11:04 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29182 for ; Wed, 28 Jan 2004 16:11:03 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0SL8RYG019650; Wed, 28 Jan 2004 22:08:27 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DZZ06MLQ; Wed, 28 Jan 2004 22:08:26 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0SL8Iwg013873; Wed, 28 Jan 2004 22:08:21 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0SL5tIt000156; Wed, 28 Jan 2004 22:05:55 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0SL5tup000155; Wed, 28 Jan 2004 22:05:55 +0100 (MET) 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.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0SL5sIt000150 for ; Wed, 28 Jan 2004 22:05:54 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep06-app.kolumbus.fi with ESMTP id <20040128210554.OZRY18555.fep06-app.kolumbus.fi@kolumbus.fi> for ; Wed, 28 Jan 2004 23:05:54 +0200 Message-ID: <401823D8.4030401@kolumbus.fi> Date: Wed, 28 Jan 2004 23:04:24 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: FW: I-D ACTION:draft-ietf-send-ndopt-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7bit The draft announcement for -02 version has come out. Note that -03 has been submitted and is still in the queue... (temporary pointers for the -03 have been posted previously on this list). ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : SEcure Neighbor Discovery (SEND) Author(s) : J. Arkko Filename : draft-ietf-send-ndopt-02.txt Pages : 54 Date : 2004-1-27 IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine each the link-layer addresses of the nodes on the link, to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike to the original NDP specifications, these mechanisms do not make use of IPsec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-send-ndopt-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -------------------------------------------------------------------- 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 Jan 28 20:22:29 2004 Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10576 for ; Wed, 28 Jan 2004 20:22:28 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0T1JuAh011946; Thu, 29 Jan 2004 02:19:56 +0100 Received: from tjatte.sw.ericsson.se ([153.88.242.9]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DZZ5YNZT; Thu, 29 Jan 2004 02:19:55 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by tjatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0T1JtXA011020; Thu, 29 Jan 2004 02:19:55 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0T1HiIt009670; Thu, 29 Jan 2004 02:17:44 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0T1Hi6q009669; Thu, 29 Jan 2004 02:17:44 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0T1HgIt009665 for ; Thu, 29 Jan 2004 02:17:43 +0100 (MET) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HS800G2D8X1YD@mailout2.samsung.com> for ietf-send@standards.ericsson.net; Thu, 29 Jan 2004 10:17:25 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HS8009IA8WBWV@mailout2.samsung.com> for ietf-send@standards.ericsson.net; Thu, 29 Jan 2004 10:16:59 +0900 (KST) Received: from LocalHost ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HS800M6N8WB9S@mmp2.samsung.com> for ietf-send@standards.ericsson.net; Thu, 29 Jan 2004 10:16:59 +0900 (KST) Date: Thu, 29 Jan 2004 10:16:50 +0900 From: "S. Daniel Park" Subject: RE: I-D ACTION:draft-ietf-send-ndopt-02.txt In-reply-to: <401823D8.4030401@kolumbus.fi> To: "'Jari Arkko'" , "'SEND WG'" Message-id: <000001c3e605$92c2a2c0$b7cbdba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk Content-Transfer-Encoding: 7BIT > The draft announcement for -02 version has come out. Note > that -03 has been submitted and is still in the queue... > (temporary pointers for the -03 have been posted previously > on this list). http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-02.txt 03 is not temporary at this time... After replaced 02 by 03, above linked draft was opened... Daniel -------------------------------------------------------------------- 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 Jan 29 14:28:51 2004 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10533 for ; Thu, 29 Jan 2004 14:28:51 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0TJOQYG001882; Thu, 29 Jan 2004 20:24:27 +0100 (MET) Received: from fnatte.sw.ericsson.se ([153.88.242.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D7J4LWTR; Thu, 29 Jan 2004 20:24:26 +0100 Received: from sw.ericsson.se (prdxweb.sw.ericsson.se [153.88.240.43]) by fnatte.sw.ericsson.se (8.12.10/8.12.10) with ESMTP id i0TJOAwg023305; Thu, 29 Jan 2004 20:24:10 +0100 (MET) Received: from prdxweb.sw.ericsson.se (localhost [127.0.0.1]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0TJKlIt000928; Thu, 29 Jan 2004 20:20:47 +0100 (MET) Received: (from ietfmdomo@localhost) by prdxweb.sw.ericsson.se (8.12.10/8.12.10/Submit) id i0TJKkZ2000925; Thu, 29 Jan 2004 20:20:46 +0100 (MET) X-Authentication-Warning: prdxweb.sw.ericsson.se: ietfmdomo set sender to owner-ietf-send@standards.ericsson.net using -f Received: from fep20-app.kolumbus.fi (fep20-0.kolumbus.fi [193.229.0.47]) by sw.ericsson.se (8.12.10/8.12.10/unixcenter-xnetx-1.0) with ESMTP id i0TJKkIt000911 for ; Thu, 29 Jan 2004 20:20:46 +0100 (MET) Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040129192045.LWQI15980.fep20-app.kolumbus.fi@kolumbus.fi> for ; Thu, 29 Jan 2004 21:20:45 +0200 Message-ID: <40195CB4.6030708@kolumbus.fi> Date: Thu, 29 Jan 2004 21:19:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SEND WG Subject: [Fwd: I-D ACTION:draft-ietf-send-ndopt-03.txt] Content-Type: multipart/mixed; boundary="------------000301050204050705050206" Sender: owner-ietf-send@standards.ericsson.net Precedence: bulk This is a multi-part message in MIME format. --------------000301050204050705050206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is the final and correct notice. And as was already noted on the list, the directories have already had the -03. --Jari --------------000301050204050705050206 Content-Type: message/rfc822; name="I-D ACTION:draft-ietf-send-ndopt-03.txt" Content-Disposition: inline; filename="I-D ACTION:draft-ietf-send-ndopt-03.txt" X-Sieve: cmu-sieve 2.0 Return-Path: X-Original-To: jari.arkko@piuha.net Delivered-To: jarkko@piuha.net Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by p2.piuha.net (Postfix) with ESMTP id F36236A903; Thu, 29 Jan 2004 18:07:52 +0200 (EET) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AmE2h-0004WG-RV for ietf-announce-list@asgard.ietf.org; Thu, 29 Jan 2004 10:25:19 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AmDzm-0004Cn-0V for all-ietf@asgard.ietf.org; Thu, 29 Jan 2004 10:22:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23793; Thu, 29 Jan 2004 10:22:07 -0500 (EST) Message-Id: <200401291522.KAA23793@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-send@standards.ericsson.net From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-send-ndopt-03.txt Date: Thu, 29 Jan 2004 10:22:07 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on p2.piuha.net X-Spam-Status: No, hits=-4.2 required=6.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Level: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : SEcure Neighbor Discovery (SEND) Author(s) : J. Arkko Filename : draft-ietf-send-ndopt-03.txt Pages : 56 Date : 2004-1-28 IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine each the link-layer addresses of the nodes on the link, to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike to the original NDP specifications, these mechanisms do not make use of IPsec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-send-ndopt-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-send-ndopt-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-29104415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-send-ndopt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-send-ndopt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-29104415.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------000301050204050705050206-- -------------------------------------------------------------------- To unsubscribe from this list, send email with "UNSUBSCRIBE" in the body to . Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html --------------------------------------------------------------------