Subject: Re: [RPSEC] issue: ASPATH

From: Sandy Murphy <[email-masked]>
Date: Mon, 14 Mar 2005 11:36:09 -0500 (EST)

>>>>I ran across this one, I think on NANOG:
>>>>
>>>>    major ISP                              major ISP
>>>>    west coast ----------------------------east coast
>>>>        |                                      |
>>>>        |                                      |
>>>>         \--big national multi-homed customer--/
>>>>
>>>>Major ISP has an outage on the cross continent link and starts routing
>>>>traffic through the customer's network
>
>it was not a valid path for transit traffic, as we all agree. however 
>the failure here seems to be a result of both the ISP and the 
>multi-homed subscriber not causing forwarding tables in their border 
>routers match their local policies. If EITHER of them  did that 
>correctly, the misdirected traffic flow would not happen.

Well, I disagree.  The "major ISP" did not violate the local policy
- it *changed* its local policy and its forwarding.  And the
customer did not have a forwarding table that violated local
policy - if you are presuming that the customer's policy was
"I don't carry transit".  There's no way for the forwarding table
to represent that - forwading tables don't look at source.  Now,
you could make the filter on the incoming router reject traffic
not intended for a customer address.  (And, come to think of it,
I don't know why that was not done).  But it isn't a forwarding
vs policy problem.

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2005 13:13:20 -0500

>I don't know why that was not done).  But it isn't a forwarding

Sandy,

I think I may have lost the context.  Sorry for my confusion. Let me 
try to reestablish what happened, and why.

Are you saying that the ISP erroneously accepted an advertisement 
from the multi-homed subscriber that advertised some portion of the 
ISP's address space, or some address space NOT associated with the 
subscriber, and as a result changed it's forwarding tables? if so, 
then  path security measures would prevent such acceptance, if 
properly, locally, maintained. If not, then what triggered the 
forwarding table change?

Secondly, with regard to the subscriber's forwarding tables in the 
BGP speakers that connect to the ISP, why would they have entries to 
forward INBOUND traffic for any but their own prefixes?

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 14 Mar 2005 15:28:17 -0500 (Eastern Standard Time)

> Well, I disagree.  The "major ISP" did not violate the local policy - it 
> *changed* its local policy and its forwarding.  And the customer did not 
> have a forwarding table that violated local policy - if you are presuming 
> that the customer's policy was "I don't carry transit".  There's no way 
> for the forwarding table to represent that - forwading tables don't look 
> at source.

Neither do routing tables.... Or routing protocols. There are some 
mechanisms for carrying policy information, but they are secondary to 
finding loop free paths.

> Now, you could make the filter on the incoming router reject traffic not 
> intended for a customer address.  (And, come to think of it, I don't know 
> why that was not done).  But it isn't a forwarding vs policy problem.

Exactly. It's a forwarding plane problem, fix it at the forwarding plane. 
You're never going to be able to fix this with routing. You can indicate 
the policy, but you can't enforce it.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Stefan Mink <[email-masked]>
Date: Fri, 18 Mar 2005 00:41:38 +0100

Russ White wrote:
> Exactly. It's a forwarding plane problem, fix it at the forwarding
> plane. You're never going to be able to fix this with routing. You can
> indicate the policy, but you can't enforce it.

one would need "forward path filtering" instead of RPF ;)

At the moment you're stuck with manual firewalling entries
to enforce your policy on forwarding plane :(

    tschuess
              Stefan
--
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec