Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes

From: "Tom Petch" <[email-masked]>
Date: Mon, 1 Mar 2004 18:10:44 -0000

It's a fair point but sounds more like
draft-ietf-idr-bgp4-experience-protocol-03.txt
than
draft-ietf-idr-bgp4-23.txt

Tom Petch

-----Original Message-----
From: Pekka Savola <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 29 February 2004 06:24
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes

>After some off-list iteration, a revamped version of the possible text
>could be:
>
>In certain common deployment scenarios, the next-hop addresses are
>supposed to be valid only if resolved via routes of a specific type
>(e.g., IGP, connected or local).  There are likely less specific
>routes from other sources (e.g., static or BGP) which may resolve the
>next-hops as well, but such resolvability typically leads to problems
>when the less specific route actually can't be used to reach the
>next-hop, and the BGP routes are not invalidated even though their
>next-hop is, for all intents and purposes, unroutable.  Therefore, it
>is advisable that the implementations allow the operator to specify
>which routes should yield a positive result if they covered the the
>next-hop.
>
>.. thoughts?  This doesn't have any MAY/SHOULD etc. terminology, at
>least yet -- maybe it should.
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr

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

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 1 Mar 2004 18:10:44 -0000

Tom Petch

-----Original Message-----
From: Pekka Savola <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 29 February 2004 06:24
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 27 Feb 2004 13:43:28 -0500

In message <[email-masked]>, Robert Raszuk writes:
> 
> http://www.securite.org/presentations/secip/BHAMS2001-SecIP-v105-full.ppt

Robert,

This file is in some sort of strange proprietary format.  Was that a
mistake?  :-)

Curtis

---

From: Parantap Lahiri <[email-masked]>
Date: Fri, 27 Feb 2004 15:26:56 -0500

The problem Pekka is describing is definitely a very valid problem which
exists. I am not sure though if the fix is in some design modifications or
in fixing the spec itself. 

The ways to fix it by design modification would be ...

The router R1 in question resets the BGP next-hop to some secondary loopback
address which is different from the primary loopback (part of the prefix/16)
and the secondary loopback address range is only in IGP as discrete /32s,
this problem might be mitigated. Though it's going to load the IGP with a
new set of IP prefixes and may be problematic in some situations since some
IGP protocols have limited capability to carry large number of IP prefixes. 

The other way to solve it might be a vendor implemented knob, where a
particular address range (like prefix/16) is never considered while doing
BGP next hop resolution. Though, I am not sure if this knob would be a part
of the spec.

-Parantap

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pekka
Savola
Sent: Friday, February 27, 2004 3:01 PM
To: John G. Scudder
Cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes

On Fri, 27 Feb 2004, John G. Scudder wrote:
> >.. the problem is that unless you have full routing table in every
> >router, and no default discard/aggregate routes/etc., this works. 
> >Otherwise when your IBGP neighbor goes down, the BGP routes learned
> >from that neighbor stay in the BGP table until the BGP session is
> >reset after 90 seconds or so.  Instead, the routes should immediately
> >be removed from BGP when the loopback address is removed from the IGP.
> 
> I agree with your final sentence; however, I 
> don't understand the other parts of that 
> paragraph, nor how your proposed text would help 
> it.  

Ok.  Let me try to clarify the situation.  Assume router R1 in the AS 
has some a route, route_r1, which it sends to every iBGP router.  
Router R1 goes down.  OSPF notices that R1 has gone down, as its 
loopback address has been removed from OSPF.

Assume that a core router or two in the AS has been set up with a 
couple of "null0" routes, for the purposes of aggregation, or default 
route redistribution, e.g., "prefix/16" or "0/0".

Assume that the nexthop of route_r1 matches these null0 routes.

Now, all other routers in the AS keep route_r1 in their routing table 
as long as the BGP session stays up (some 90 seconds or so), because 
its nexthop, the loopback address of R1 -- while no longer available 
with OSPF, is still recursively resolvable through either one of the 
null0 routes.

This causes a major problem.  This implies that for BGP to function
properly, the loopback or point-to-point addresses MUST NOT have any 
less-specific routes which could be considered unresolvable if the 
main route itself is removed from IGP.

> In fact, I don't think there is a problem in 
> the spec as it stands with IBGP routes which 
> resolve to a loopback -- these are covered by 
> 9.1.2.1(1).  

When the loopback address is removed from OSPF, the next best route is 
the static default discard route (or something like that) -- which is 
an interface route.

> As others have mentioned, if a route 
> resolves to null0 or the like, this is presumably 
> the result of deliberate configuration and 
> certainly not something we want to preclude in 
> the spec.

Yep, this causes a problem with the DDoS mitigation method described 
earlier, so I'm not sure what the right fix is.

However, it clearly seems to call for a requirement to be able to 
specify, somehow, which routes should be used when considering 
resolvability (e.g., just connected and IGP routes, ...).

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 27 Feb 2004 14:36:28 -0500

In message <p0602040ebc6536bf8c68@[192.168.42.3]>, "John G. Scudder" writes:
> Pekka,
> 
> I'm confused -- to my eye, the spec change you propose:
> 
> At 9:01 AM +0200 2/27/04, Pekka Savola wrote:
> >Hi,
> >
> >We analyzed one source of operational BGP problems and noticed a
> >problem which should be made explicit in the BGP specification.
> >
> >In draft-ietf-idr-bgp4-23.txt, section 9.1.2.1:
> >
> >       2. Routes referencing interfaces (with or without intermediate
> >       addresses) are considered resolvable if the state of the refer-
> >       enced interface is up and IP processing is enabled on this inter-
> >       face.
> >
> >I propose adding something like:
> >
> >             For the purposes of this check, the routes for which
> >       packets are discarded by the router (i.e., "null" or "discard"
> >       routes) SHOULD be considered unresolvable.
> 
> Doesn't correspond to the problem you describe:
> 
> it.  In fact, I don't think there is a problem in 
> 9.1.2.1(1).  As others have mentioned, if a route 
> Maybe you could expand further on what you think the problem is.
> 
> --John
> 

You can never advertise a discard route to a BGP peer which makes
sense but the text in 9.1.2.1 doesn't deal with advertisement.

If you have a discard route, you probably put it there for a reason
and therefore you don't want to exclude that router from the decision
process.  It doesn't really come into play in this decision.  The
discard route would override the best BGP route.  It would often be a
more specific route, maybe a /32.

Curtis