Subject: [SAVA] Review request

From: fred at cisco.com (Fred Baker)
Date: Tue, 6 Nov 2007 06:28:11 -0800

I am about to post this, and wonder if it gives anyone any heartburn

     ftp://ftpeng.cisco.com/fred/sava/local-sava.html

---

From: fred at cisco.com (Fred Baker)
Date: Tue, 6 Nov 2007 06:35:15 -0800

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?

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 6 Nov 2007 16:47:09 +0200 (EET)

> 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 (Jun Bi)
Date: Tue, 6 Nov 2007 23:57:01 +0800

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" <fred at cisco.com>
To: "SAVA Mailing List" <sava at nrc.tsinghua.edu.cn>
Sent: Tuesday, November 06, 2007 10:28 PM
Subject: [SAVA] Review request

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----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 (Fred Baker)
Date: Tue, 6 Nov 2007 08:43:28 -0800

> 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?

---

From: fred at cisco.com (Fred Baker)
Date: Tue, 6 Nov 2007 09:30:35 -0800

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?

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 6 Nov 2007 21:42:33 +0200 (EET)

On Tue, 6 Nov 2007, Fred Baker wrote:
> 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...

> 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|
>              +-+----+-+ +-+------+
>               | | |
> 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.

---

From: fred at cisco.com (Fred Baker)
Date: Tue, 6 Nov 2007 13:14:24 -0800

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.)
>
> 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.
>
> 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  

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.

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Wed, 7 Nov 2007 08:46:27 +0200 (EET)

On Tue, 6 Nov 2007, Fred Baker wrote:
>> 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

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
>>                         /     /
>>                       /     /
>>                       /     /
>>               +------+-+   +-+------+
>> 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.

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Wed, 7 Nov 2007 09:41:49 -0800

> 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.

---

From: fred at cisco.com (Fred Baker)
Date: Wed, 7 Nov 2007 16:44:39 -0800

On Nov 6, 2007, at 10:46 PM, Pekka Savola 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  
>> 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
>>
> 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. :-)

>> 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.
>
> 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  
> 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?

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 8 Nov 2007 08:06:32 +0200 (EET)

On Wed, 7 Nov 2007, Fred Baker wrote:
> 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.

---

From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Sun, 11 Nov 2007 15:38:55 +0100

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.

<delurk>

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 (Fred Baker)
Date: Sun, 11 Nov 2007 15:43:37 -0800

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.

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Mon, 12 Nov 2007 08:54:20 +0800

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" <iljitsch at muada.com>
To: "Jun Bi" <junbi at cernet.edu.cn>
Cc: "Fred Baker" <fred at cisco.com>; "SAVA Mailing List" 
<sava at nrc.tsinghua.edu.cn>
Sent: Sunday, November 11, 2007 10:38 PM
Subject: Re: [SAVA] Review request

>> 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.
>
> <delurk>
>
> 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 
> 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 (Fred Baker)
Date: Mon, 12 Nov 2007 13:35:36 +0000

> then there will be address conflict problem, so the spoofer can not  

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.