From jari.arkko at piuha.net Thu Nov 1 01:58:57 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Wed, 31 Oct 2007 19:58:57 +0200 Subject: [SAVA] FW: SAVI - Requested session has been scheduled for IETF 70 In-Reply-To: References: Message-ID: <4728C261.7000203@piuha.net> Preliminary scheduling information. Subject to change; the scheduling problem and conflicts are very hard. > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > SAVI Session 1 (1 hour) > Thursday, Afternoon Session II 1510-1610 > Room Name: Salon 3 > ---------------------------------------------- > > From fred at cisco.com Tue Nov 6 22:28:11 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Nov 2007 06:28:11 -0800 Subject: [SAVA] Review request In-Reply-To: <471CC489.4000606@piuha.net> References: <471CC489.4000606@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am about to post this, and wonder if it gives anyone any heartburn ftp://ftpeng.cisco.com/fred/sava/local-sava.html -----BEGIN PGP SIGNATURE----- iD8DBQFHMHn7bjEdbHIsm0MRAnetAJ9dhclA4yHX3N0Z4qMklNGwR4LFVQCgqh8Z oG+Yq+JDqpjsclWlzxxJso0= =+8PJ -----END PGP SIGNATURE----- From fred at cisco.com Tue Nov 6 22:35:15 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Nov 2007 06:35:15 -0800 Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One specific thought I have had regards ingress filtering via uRPF. That has been a pain to get right, and would be worth specifying. That said, I think it can actually be said in a few sentences, something along the lines of: A router MAY be configured to discard traffic that routing believes is coming from an inappropriate direction. This does not depend on the router's choice of routes, however; it depends on the routing calculated by a router's neighbors. As such, if router A validly advertises to router B that it can route traffic to a prefix, the router B SHOULD accept traffic from that prefix from router A. The determination of when a routing advertisement is valid is beyond the scope of this specification. I think that if I add that to this note, I should also include some overview of defense in depth, the notion that there is value in a layered defense. Comments? -----BEGIN PGP SIGNATURE----- iD8DBQFHMHujbjEdbHIsm0MRAgi7AJ96zy3xh2lL9mnuKaot2PBzZRvPuwCgykDJ AlSjBILKXWaR/n1hisVdo/w= =C880 -----END PGP SIGNATURE----- From pekkas at netcore.fi Tue Nov 6 22:47:09 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 6 Nov 2007 16:47:09 +0200 (EET) Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: On Tue, 6 Nov 2007, Fred Baker wrote: > A router MAY be configured to discard traffic that routing believes > is coming from an inappropriate direction. This does not depend on > the router's choice of routes, however; it depends on the routing > calculated by a router's neighbors. As such, if router A validly > advertises to router B that it can route traffic to a prefix, the > router B SHOULD accept traffic from that prefix from router A. The > determination of when a routing advertisement is valid is beyond the > scope of this specification. Does that work with more specific routes? For example scenarios in 3.2 and 3.3 of: http://tools.ietf.org/id/draft-savola-bcp84-urpf-experiences-02.txt -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From junbi at cernet.edu.cn Tue Nov 6 23:57:01 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Tue, 6 Nov 2007 23:57:01 +0800 Subject: [SAVA] Review request References: <471CC489.4000606@piuha.net> Message-ID: <002601c8208d$aca919a0$6401a8c0@IBMC9236A69C07> In section 2, "The switch, however, may be able to associate the IPv6 address with a switch port if it knows that only one host is attached to the port." I think, if more than one host is attached to the port, the switch may be able to associate the "IPv6 address/MAC" couple with a switch port. thanks, Jun Bi ----- Original Message ----- From: "Fred Baker" To: "SAVA Mailing List" Sent: Tuesday, November 06, 2007 10:28 PM Subject: [SAVA] Review request > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I am about to post this, and wonder if it gives anyone any heartburn > > ftp://ftpeng.cisco.com/fred/sava/local-sava.html > > -----BEGIN PGP SIGNATURE----- > > iD8DBQFHMHn7bjEdbHIsm0MRAnetAJ9dhclA4yHX3N0Z4qMklNGwR4LFVQCgqh8Z > oG+Yq+JDqpjsclWlzxxJso0= > =+8PJ > -----END PGP SIGNATURE----- > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > From fred at cisco.com Wed Nov 7 00:43:28 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Nov 2007 08:43:28 -0800 Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 6, 2007, at 6:47 AM, Pekka Savola wrote: > On Tue, 6 Nov 2007, Fred Baker wrote: >> A router MAY be configured to discard traffic that routing believes >> is coming from an inappropriate direction. This does not depend on >> the router's choice of routes, however; it depends on the routing >> calculated by a router's neighbors. As such, if router A validly >> advertises to router B that it can route traffic to a prefix, the >> router B SHOULD accept traffic from that prefix from router A. The >> determination of when a routing advertisement is valid is beyond the >> scope of this specification. > > Does that work with more specific routes? > > For example scenarios in 3.2 and 3.3 of: > http://tools.ietf.org/id/draft-savola-bcp84-urpf-experiences-02.txt Section 3.2 suggests that the address on a p2p interface might not be recognized correctly. It seems to me that if the PE router wants to ping the CPE router, for example, it will have to have a route that puts the datagram in that direction. You suggest a more specific route (in this case a host route) for uRPF purposes; it seems to me that it needs to either have that or have the address in the customer's address block in the first place t even use it. What is the case in which a PE can ping a CPE directly across the link but the uRPF doesn't work? 3.3 reads: When multiple routers attach to the same network subnet (typically when e.g., VRRP is used), packets destined to router 2 (R2)'s interface addresses towards the LAN transiting router 1 use the LAN interface to reach R2. (In most cases, the primary path between routers should go via dedicated link(s), not via a LAN.) These packets fail uRPF check at R2 (and vice versa at R1). There isn't a picture, so I'm interpolating from the text. In fact, I'm not sure I understand the case. I assume the picture is: Upstream / / / / / / +------+-+ +-+------+ |Router 1| |Router 2| +-+----+-+ +-+------+ | | | -----------+- -+-----+------. 192.0.2.16/28 192.0.2.32/28 R1 and R2 multiplex the "router address" on 192.0.2.32/28 using VRRP. I think you are saying that datagrams from 192.0.2.16/28 transit 192.0.2.32/28 and go upstream via Router 2, and Router 2 doesn't recognize the route. If this is the right picture, I think there is a routing bug there. First, how does R2 ping a host in 192.0.2.16/28 or give any data to it? It must have a route to it, and the only available route is via R1. If it doesn't, routing has a bug, and if it does, uRPF works. Second, if R1 is a hot standby for R2, why is it not sending datagrams headed upstream directly upstream? But the text seems to say that there are more than two routers in the mix. So maybe you're talking about something more like Upstream / / / / / / +------+-+ +-+------+ |Transit | |Transit | |Router 1| |Router 2| +---+----+ +----+---+ |192.0.2.32/28| ------+-------------+------ | | +----+-----+ +-----+----+ |Downstream| |Downstream| |Router 1 | |Router 2 | +----+-----+ +-----+----+ | | -----+------ ------+----- 192.0.2.16/28 192.0.2.48/28 In that case, I'm not at all sure I can track what problem you are seeing. How do datagrams from 192.0.2.16/28 get to Downstream Router 2 on their way out the door? Why would that router not be able to ping a system on 192.0.2.16/28? -----BEGIN PGP SIGNATURE----- iD8DBQFHMJmwbjEdbHIsm0MRAqJ8AKCc6WhhDIJIZOb6BZBtsXgNstIR4gCeKfaO Gwfh9o52fnrsti27q3FqnGg= =gKmK -----END PGP SIGNATURE----- From fred at cisco.com Wed Nov 7 01:30:35 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Nov 2007 09:30:35 -0800 Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Following up on my previous notes, you can take a look at ftp://ftpeng.cisco.com/fred/sava/local-sava.html ftp://ftpeng.cisco.com/fred/sava/sava.html The latter makes statements about ingress filtering using uRPF etc as well as the local concepts in the first one. I have three questions. First and second, do you think that these are respectively adequate for a first cut? Note that this does not imply "final product". Third, which would you like to see posted at the Internet Drafts directory? -----BEGIN PGP SIGNATURE----- iD8DBQFHMKS8bjEdbHIsm0MRAieEAJ9a1NFiMknnzyArd0JMRXoTx0cYZACfdBpo 9syv2MDwFTnTjsZgwxGSylc= =lnJz -----END PGP SIGNATURE----- From pekkas at netcore.fi Wed Nov 7 03:42:33 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 6 Nov 2007 21:42:33 +0200 (EET) Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: On Tue, 6 Nov 2007, Fred Baker wrote: > Section 3.2 suggests that the address on a p2p interface might not be > recognized correctly. > > It seems to me that if the PE router wants to ping the CPE router, for > example, it will have to have a route that puts the datagram in that > direction. You suggest a more specific route (in this case a host route) for > uRPF purposes; it seems to me that it needs to either have that or have the > address in the customer's address block in the first place t even use it. > > What is the case in which a PE can ping a CPE directly across the link but > the uRPF doesn't work? I guess my draft could use a couple of diagrams... :-) I think our scenarios are a bit different. Let me try to spell mine out. Let's take a scenario where the customer has 1.1.0.0/16 and point-to-point links have addresses 1.1.1.252/30 (ISP's router A) and 1.1.1.248/30 (ISP's router B). Assume the customer is multi-connecting to the ISP, i.e., both links attach to the same ISP but to different routers (A & B). Further assume that routers redistribute these connected routes in some manner to IGP or iBGP. (I believe all of these are sensible assumptions but slightly different conditions apply if you vary these assumptions.) Now, when Router A receives a packet with a source address inside 1.1.1.248/30 from the customer link, what will it do? The "correct" direction the packet should have come from is the link towards Router B, not from the customer, even though the packet's source address is in the customer's superblock. As a workaround, you may have need to install another 1.1.1.248/30 route on router A which points to the customer link in order to accept such packets. As a result, specifying "route for a prefix" or such may result in unintended consequences (i.e. you have to apply tricks like above to make it work) when you consider the implications of longest-prefix-match. On the other hand, it's no worse than the current situation... > 3.3 reads: > > When multiple routers attach to the same network subnet (typically > when e.g., VRRP is used), packets destined to router 2 (R2)'s > interface addresses towards the LAN transiting router 1 use the LAN > interface to reach R2. (In most cases, the primary path between > routers should go via dedicated link(s), not via a LAN.) These > packets fail uRPF check at R2 (and vice versa at R1). > > There isn't a picture, so I'm interpolating from the text. In fact, I'm not > sure I understand the case. I assume the picture is: > > Upstream > / / > / / > / / > +------+-+ +-+------+ > | Router 1| |Router 2| > +-+----+-+ +-+------+ > | | | > -----------+- -+-----+------. > 192.0.2.16/28 192.0.2.32/28 > > R1 and R2 multiplex the "router address" on 192.0.2.32/28 using VRRP. I think > you are saying that datagrams from 192.0.2.16/28 transit 192.0.2.32/28 and go > upstream via Router 2, and Router 2 doesn't recognize the route. > > If this is the right picture, I think there is a routing bug there. First, > how does R2 ping a host in 192.0.2.16/28 or give any data to it? It must have > a route to it, and the only available route is via R1. If it doesn't, routing > has a bug, and if it does, uRPF works. Second, if R1 is a hot standby for R2, > why is it not sending datagrams headed upstream directly upstream? No, if I understand your figures correctly, this is about something else: Upstream / / / / / / +------+-+ +-+------+ Cust A------|Router 1|---|Router 2| +-+----+-+ +--+-----+ | | -----------+-------------+---------- 192.0.2.0/24 Assume that R1's LAN address is 192.0.2.1 and R2's 192.0.2.2. When customer A pings router 2's loopback address, packets get forwarded through R1-R2 link. When customer A pings 192.0.2.2, router 1 forwards the packets to the LAN, and router 2 receives them through the LAN. However, from Router 2's perpective, it seems that someone in the LAN has spoofed Customer A's source addresses and uRPF drops the packets. One way to work around this is to set up static host route for 192.0.2.2/32 pointing at R1-R2 link at R1, and similarly for 192.0.2.1/32 at R2 -- but that again has similar implications as above that longest-prefix-match would reject packets from that IP if they arrived from the LAN. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From fred at cisco.com Wed Nov 7 05:14:24 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Nov 2007 13:14:24 -0800 Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: <9AC3EAF6-9B2E-48C4-B2D9-0626339043EB@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 6, 2007, at 11:42 AM, Pekka Savola wrote: > Let's take a scenario where the customer has 1.1.0.0/16 and point- > to-point links have addresses 1.1.1.252/30 (ISP's router A) and > 1.1.1.248/30 (ISP's router B). Assume the customer is multi- > connecting to the ISP, i.e., both links attach to the same ISP but > to different routers (A & B). Further assume that routers > redistribute these connected routes in some manner to IGP or iBGP. > (I believe all of these are sensible assumptions but slightly > different conditions apply if you vary these assumptions.) > > Now, when Router A receives a packet with a source address inside > 1.1.1.248/30 from the customer link, what will it do? The > "correct" direction the packet should have come from is the link > towards Router B, not from the customer, even though the packet's > source address is in the customer's superblock. As a workaround, > you may have need to install another 1.1.1.248/30 route on router A > which points to the customer link in order to accept such packets. > > As a result, specifying "route for a prefix" or such may result in > unintended consequences (i.e. you have to apply tricks like above > to make it work) when you consider the implications of longest- > prefix-match. On the other hand, it's no worse than the current > situation... OK. So you're saying that the router has multiple interfaces, and can respond from the address of one on the other. This is the reason I have the recommendation As noted in Section 1.2, caveats that make this difficult include any system that might send a datagram from an address unknown in the local environment. These include, but are not limited to, routers and any middleware that behaves like a router, in that it forwards datagrams originated by other systems using their source addresses, and multi-LAN hosts. To simplify source address validation, this specification declares that a host SHOULD send any datagram it originates on an interface the source address is associated with. Does that help? > No, if I understand your figures correctly, this is about something > else: > > Upstream > / / > / / > / / > +------+-+ +-+------+ > Cust A------|Router 1|---|Router 2| > +-+----+-+ +--+-----+ > | | > -----------+-------------+---------- > 192.0.2.0/24 > > Assume that R1's LAN address is 192.0.2.1 and R2's 192.0.2.2. > > When customer A pings router 2's loopback address, packets get > forwarded through R1-R2 link. that can happen iff R2 is advertising the address pinged to Router 1 but Router 1 is not advertising routing to R2. If R1 is advertising neither its loop-back address/prefix nor cust A to R2 on that interface, I wonder what the value of the interface is. -----BEGIN PGP SIGNATURE----- iD8DBQFHMNkxbjEdbHIsm0MRAnttAJ9sKWghWh6RDsgPy3DTeP9zFyAXIACgzAGd RU3hRPgx8XCGYEmuTkNy7w4= =//mQ -----END PGP SIGNATURE----- From pekkas at netcore.fi Wed Nov 7 14:46:27 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 7 Nov 2007 08:46:27 +0200 (EET) Subject: [SAVA] Review request In-Reply-To: <9AC3EAF6-9B2E-48C4-B2D9-0626339043EB@cisco.com> References: <471CC489.4000606@piuha.net> <9AC3EAF6-9B2E-48C4-B2D9-0626339043EB@cisco.com> Message-ID: On Tue, 6 Nov 2007, Fred Baker wrote: >> As a result, specifying "route for a prefix" or such may result in >> unintended consequences (i.e. you have to apply tricks like above to make >> it work) when you consider the implications of longest-prefix-match. On >> the other hand, it's no worse than the current situation... > > OK. So you're saying that the router has multiple interfaces, and can respond > from the address of one on the other. This is the reason I have the > recommendation > > As noted in Section 1.2, caveats that make this difficult include any > system that might send a datagram from an address unknown in the > local environment. These include, but are not limited to, routers > and any middleware that behaves like a router, in that it forwards > datagrams originated by other systems using their source addresses, > and multi-LAN hosts. To simplify source address validation, this > specification declares that a host SHOULD send any datagram it > originates on an interface the source address is associated with. > > Does that help? Yes that helps though it requires source-address based routing (i.e., ignorining typical routing policy). >> No, if I understand your figures correctly, this is about something else: >> >> Upstream >> / / >> / / >> / / >> +------+-+ +-+------+ >> Cust A------|Router 1|---|Router 2| >> +-+----+-+ +--+-----+ >> | | >> -----------+-------------+---------- >> 192.0.2.0/24 >> >> Assume that R1's LAN address is 192.0.2.1 and R2's 192.0.2.2. >> >> When customer A pings router 2's loopback address, packets get forwarded >> through R1-R2 link. > > that can happen iff R2 is advertising the address pinged to Router 1 but > Router 1 is not advertising routing to R2. If R1 is advertising neither its > loop-back address/prefix nor cust A to R2 on that interface, I wonder what > the value of the interface is. I'm not sure if I understand your point. The point-to-point link between R1 and R2 is configured in routing and is used in response packets when R2 would respond to ping (if an exclusion is made in uRPF checks). I think you're saying that in this scenario, the 192.0.2/0/24 LAN should be configured in routing as well so that it would be used for transit traffic between routers instead of the direct point-to-point link. That's exactly the opposite intent. The LAN is meant to connect hosts with VRRP service provided by two routers. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From bgreene at cisco.com Thu Nov 8 01:41:49 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Wed, 7 Nov 2007 09:41:49 -0800 Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > A router MAY be configured to discard traffic that routing > believes is coming from an inappropriate direction. This does > not depend on the router's choice of routes, however; it > depends on the routing calculated by a router's neighbors. As > such, if router A validly advertises to router B that it can > route traffic to a prefix, the router B SHOULD accept traffic > from that prefix from router A. The determination of when a > routing advertisement is valid is beyond the scope of this > specification. This sounds like uRPF VRF mode. The problem with it is the memory expense. You need to pull the table out to a separate VRF. If router A has connections to router B, C, and D, each router could send a different set of prefixes to router A - some of them duplicate. The only way to keep them separate - given the J and C do their forwarding tables. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRzH0Qr/UEA/xivvmEQIFQgCfUeziVTX9hgM1EvfBdfIoXFPxae0AoOad K+RaH4U3Jj7XuNGCobMfbF9F =IR6Y -----END PGP SIGNATURE----- From fred at cisco.com Thu Nov 8 08:44:39 2007 From: fred at cisco.com (Fred Baker) Date: Wed, 7 Nov 2007 16:44:39 -0800 Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> <9AC3EAF6-9B2E-48C4-B2D9-0626339043EB@cisco.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 6, 2007, at 10:46 PM, Pekka Savola wrote: > On Tue, 6 Nov 2007, Fred Baker wrote: >>> As a result, specifying "route for a prefix" or such may result >>> in unintended consequences (i.e. you have to apply tricks like >>> above to make it work) when you consider the implications of >>> longest-prefix-match. On the other hand, it's no worse than the >>> current situation... >> >> OK. So you're saying that the router has multiple interfaces, and >> can respond from the address of one on the other. This is the >> reason I have the recommendation >> >> As noted in Section 1.2, caveats that make this difficult >> include any >> system that might send a datagram from an address unknown in the >> local environment. These include, but are not limited to, routers >> and any middleware that behaves like a router, in that it forwards >> datagrams originated by other systems using their source addresses, >> and multi-LAN hosts. To simplify source address validation, this >> specification declares that a host SHOULD send any datagram it >> originates on an interface the source address is associated with. >> >> Does that help? > > Yes that helps though it requires source-address based routing > (i.e., ignorining typical routing policy). ...on a host. from my perspective, tere are two choices. One is what we do now: declare multi-lan hosts to be exempt from checking. The other is to ask them to pretty-please-with-sugar-on-top send their datagrams in a way that doesn't force us to exempt them. At this point, I'm not actually trying to have the discussion of "do we all agree with all of these recommendations". I hope we will agree to them. But at this point, I'm just trying to get them all down on the electronic counterpart of paper. :-) > >>> No, if I understand your figures correctly, this is about >>> something else: >>> >>> Upstream >>> / / >>> / / >>> / / >>> +------+-+ +-+------+ >>> Cust A------|Router 1|---|Router 2| >>> +-+----+-+ +--+-----+ >>> | | >>> -----------+-------------+---------- >>> 192.0.2.0/24 >>> Assume that R1's LAN address is 192.0.2.1 and R2's 192.0.2.2. >>> When customer A pings router 2's loopback address, packets get >>> forwarded through R1-R2 link. >> >> that can happen iff R2 is advertising the address pinged to Router >> 1 but Router 1 is not advertising routing to R2. If R1 is >> advertising neither its loop-back address/prefix nor cust A to R2 >> on that interface, I wonder what the value of the interface is. > > I'm not sure if I understand your point. The point-to-point link > between R1 and R2 is configured in routing and is used in response > packets when R2 would respond to ping (if an exclusion is made in > uRPF checks). I think you're saying that in this scenario, the > 192.0.2/0/24 LAN should be configured in routing as well so that it > would be used for transit traffic between routers instead of the > direct point-to-point link. That's exactly the opposite intent. > The LAN is meant to connect hosts with VRRP service provided by two > routers. my point is that I don't see why you have a direct r1-r2 link other than the LAN if R1 and R2 aren't going to exchange routes over it. If they do, I don't see how the problem you allude to happens - the route has been advertised and R2 should be able to see that even if it didn't choose the route the peer might send it datagrams from the route. If they don't, why have the link? -----BEGIN PGP SIGNATURE----- iD8DBQFHMlv3bjEdbHIsm0MRAnC5AJ9VPHr4n/FL6zKaRJHRhbUCBQfb/ACgtEQ4 pU47vITGDROkFQjHb+UZ1HE= =OFwT -----END PGP SIGNATURE----- From pekkas at netcore.fi Thu Nov 8 14:06:32 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 8 Nov 2007 08:06:32 +0200 (EET) Subject: [SAVA] Review request In-Reply-To: References: <471CC489.4000606@piuha.net> <9AC3EAF6-9B2E-48C4-B2D9-0626339043EB@cisco.com> Message-ID: On Wed, 7 Nov 2007, Fred Baker wrote: >> Yes that helps though it requires source-address based routing (i.e., >> ignorining typical routing policy). > > ...on a host. > > from my perspective, tere are two choices. One is what we do now: declare > multi-lan hosts to be exempt from checking. The other is to ask them to > pretty-please-with-sugar-on-top send their datagrams in a way that doesn't > force us to exempt them. Or a router acting as a host in this particular case, yes. There is, at least in theory, a third approach. It's not a full solution but could help in situations where you have more specific routes inside a superblock and you wish to ignore those more specifics. Specifically, being able to apply "bounded longest prefix matching" principle to uRPF check. >> I'm not sure if I understand your point. The point-to-point link between >> R1 and R2 is configured in routing and is used in response packets when R2 >> would respond to ping (if an exclusion is made in uRPF checks). I think >> you're saying that in this scenario, the 192.0.2/0/24 LAN should be >> configured in routing as well so that it would be used for transit traffic >> between routers instead of the direct point-to-point link. That's exactly >> the opposite intent. The LAN is meant to connect hosts with VRRP service >> provided by two routers. > > my point is that I don't see why you have a direct r1-r2 link other than the > LAN if R1 and R2 aren't going to exchange routes over it. If they do, I don't > see how the problem you allude to happens - the route has been advertised and > R2 should be able to see that even if it didn't choose the route the peer > might send it datagrams from the route. If they don't, why have the link? Please reread above. Routes are exchanged over R1-R2 link. There is no routing exchange over R1-LAN-R2 links. R1-R2 routing only exchanges the prefixes of attached interfaces (in this case, a /24). It does not additionally advertise the router's own addresses in those prefixes as /32 host routes. Because a directly connected /24 is always preferable to the same prefix learned from a routing protocol, R1 forwards packets destined to R2's 192.0.2.2 to the LAN, even when R2 advertises 192.0.2.0/24 to R1 through R1-R2 point to point link. And again, R2 drops such packets (because they use off-link source addresses from the LAN) because R1-LAN-R2 path does not participate in routing exchange. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From fred at cisco.com Fri Nov 9 01:14:14 2007 From: fred at cisco.com (Fred Baker) Date: Thu, 8 Nov 2007 09:14:14 -0800 Subject: [SAVA] Fwd: draft-baker-6man-multiprefix-default-route-00.txt is a new draft References: <200711081001.lA8A14C00375@ftpeng-update.cisco.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This might be interesting to know of in this context. We discussed it in Helsinki. Begin forwarded message: > From: fred at cisco.com > Date: November 8, 2007 2:01:04 AM PST > To: fred at cisco.com > Cc: ietf-interest at cisco.com > Subject: draft-baker-6man-multiprefix-default-route-00.txt is a new > draft > > You posted a new draft today. In the interest of informing your Cisco > colleagues, would you be so kind as to fill the rest of us in on your > project and what the draft is about? > > http://www.ietf.org/internet-drafts/draft-baker-6man-multiprefix- > default-route-00.txt > "Multiprefix IPv6 Routing for Ingress Filters", Fred Baker, 7- > Nov-07, > > > > The abstract you included reads: > > This note addresses routing in a network that supports multiple > prefixes and has different DMZs, in the context of BCPs 38 and 84 > (ingress filtering). It proposes a change to the way IPv6 forwarding > occurs, and so should be considered carefully by the Internet > community. > > There is more background at http://wwwin-people/fred/explanation.html > > By the way, if you're not on ietf-interest, you may find it an > interesting list to join. -----BEGIN PGP SIGNATURE----- iD8DBQFHM0PnbjEdbHIsm0MRAr3VAKD5Gqx65kbLWMNRWcUOppVcX9nVfACfcAjj mYTH78E8+Z+VlfbGJVyCq8E= =JCH4 -----END PGP SIGNATURE----- From fred at cisco.com Fri Nov 9 01:14:42 2007 From: fred at cisco.com (Fred Baker) Date: Thu, 8 Nov 2007 09:14:42 -0800 Subject: [SAVA] Fwd: draft-baker-sava-cisco-ip-source-guard-00.txt is a new draft References: <200711081001.lA8A14b00409@ftpeng-update.cisco.com> Message-ID: <6CAD4EB6-AD15-4C4E-B70C-A80E97B477FC@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This might be interesting to know of in this context. We discussed it in Helsinki. Begin forwarded message: > From: fred at cisco.com > Date: November 8, 2007 2:01:04 AM PST > To: fred at cisco.com > Cc: ietf-interest at cisco.com > Subject: draft-baker-sava-cisco-ip-source-guard-00.txt is a new draft > > You posted a new draft today. In the interest of informing your Cisco > colleagues, would you be so kind as to fill the rest of us in on your > project and what the draft is about? > > http://www.ietf.org/internet-drafts/draft-baker-sava-cisco-ip- > source-guard-00.txt > "Cisco IP Version 4 Source Guard", Fred Baker, 7-Nov-07, > > > > The abstract you included reads: > > As requested in the SAVA discussions, this document describes Cisco's > IP Source Guard feature. > > There is more background at http://wwwin-people/fred/explanation.html > > By the way, if you're not on ietf-interest, you may find it an > interesting list to join. -----BEGIN PGP SIGNATURE----- iD8DBQFHM0QCbjEdbHIsm0MRAi0HAKCXzyX8vXmsEKxqCOIotyNe7HoHDgCgozVq GGHNBh5XVUkYdoPWYVgSVxY= =8xyv -----END PGP SIGNATURE----- From fred at cisco.com Fri Nov 9 01:19:48 2007 From: fred at cisco.com (Fred Baker) Date: Thu, 8 Nov 2007 09:19:48 -0800 Subject: [SAVA] Fwd: New Version Notification for draft-baker-sava-implementation-00 References: Message-ID: <6965C546-BE87-4366-90B1-D96FC64D51E4@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The working group may be interested in this as well. Begin forwarded message: > From: IETF I-D Submission Tool > Date: November 8, 2007 9:18:19 AM PST > To: fred at cisco.com > Subject: New Version Notification for draft-baker-sava- > implementation-00 > > > A new version of I-D, draft-baker-sava-implementation-00.txt has > been successfuly submitted by Fred Baker and posted to the IETF > repository. > > Filename: draft-baker-sava-implementation > Revision: 00 > Title: Source address validation in the local environment > Creation_date: 2007-11-06 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > This note describes how Source Address Validation might be applied in > an IPv6 environment. Local systems should be able to ensure that > their peers are using the IPv6 source addresses that the routing > system uses to deliver data to them. Remote systems should be able > to ensure that traffic they forward has reasonable source addresses. > > > > The IETF Secretariat. -----BEGIN PGP SIGNATURE----- iD8DBQFHM0U0bjEdbHIsm0MRAmDwAJ9hBwFyywP6Aj40q5xj6+nfiYsVpACfY2bs tQsHorN53scC/oeH3M9pc1g= =AO9E -----END PGP SIGNATURE----- From iljitsch at muada.com Sun Nov 11 22:38:55 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 11 Nov 2007 15:38:55 +0100 Subject: [SAVA] Review request In-Reply-To: <002601c8208d$aca919a0$6401a8c0@IBMC9236A69C07> References: <471CC489.4000606@piuha.net> <002601c8208d$aca919a0$6401a8c0@IBMC9236A69C07> Message-ID: <9629DABA-12C7-44BF-95EC-AAF31F34DA40@muada.com> On 6 nov 2007, at 16:57, Jun Bi wrote: > In section 2, "The switch, however, may be able to associate the > IPv6 address with a switch port if it knows that only one host is > attached to the port." > I think, if more than one host is attached to the port, the switch > may be able to associate the "IPv6 address/MAC" couple with a switch > port. I haven't read the draft (and can't do so right now because my new ISP is apparently filtering new customer requests; life is quiet with no internet access at home) and I have only followed the discussion superficially, so I may say something stupid here... Because IPv6 hosts always have multiple addresses (at least a global one or SAVA is moot and of course a link local address) there can't be a one-to-one mapping between the IP address and the MAC address. I assume this complicates implementations. However, if we can have multiple IP addresses per MAC address, wouldn't it be trivial to enforce IP address <-> MAC address <-> port relationships so there are no limitations in the number of hosts behind a switch port other than a possible "one MAC address per port" constraint? From fred at cisco.com Mon Nov 12 07:43:37 2007 From: fred at cisco.com (Fred Baker) Date: Sun, 11 Nov 2007 15:43:37 -0800 Subject: [SAVA] Review request In-Reply-To: <9629DABA-12C7-44BF-95EC-AAF31F34DA40@muada.com> References: <471CC489.4000606@piuha.net> <002601c8208d$aca919a0$6401a8c0@IBMC9236A69C07> <9629DABA-12C7-44BF-95EC-AAF31F34DA40@muada.com> Message-ID: <8CDBE8B3-9E26-45D2-9728-9CEB0A84ACA4@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 11, 2007, at 6:38 AM, Iljitsch van Beijnum wrote: > Because IPv6 hosts always have multiple addresses (at least a > global one or SAVA is moot and of course a link local address) > there can't be a one-to-one mapping between the IP address and the > MAC address. I assume this complicates implementations. However, if > we can have multiple IP addresses per MAC address, wouldn't it be > trivial to enforce IP address <-> MAC address <-> port > relationships so there are no limitations in the number of hosts > behind a switch port other than a possible "one MAC address per > port" constraint? yes. what the draft suggests is that an IP address have one or more attributes, which depending on context might be a port number, a MAC address, or etc. In IPv4, one could imagine there being a 1:1 correspondence, and I think the Cisco implementation does that. But in IPv6, basically you want to find the IPv6 address in some table and ask if the other attributes also hold - address mumble arrived using port foo and MAC address bar. It occurs to me that we might have some cases where the same address is legitimately used on multiple interfaces; if so, we would have to address that case as well. A place for further reading. -----BEGIN PGP SIGNATURE----- iD8DBQFHN5OpbjEdbHIsm0MRAp/HAKDeZAI/v1u9ZLgFmNPComOE0lKppQCg5NAh wDkgmb7B223TfsCWVee+WtA= =QePh -----END PGP SIGNATURE----- From junbi at cernet.edu.cn Mon Nov 12 08:54:20 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Mon, 12 Nov 2007 08:54:20 +0800 Subject: [SAVA] Review request In-Reply-To: <9629DABA-12C7-44BF-95EC-AAF31F34DA40@muada.com> References: <471CC489.4000606@piuha.net> <002601c8208d$aca919a0$6401a8c0@IBMC9236A69C07> <9629DABA-12C7-44BF-95EC-AAF31F34DA40@muada.com> Message-ID: <30997329CC9049FA878D8F5983BADED0@userPC> In my opinion, if a host use another host's same ipv6 address and same MAC, then there will be address conflict problem, so the spoofer can not communicate properly. thanks, Jun ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Jun Bi" Cc: "Fred Baker" ; "SAVA Mailing List" Sent: Sunday, November 11, 2007 10:38 PM Subject: Re: [SAVA] Review request > On 6 nov 2007, at 16:57, Jun Bi wrote: > >> In section 2, "The switch, however, may be able to associate the IPv6 >> address with a switch port if it knows that only one host is attached to >> the port." > >> I think, if more than one host is attached to the port, the switch may >> be able to associate the "IPv6 address/MAC" couple with a switch port. > > > > I haven't read the draft (and can't do so right now because my new ISP is > apparently filtering new customer requests; life is quiet with no > internet access at home) and I have only followed the discussion > superficially, so I may say something stupid here... > > Because IPv6 hosts always have multiple addresses (at least a global one > or SAVA is moot and of course a link local address) there can't be a > one-to-one mapping between the IP address and the MAC address. I assume > this complicates implementations. However, if we can have multiple IP > addresses per MAC address, wouldn't it be trivial to enforce IP address > <-> MAC address <-> port relationships so there are no limitations in the > number of hosts behind a switch port other than a possible "one MAC > address per port" constraint? > > From fred at cisco.com Mon Nov 12 21:35:36 2007 From: fred at cisco.com (Fred Baker) Date: Mon, 12 Nov 2007 13:35:36 +0000 Subject: [SAVA] Review request In-Reply-To: <30997329CC9049FA878D8F5983BADED0@userPC> References: <471CC489.4000606@piuha.net> <002601c8208d$aca919a0$6401a8c0@IBMC9236A69C07> <9629DABA-12C7-44BF-95EC-AAF31F34DA40@muada.com> <30997329CC9049FA878D8F5983BADED0@userPC> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 12, 2007, at 12:54 AM, Jun Bi wrote: > In my opinion, if a host use another host's same ipv6 address and > same MAC, > then there will be address conflict problem, so the spoofer can not > communicate properly. That's not an opinion; it's a fact. That's why Cisco switches look at port number. I'm not sure how a layer 3 device would do that, though. -----BEGIN PGP SIGNATURE----- iD8DBQFHOFaobjEdbHIsm0MRAgs1AKDnfNF73sjkDfZclDvhk6qbnf32WgCfSvXp NV1qEfIe3MpVK5BUOeENjJM= =e4z0 -----END PGP SIGNATURE----- From christian.vogt at nomadiclab.com Sat Nov 24 03:05:44 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Fri, 23 Nov 2007 21:05:44 +0200 Subject: [SAVA] Review of draft-baker-sava-cisco-ip-source-guard-00 Message-ID: <47472488.5010909@nomadiclab.com> Fred, thanks for documenting Cisco's IPv4 Source Guard protocol. This will be a very useful reference for the work ahead in SAVI. Couple of comments: Section 2, 3rd paragraph: As described, the feature is clearly one implemented on an IP or Ethernet switch intended for use in a SOHO, corporate, or access network. It is not, at this writing, supported on Cisco routers, nor is it something one would expect to be implemented on a host. I think the last part of the latter sentence can be dropped because an implementation on a host would theoretically be feasible. Why not have a host implement the Source Guard and have it verify the source address in packets received directly from a neighbor? Interoperability is not a requirement per se; if the DHCP client and server are interoperable with each other, spoofing is adequately eliminated. Better just state that there are no interoperability issues because the Source Guard works with standard DHCP and no extensions are necessary. Section 2.1, 1st paragraph: In the IPv4 architecture, it is legal to have more than one IP address on a host, and there are systems (including routers and some hosts) that routinely send datagrams using a source IP address that differs from the interface's primary IP address. However, in the general case, a host has one address for each interface, and in the general case, a host has one interface. It is this case that the IP Source Guard feature addresses. By dropping all IPv4 datagrams from such hosts that use a different address than the one assigned, the feature severely limits a network's ability to introduce spoofed source addresses to the Internet. Why would hosts with multiple interfaces be a problem? Since the Source Guard sees only interfaces, it does not care if multiple interfaces belong to the same host. Additionally, why would hosts with multiple IP addresses per interface be problematic? One simply needs to bind a single link layer address to multiple IP addresses. Similar case with NATs, which are listed as a pitfall in the 3rd paragraph of section 2.2: They should work with the Source Guard if you set up multiple IP/link-layer address bindings for the same link-layer address. Section 2.1, 2nd paragraph: One could argue that this done not help the local network, but one would be wrong. An attack that happens elsewhere in the Internet can and does happen on the local LAN and in the IP network that a host resides in. Hence, while the degree may not be the same, eliminating address spoofing remains the first step in removing several classes of attacks from one's network, and is therefore a good idea. This paragraph is a bit confusing. I think we should identify two goals here: - Security benefits local to the network deploying the Source Guard, such as detection of infected hosts, reliability for administration and accounting, secure firewall/NAT bindings, etc. - If/when widely deployed, increased reliability of IP source addresses globally, not just locally within a network. Section 2.2, 1st paragraph: IP Source Guard assumes that some ports on a switch - those whose single interface has one address - are "protected" and others are not. "Others" include systems with multiple interfaces, which might as a result receive a datagram through one interface and respond to it ("from" the IP of that interface) on the other, for which this capability is obviously problematic. "Others" also includes routers, prefix-based NATs, and others, which may originate traffic from a variety of addresses that are not within the local prefix. IMO, a host that sends packets through one of its interfaces with a source address configured on another of its interfaces does misbehave. Hence it is OK to filter such packets. After all, the packets would also get filtered if the two interfaces happened to connect to different links, and ingress filtering was applied on access routers. Section 2.2, 2nd paragraph: The problem on a router interface should be obvious: a router forwards datagrams sent by other systems, which carry the source address of their originators. If this feature is applied to a router interface, the data it is forwarding will be discarded, nullifying its usefulness without advising either the network or its users of the fact - a clear violation of the End-to-End principle. Simply state that the Source Guard can verify the IP addresses of only non-forwarding hosts. As I said above for section 2.1, 1st paragraph, that sould work also for hosts with multiple IP addresses on an interface and for NATs. Section 2.2, 3rd paragraph: The problem on other varieties of devices - NATs that use multiple addresses, hosts that have "primary" and "secondary" addresses, and hosts with multiple LAN interfaces - is of the same nature. The system will be prevented from carrying out an intended function when using an address other than the one that the switch is enforcing the use of. See my comments above for section 2.1, 1st paragraph. Best, - Christian From christian.vogt at nomadiclab.com Sat Nov 24 03:07:09 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Fri, 23 Nov 2007 21:07:09 +0200 Subject: [SAVA] Review of draft-baker-sava-implementation-00 Message-ID: <474724DD.4050202@nomadiclab.com> Fred, thanks for writing this document. It is very good to have an overview of this IP source address verification solution. Still, to help a reader understand the feasibility, requirements, and implications of the solution, the document needs to be a bit more detailed and concise IMO. Below are suggestions on restructuring the document to this extent. It would be great if you could give the document a revision based on those, possibly even before the SAVI BoF in Vancouver. The structure below should also be helpful for a presentation of your solution at the BoF. (1) Begin with a brief summary of the main idea: - Address filter located on the path of to-be verified packets, capable of dropping packets - monitors address configuration signaling in order to build up a list of legitimate bindings between IP addresses and link layer addresses - can additionally be manually configured with static bindings - drops packets of which IP and link layer addresses do not match an entry in the list (2) Then start adding details: - Location of filter: Must be on same link as packet sender since original link layer addresses are otherwise not visible. Can be on a switch, on an access router, on a neighbor. - Means for address configuration we need to consider: DHCP, autonomous configuration - Link layer addresses to which IP addresses may be bound: Add your first list in section 2.1. - Reactive verification of address binding (double-checking): If no binding exists for a packet, double check addresses prior to dropping the packet, e.g., based on Neighbor Unreachability Detection. - Hard-state for manually configured bindings, soft-state otherwise. (3) A discussion of things to be worked out: - What happens if a filter misses part of the address configuration signaling before it boots up or appears on a link? (E.g., what about filters on mobile hosts?) - Packet caching or not during double-checking? - How long should refresh triggers and timeout values for soft-state bindings be? (4) Security considerations: - DoS threat: Legitimate host prevented by attacker from using its own IP address. This is already possible with NDP. - Flooding threat: Attacker floods packet cache in filter. Mitigation possible through limiting number of IP addresses per link layer address. Align soft-state timeouts with change interval for privacy addresses so that limit does not get reached. Best regards, - Christian From jari.arkko at piuha.net Sun Nov 25 00:48:56 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Sat, 24 Nov 2007 18:48:56 +0200 Subject: [SAVA] Chairs for the SAVI BOF Message-ID: <474855F8.8020908@piuha.net> Danny McPherson and Christian Vogt have kindly agreed to chair the BOF. Thanks! They are working on agenda which will be posted soon. Jari From fred at cisco.com Mon Nov 26 12:47:19 2007 From: fred at cisco.com (Fred Baker) Date: Sun, 25 Nov 2007 20:47:19 -0800 Subject: [SAVA] Review of draft-baker-sava-cisco-ip-source-guard-00 In-Reply-To: <47472488.5010909@nomadiclab.com> References: <47472488.5010909@nomadiclab.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 23, 2007, at 11:05 AM, Christian Vogt wrote: > Fred, > > thanks for documenting Cisco's IPv4 Source Guard protocol. This > will be > a very useful reference for the work ahead in SAVI. Couple of > comments: > > > Section 2, 3rd paragraph: > > As described, the feature is clearly one implemented on an IP or > Ethernet switch intended for use in a SOHO, corporate, or access > network. It is not, at this writing, supported on Cisco > routers, nor > is it something one would expect to be implemented on a host. > > I think the last part of the latter sentence can be dropped because an > implementation on a host would theoretically be feasible. Why not > have > a host implement the Source Guard and have it verify the source > address > in packets received directly from a neighbor? If you're asking about Cisco's implementation, which is specifically what was requested and what I documented, Cisco doesn't make hosts. > Interoperability is not a requirement per se; if the DHCP client > and > server are interoperable with each other, spoofing is adequately > eliminated. > > Better just state that there are no interoperability issues because > the > Source Guard works with standard DHCP and no extensions are necessary. > > > Section 2.1, 1st paragraph: > > In the IPv4 architecture, it is legal to have more than one IP > address on a host, and there are systems (including routers and > some > hosts) that routinely send datagrams using a source IP address that > differs from the interface's primary IP address. However, in the > general case, a host has one address for each interface, and in the > general case, a host has one interface. It is this case that > the IP > Source Guard feature addresses. By dropping all IPv4 datagrams > from > such hosts that use a different address than the one assigned, the > feature severely limits a network's ability to introduce spoofed > source addresses to the Internet. > > Why would hosts with multiple interfaces be a problem? Since the > Source Guard sees only interfaces, it does not care if multiple > interfaces belong to the same host. it does care about addresses uses by the host. If the host has multiple interfaces, it has multiple addresses, and there are cases where a host will use the address from one interface on a message transmitted on another (for example, if it is replying to q request and its route table specifies an interface to send the datagram on). If it is limiting the use of the interface to a single address, that will scotch such a message. > Additionally, why would hosts with multiple IP addresses per interface > be problematic? One simply needs to bind a single link layer > address to > multiple IP addresses. While that happens in IPv4, it is not common (it is fairly ancient BSD technology and no longer widely used), and the Cisco implementation very specifically limits the host to a single address on the interface, the one assigned using DHCP. > Similar case with NATs, which are listed as a pitfall in the 3rd > paragraph of section 2.2: They should work with the Source Guard > if you > set up multiple IP/link-layer address bindings for the same link-layer > address. They will if it is the type of NAT that overlays all traffic on one address. Not all NATs do that. > Section 2.1, 2nd paragraph: > > One could argue that this done not help the local network, but one > would be wrong. An attack that happens elsewhere in the > Internet can > and does happen on the local LAN and in the IP network that a host > resides in. Hence, while the degree may not be the same, > eliminating > address spoofing remains the first step in removing several classes > of attacks from one's network, and is therefore a good idea. > > This paragraph is a bit confusing. I think we should identify two > goals > here: > > - Security benefits local to the network deploying the Source Guard, > such as detection of infected hosts, reliability for administration > and accounting, secure firewall/NAT bindings, etc. > > - If/when widely deployed, increased reliability of IP source > addresses > globally, not just locally within a network. > > > Section 2.2, 1st paragraph: > > IP Source Guard assumes that some ports on a switch - those whose > single interface has one address - are "protected" and others are > not. "Others" include systems with multiple interfaces, which > might > as a result receive a datagram through one interface and respond to > it ("from" the IP of that interface) on the other, for which this > capability is obviously problematic. "Others" also includes > routers, > prefix-based NATs, and others, which may originate traffic from a > variety of addresses that are not within the local prefix. > > IMO, a host that sends packets through one of its interfaces with a > source address configured on another of its interfaces does misbehave. you're welcome to your opinion. The question is whether the message is a request or a response. Yes, a request sent on an interface should use that interface's address. A response must use he address to which its request was sent, else the peer will not be able to correlate it with its request. But the route table in the host can send it out any interface. It's a bug, yes, but it is the truth. See draft-baker-6man-multiprefix-default-route for a way around that. 6man doesn't like it. > Hence it is OK to filter such packets. After all, the packets would > also get filtered if the two interfaces happened to connect to > different > links, and ingress filtering was applied on access routers. > > > Section 2.2, 2nd paragraph: > > The problem on a router interface should be obvious: a router > forwards datagrams sent by other systems, which carry the source > address of their originators. If this feature is applied to a > router > interface, the data it is forwarding will be discarded, nullifying > its usefulness without advising either the network or its users of > the fact - a clear violation of the End-to-End principle. > > Simply state that the Source Guard can verify the IP addresses of only > non-forwarding hosts. You seem to have missed RFC 2460's definition of a router and a host. A system that forwards a datagram is a router; any other system is a host. There *are* no non-forwarding hosts. > As I said above for section 2.1, 1st paragraph, > that sould work also for hosts with multiple IP addresses on an > interface and for NATs. See my comments on same. > Section 2.2, 3rd paragraph: > > The problem on other varieties of devices - NATs that use multiple > addresses, hosts that have "primary" and "secondary" addresses, and > hosts with multiple LAN interfaces - is of the same nature. The > system will be prevented from carrying out an intended function > when > using an address other than the one that the switch is enforcing > the > use of. > > See my comments above for section 2.1, 1st paragraph. See my comments on same. -----BEGIN PGP SIGNATURE----- iD8DBQFHSk/XbjEdbHIsm0MRAnbXAKDAW82miXUKi+hJGzczOkN/Ln/9bwCgqx7z f0feGsFMoh78ai58aIQcRLQ= =+z3a -----END PGP SIGNATURE----- From fred at cisco.com Mon Nov 26 13:02:31 2007 From: fred at cisco.com (Fred Baker) Date: Sun, 25 Nov 2007 21:02:31 -0800 Subject: [SAVA] Review of draft-baker-sava-cisco-ip-source-guard-00 In-Reply-To: References: <47472488.5010909@nomadiclab.com> Message-ID: <1AA8384F-CAAB-461C-AC75-BE7EE28F9A00@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 25, 2007, at 8:47 PM, Fred Baker wrote: > There *are* no non-forwarding hosts. arg. correction: all hosts are non-forwarding. -----BEGIN PGP SIGNATURE----- iD8DBQFHSlNnbjEdbHIsm0MRApQLAKDgnxR8LyoAYFlztxoYOy+pjPma+wCg1f1e KKhWLEHEL8rZQjvh/hLptGY= =HxWa -----END PGP SIGNATURE----- From christian.vogt at nomadiclab.com Mon Nov 26 23:25:04 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Mon, 26 Nov 2007 17:25:04 +0200 Subject: [SAVA] Review of draft-baker-sava-cisco-ip-source-guard-00 In-Reply-To: References: <47472488.5010909@nomadiclab.com> Message-ID: <474AE550.80900@nomadiclab.com> Fred - Most of my comments were because I am looking at the Source Guard idea conceptually, while you were describing Cisco's implementation in particular. It would be good to stricter distinguish between the two in the draft. This will make it clear that features not supported by the current implementation do not necessarily conflict with the Source Guard idea as such -- like the use of multiple IP addresses per interface. More comments below... >> Section 2, 3rd paragraph: >> >> As described, the feature is clearly one implemented on an IP or >> Ethernet switch intended for use in a SOHO, corporate, or access >> network. It is not, at this writing, supported on Cisco routers, nor >> is it something one would expect to be implemented on a host. >> >> I think the last part of the latter sentence can be dropped because an >> implementation on a host would theoretically be feasible. Why not have >> a host implement the Source Guard and have it verify the source address >> in packets received directly from a neighbor? > > If you're asking about Cisco's implementation, which is specifically > what was requested and what I documented, Cisco doesn't make hosts. Sure, just change the wording a bit. Currently the draft says that one would not "expect" the Source Guard functionality to be implemented in hosts. What it should say is that there is no host implementation for it, but that it would in principle be feasible. >> Section 2.1, 1st paragraph: >> >> In the IPv4 architecture, it is legal to have more than one IP >> address on a host, and there are systems (including routers and some >> hosts) that routinely send datagrams using a source IP address that >> differs from the interface's primary IP address. However, in the >> general case, a host has one address for each interface, and in the >> general case, a host has one interface. It is this case that the IP >> Source Guard feature addresses. By dropping all IPv4 datagrams from >> such hosts that use a different address than the one assigned, the >> feature severely limits a network's ability to introduce spoofed >> source addresses to the Internet. >> >> Why would hosts with multiple interfaces be a problem? Since the >> Source Guard sees only interfaces, it does not care if multiple >> interfaces belong to the same host. > > it does care about addresses uses by the host. If the host has multiple > interfaces, it has multiple addresses, and there are cases where a host > will use the address from one interface on a message transmitted on > another (for example, if it is replying to q request and its route table > specifies an interface to send the datagram on). If it is limiting the > use of the interface to a single address, that will scotch such a message. My thinking was that it would be OK to filter packets with a source address from a different interface than the transmitting one. The reason is that such a source address would be incorrect anyway. So the question is if a source address validation technique should allow hosts to use any of their IP addresses as a source address for sending via any of its interfaces. Personally, I don't fully agree that the fact that this is a "prevalent bug" means that source address validation techniques should permit it. Permitting it would make the techniques either more complex, or inapplicable to scenarios with multi-interface hosts. >> Additionally, why would hosts with multiple IP addresses per interface >> be problematic? One simply needs to bind a single link layer address to >> multiple IP addresses. > > While that happens in IPv4, it is not common (it is fairly ancient BSD > technology and no longer widely used), and the Cisco implementation very > specifically limits the host to a single address on the interface, the > one assigned using DHCP. That's fair enough. I wonder, though, if you could differentiate a bit clearer between the Source Guard idea as such and Cisco's implementation specifically. I think the Source Guard idea is conceptually well compatible with hosts which have multiple IP addresses per interface, even though the currently available implementation might be more restrictive. >> Similar case with NATs, which are listed as a pitfall in the 3rd >> paragraph of section 2.2: They should work with the Source Guard if you >> set up multiple IP/link-layer address bindings for the same link-layer >> address. > > They will if it is the type of NAT that overlays all traffic on one > address. Not all NATs do that. I don't see a problem even if the NAT would use multiple external addresses. All of those addresses would have to be bound to the NAT's single link layer address; that should do it. But maybe we are talking about two different things here... >> Section 2.2, 1st paragraph: >> >> IP Source Guard assumes that some ports on a switch - those whose >> single interface has one address - are "protected" and others are >> not. "Others" include systems with multiple interfaces, which might >> as a result receive a datagram through one interface and respond to >> it ("from" the IP of that interface) on the other, for which this >> capability is obviously problematic. "Others" also includes routers, >> prefix-based NATs, and others, which may originate traffic from a >> variety of addresses that are not within the local prefix. >> >> IMO, a host that sends packets through one of its interfaces with a >> source address configured on another of its interfaces does misbehave. > > you're welcome to your opinion. The question is whether the message is a > request or a response. Yes, a request sent on an interface should use > that interface's address. A response must use he address to which its > request was sent, else the peer will not be able to correlate it with > its request. But the route table in the host can send it out any > interface. It's a bug, yes, but it is the truth. I do see your point, Fred. And it is likely that we won't be able to do anything about it because we don't have a host identify available to which IP addresses could be bound -- we only have interface IDs. The best is probably to explicitly state that the described host behavior is incorrect, but that it is a common phenomenon due to which the Source Guard feature may have to be disabled. > See draft-baker-6man-multiprefix-default-route for a way around that. > 6man doesn't like it. Section 2.2 of draft-baker-6man-multiprefix-default-route would already be enough. >> Hence it is OK to filter such packets. After all, the packets would >> also get filtered if the two interfaces happened to connect to different >> links, and ingress filtering was applied on access routers. >> >> >> Section 2.2, 2nd paragraph: >> >> The problem on a router interface should be obvious: a router >> forwards datagrams sent by other systems, which carry the source >> address of their originators. If this feature is applied to a router >> interface, the data it is forwarding will be discarded, nullifying >> its usefulness without advising either the network or its users of >> the fact - a clear violation of the End-to-End principle. >> >> Simply state that the Source Guard can verify the IP addresses of only >> non-forwarding hosts. > > You seem to have missed RFC 2460's definition of a router and a host. A > system that forwards a datagram is a router; any other system is a host. > There *are* no non-forwarding hosts. Yes, that was a tautology. - Christian From christian.vogt at nomadiclab.com Tue Nov 27 07:29:36 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Tue, 27 Nov 2007 01:29:36 +0200 Subject: [SAVA] Agenda for Vancouver BoF Message-ID: <474B56E0.5020305@nomadiclab.com> Folks, here is the agenda for our BoF in Vancouver: Problems to solve, focus for SAVI 10 min Danny McPherson, Christian Vogt IPv4 Source Guard ? An existing technique 10 min for source address validation on the 1st hop Fred Baker, draft-baker-sava-cisco-ip-source-guard-00 Source Guard for IP version 6 15 min Fred Baker, draft-baker-sava-implementation-00 Discussion 25 min The goal is to keep the presentation part focused on concrete proposals, and to allow sufficient time for the discussion about the charter. CU in Vancouver! - Danny and Christian From christian.vogt at nomadiclab.com Tue Nov 27 23:59:11 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Tue, 27 Nov 2007 17:59:11 +0200 Subject: [SAVA] SAVI Dinner? Message-ID: <474C3ECF.5080509@nomadiclab.com> Folks, are you interested in a "SAVI dinner"? How about Wednesday after the IESG/IAOC plenary? - Danny and Christian From miw at computer.org Wed Nov 28 00:17:18 2007 From: miw at computer.org (Mark Williams) Date: Wed, 28 Nov 2007 00:17:18 +0800 Subject: [SAVA] SAVI Dinner? In-Reply-To: <474C3ECF.5080509@nomadiclab.com> References: <474C3ECF.5080509@nomadiclab.com> Message-ID: <474C430E.1020800@computer.org> count me in Mark Christian Vogt wrote: > Folks, > > are you interested in a "SAVI dinner"? How about Wednesday after the > IESG/IAOC plenary? > > - Danny and Christian > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > From fred at cisco.com Wed Nov 28 00:24:24 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 27 Nov 2007 08:24:24 -0800 Subject: [SAVA] SAVI Dinner? In-Reply-To: <474C3ECF.5080509@nomadiclab.com> References: <474C3ECF.5080509@nomadiclab.com> Message-ID: <42D70390-AB53-44AF-8E98-1C321485D9F1@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Willing. I'd personally prefer Tuesday night. On Nov 27, 2007, at 7:59 AM, Christian Vogt wrote: > Folks, > > are you interested in a "SAVI dinner"? How about Wednesday after the > IESG/IAOC plenary? > > - Danny and Christian > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava -----BEGIN PGP SIGNATURE----- iD8DBQFHTES4bjEdbHIsm0MRAmx8AJ0Sms/bbhJ1fFz+288ix0IxzgZbggCfbpsQ QHBP7hldL7cJ6PBDb9JpWVg= =Iwy0 -----END PGP SIGNATURE----- From fred at cisco.com Wed Nov 28 00:26:43 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 27 Nov 2007 08:26:43 -0800 Subject: [SAVA] SAVI Dinner? In-Reply-To: <42D70390-AB53-44AF-8E98-1C321485D9F1@cisco.com> References: <474C3ECF.5080509@nomadiclab.com> <42D70390-AB53-44AF-8E98-1C321485D9F1@cisco.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 27, 2007, at 8:24 AM, Fred Baker wrote: > Willing. I'd personally prefer Tuesday night. Oops, Tuesday night just got taken. Yes, I can do Wednesday night. :-) > On Nov 27, 2007, at 7:59 AM, Christian Vogt wrote: > >> Folks, >> >> are you interested in a "SAVI dinner"? How about Wednesday after the >> IESG/IAOC plenary? >> >> - Danny and Christian -----BEGIN PGP SIGNATURE----- iD8DBQFHTEVDbjEdbHIsm0MRAnIRAJ4zlAlcU7qBB4nzBoi9OKCTM2OOfgCfXgXH n8e2ydcPFSKPPlUX1y+AiYc= =BB7L -----END PGP SIGNATURE----- From bgreene at cisco.com Wed Nov 28 00:40:40 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Tue, 27 Nov 2007 08:40:40 -0800 Subject: [SAVA] SAVI Dinner? In-Reply-To: <474C3ECF.5080509@nomadiclab.com> References: <474C3ECF.5080509@nomadiclab.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm in. > -----Original Message----- > From: sava-bounces at mail.nrc.tsinghua.edu.cn > [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of > Christian Vogt > Sent: Tuesday, November 27, 2007 7:59 AM > To: SAVA Mailing List > Subject: [SAVA] SAVI Dinner? > > Folks, > > are you interested in a "SAVI dinner"? How about Wednesday > after the IESG/IAOC plenary? > > - Danny and Christian > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBR0xIiL/UEA/xivvmEQKgxQCeKZK9jyd+hxuOWRWyjga3kL6dyoEAoMm9 xGxZocqy3/RqXObkGpg91jRG =bOnY -----END PGP SIGNATURE----- From wassim.haddad at ericsson.com Wed Nov 28 01:52:00 2007 From: wassim.haddad at ericsson.com (Wassim Haddad) Date: Tue, 27 Nov 2007 12:52:00 -0500 Subject: [SAVA] SAVI Dinner? References: <474C3ECF.5080509@nomadiclab.com> Message-ID: <95D8C1105D54EB41864F8831E6C4EB75021C81C2@ecamlmw720.eamcs.ericsson.se> Am interested. Regards, Wassim H. -----Original Message----- From: sava-bounces at mail.nrc.tsinghua.edu.cn on behalf of Christian Vogt Sent: Tue 11/27/2007 4:59 PM To: SAVA Mailing List Subject: [SAVA] SAVI Dinner? Folks, are you interested in a "SAVI dinner"? How about Wednesday after the IESG/IAOC plenary? - Danny and Christian _______________________________________________ SAVA mailing list SAVA at mail.nrc.tsinghua.edu.cn http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava From junbi at cernet.edu.cn Wed Nov 28 02:03:32 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Wed, 28 Nov 2007 02:03:32 +0800 Subject: [SAVA] SAVI Dinner? In-Reply-To: <95D8C1105D54EB41864F8831E6C4EB75021C81C2@ecamlmw720.eamcs.ericsson.se> References: <474C3ECF.5080509@nomadiclab.com> <95D8C1105D54EB41864F8831E6C4EB75021C81C2@ecamlmw720.eamcs.ericsson.se> Message-ID: <5E6C7CBD975E44BF893113BB36AD430A@userPC> Please count 5-6 people from Tsinghua/CERNET. Thanks, Jun bi ----- Original Message ----- From: "Wassim Haddad" To: "Christian Vogt" ; "SAVA Mailing List" Cc: "Wassim Haddad" Sent: Wednesday, November 28, 2007 1:52 AM Subject: Re: [SAVA] SAVI Dinner? > Am interested. > > > Regards, > > Wassim H. > > > > -----Original Message----- > From: sava-bounces at mail.nrc.tsinghua.edu.cn on behalf of Christian Vogt > Sent: Tue 11/27/2007 4:59 PM > To: SAVA Mailing List > Subject: [SAVA] SAVI Dinner? > > Folks, > > are you interested in a "SAVI dinner"? How about Wednesday after the > IESG/IAOC plenary? > > - Danny and Christian > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > From christian.vogt at nomadiclab.com Wed Nov 28 06:50:08 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Wed, 28 Nov 2007 00:50:08 +0200 Subject: [SAVA] SAVI Dinner? In-Reply-To: <474C3ECF.5080509@nomadiclab.com> References: <474C3ECF.5080509@nomadiclab.com> Message-ID: <474C9F20.9060503@nomadiclab.com> Folks, too many conflicting suggestions (also got some not CC'ed to the list). Please do me a favor and check your availability here: http://www.doodle.ch/mae9crv5gndka9eg Thanks, - Christian From jianping at cernet.edu.cn Wed Nov 28 12:58:13 2007 From: jianping at cernet.edu.cn (Jianping WU) Date: Wed, 28 Nov 2007 12:58:13 +0800 Subject: [SAVA] SAVI Dinner? References: <474C3ECF.5080509@nomadiclab.com> <474C9F20.9060503@nomadiclab.com> Message-ID: <474CF565.6090206@cernet.edu.cn> I will arrive Vancouver in the morning of Tuesday and favor the dinner of Tuesday or after. Thanks Jianping Christian Vogt wrote: >Folks, > >too many conflicting suggestions (also got some not CC'ed to the >list). Please do me a favor and check your availability here: > > http://www.doodle.ch/mae9crv5gndka9eg > >Thanks, >- Christian > >_______________________________________________ >SAVA mailing list >SAVA at mail.nrc.tsinghua.edu.cn >http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > > > From jianping at cernet.edu.cn Wed Nov 28 22:08:15 2007 From: jianping at cernet.edu.cn (Jianping WU) Date: Wed, 28 Nov 2007 22:08:15 +0800 Subject: [SAVA] SAVI Dinner? References: <474C3ECF.5080509@nomadiclab.com> <474C9F20.9060503@nomadiclab.com> Message-ID: <474D764F.4040503@cernet.edu.cn> I will arrive Vancouver in the morning of Tuesday and favor the dinner of Tuesday or after. Thanks Jianping Christian Vogt wrote: >Folks, > >too many conflicting suggestions (also got some not CC'ed to the >list). Please do me a favor and check your availability here: > > http://www.doodle.ch/mae9crv5gndka9eg > >Thanks, >- Christian >_______________________________________________ >SAVA mailing list >SAVA at mail.nrc.tsinghua.edu.cn >http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > > > From christian.vogt at nomadiclab.com Thu Nov 29 06:58:06 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Thu, 29 Nov 2007 00:58:06 +0200 Subject: [SAVA] SAVI Dinner: Tuesday, Dec. 4, 20:15 @ Registration Desk Message-ID: <474DF27E.4030404@nomadiclab.com> Folks, let's have a SAVI dinner on Tuesday, December 4, and meet at 20:15 at the registration desk. Dinner on Tuesday is the clear winner according to our Doodle poll. Looking forward to seeing you! - Christian From denghui02 at gmail.com Thu Nov 29 08:44:10 2007 From: denghui02 at gmail.com (Hui Deng) Date: Thu, 29 Nov 2007 08:44:10 +0800 Subject: [SAVA] SAVI Dinner? In-Reply-To: <474D764F.4040503@cernet.edu.cn> References: <474C3ECF.5080509@nomadiclab.com> <474C9F20.9060503@nomadiclab.com> <474D764F.4040503@cernet.edu.cn> Message-ID: <1d38a3350711281644g325213c5ta8f208955c740ca4@mail.gmail.com> I will try to join this dinner, thanks -Hui 2007/11/28, Jianping WU : > I will arrive Vancouver in the morning of Tuesday > and favor the dinner of Tuesday or after. > > Thanks > > Jianping > > Christian Vogt wrote: > > >Folks, > > > >too many conflicting suggestions (also got some not CC'ed to the > >list). Please do me a favor and check your availability here: > > > > http://www.doodle.ch/mae9crv5gndka9eg > > > >Thanks, > >- Christian > >_______________________________________________ > >SAVA mailing list > >SAVA at mail.nrc.tsinghua.edu.cn > >http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > > > > > > > > > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava >