Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes

From: [email-masked]
Date: Mon, 15 Dec 2008 17:51:33 +0000

> While I agree that we don't ever want to ignore updates or provide
> non-deterministic behavior

Note that in this case the decoding of the update got far enough to be able  
to identify the individual routes in the update.

Because of this an alternative is available: instead of ignoring the  
update, we can treat these "illegal" routes as unusable, ie no different  
than -say- a route with an unreachable next-hop.

This will lead to perfectly deterministic behavior, eg pick another route  
to the same prefix as the best route, or if no alternative is available,  
send out withdraws.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 11:05:46 -0700

On Dec 15, 2008, at 10:51 AM, [email-masked] wrote:
>
> Note that in this case the decoding of the update got far enough to  
> be able to identify the individual routes in the update.
>
> update, we can treat these "illegal" routes as unusable, i.e. no  
> different than -say- a route with an unreachable next-hop.
>
> This will lead to perfectly deterministic behavior, e.g. pick  
> another route to the same prefix as the best route, or if no  
> alternative is available, send out withdraws.

This results in non-deterministic reachability for the
prefix in question though, and I suspect even result in
forwarding loops.

Given that we can be certain AS_CONFED_* segments serve NO
function in AS4_PATH, I believe discarding only those segments
and continuing normal processing is a reasonable response for
a receiver.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 12:23:08 -0700

On Dec 15, 2008, at 11:11 AM, Jeffrey Haas wrote:
>
> On Mon, Dec 15, 2008 at 11:05:46AM -0700, Danny McPherson wrote:
> The presumption is that the path is malformed in some fashion.  Can  
> you
> really trust that the portions to either side of the confederation
> segments are correct?  Should you attempt to determine which  
> external AS
> those segments represents?
>
> I'd still suggest discarding the update.

After thinking about this for a few minutes, I can't currently
come up with any configuration where a forwarding loop would occur
as a result of just dropping the update (because the "translation"
occurs on ingress to an AS), so discarding the update is likely
to be a cleaner action.

Somewhat related and considering implementations that
are currently generating or processing these, two questions
come to mind:

1) did the AS that put the as_confed_* segments there also
include their confederation identifier?  If not, a routing
information loop might occur.

2) if a NEW BGP speaker is accepting these as_confed_* segments
and they're using confederations within their AS, then "matches"
with member AS numbers might cause routes to be discarded within
some member ASes of the confederation.

RFC 4893 definitely needs to be updated with new handling
procedures.

-danny

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 15 Dec 2008 14:36:34 -0500

[resending with cropped cc list to get around brain-damaged ietf  
bogosity filter]

On Dec 15, 2008, at 1:11 PM, Jeffrey Haas wrote:
> On Mon, Dec 15, 2008 at 05:51:33PM +0000, [email-masked]  
> wrote:
> In that case, the presumption is that you would *ever* want to use it.
> I suggest simply discarding the update.

Discarding updates without processing them as Cayle describes violates  
the loop free property.  Consider the fact that an advertisement of a  
route is also an implicit withdrawal of any previous advertisement,  
and also consider that an update can also carry explicit withdrawals.   
Simply discarding an update is thus equivalent to ignoring a  
withdrawal.  It's not difficult to construct a scenario in which  
persistent forwarding loops ensue.  A scenario with a persistent  
blackhole is trivial.

If you ever get into a state where the only sensible thing you can do  
is discard an update, you're at the point where BGP's most fundamental  
correctness property is broken.  I think you want to think very, very  
hard about whether the "cure" (dropping the update) is worse than the  
disease (dropping the session).  OTOH, I think it's worth continuing  
the discussion about what kinds of other actions can be taken up to,  
but not including, dropping the update.

> segments are correct?

This has generally been my position in past iterations of this annual  
debate.  I'm starting to moderate it based on the demonstrated  
operational problems caused in particular by bad optional/transitives.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 15 Dec 2008 14:37:00 -0500

> occurs on ingress to an AS), so discarding the update is likely

AS1---AS2
   \   /
    \ /
    AS3

- AS1 prefers to reach AS3 directly, and advertises its route to AS2.
- AS2 prefers to reach AS3 directly, and advertises its route to AS1.
- Connections AS3-AS1 and AS3-AS2 fail simultaneously.
- AS1 switches to prefer AS2's route, and sends an update message which
   includes a withdraw of its previous announcement.  The withdraw is
   bundled with some advertisements.  It includes a bad attribute.  As a
   result, AS2 ignores the message.
- AS2 switches to prefer AS1's route, and sends an update message which
   includes a withdraw of its previous announcement.  The withdraw is
   bundled with some advertisements.  It includes a bad attribute.  As a
   result, AS1 ignores the message.

End result is that AS1 forwards traffic for AS3 towards AS2, and AS2  
forwards traffic for AS3 towards AS1.  This is a permanent (until  
corrected) forwarding loop.

I'm sure a less-contrived example can also be constructed, but this  
one should be sufficient to prove the point.

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Dec 2008 15:00:51 -0500

On Mon, Dec 15, 2008 at 02:36:34PM -0500, John G. Scudder wrote:
> Discarding updates without processing them as Cayle describes violates the 
> loop free property.  Consider the fact that an advertisement of a route is 
> also an implicit withdrawal of any previous advertisement, and also 
> consider that an update can also carry explicit withdrawals.  Simply 
> discarding an update is thus equivalent to ignoring a withdrawal.  It's not 
> difficult to construct a scenario in which persistent forwarding loops 
> ensue.  A scenario with a persistent blackhole is trivial.

That was a point I clearly hadn't thought through: This may affect
implicit withdrawals along with other bundled reachability.

At the risk of missing something else obvious in a quick reply, presume
instead of dropping the update that the withdrawn routes field is processed
and that all reachability covered by the path attributes is deleted
instead of being installed or updated.  I believe this would have the
effect I was originally intending without leaving stale information in
the system.

> debate.  I'm starting to moderate it based on the demonstrated operational 
> problems caused in particular by bad optional/transitives.

I think we're all there with you.

I suspect if the WG put our collective heads together we'd probably
arrive at some consensus on having more survivable sessions.  It'd
probably result in a re-spin of the previous INFORM specification,
perhaps renaming the attribute WTF.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 15 Dec 2008 15:08:14 -0500

> effect I was originally intending without leaving stale information in

Right, I think that was what Cayle also described and anyway was what  
I meant to agree with. :-)  It's ugly and has its own problems but  
doesn't appear to violate the loop free property assuming you can do  
it right.  One of the "own problems" is that it presumes the error  
you're coping with is one which leaves the update in a state where you  
can reliably dig out all the un/reachability information, including  
that in the NLRI field, the WITHDRAWN ROUTES field, the  
MP_{UN}REACH_NLRI attributes, and any other place where un/ 
reachability information may end up residing in the future.  (I think  
this is kind of a restatement of your earlier point which generally  
pertained to slippery slopes and grot.)

> perhaps renaming the attribute WTF.

You have just volunteered to craft an appropriate TLA back- 
formation. :-)

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Dec 2008 15:28:51 -0500

On Mon, Dec 15, 2008 at 03:08:14PM -0500, John G. Scudder wrote:
> Right, I think that was what Cayle also described and anyway was what I 
> meant to agree with.

I had interpreted Cayle perhaps a bit too pedantically (apropos) in that
I thought it was a matter of keeping the reachability around as
ineligible rather than discarding it as toxic.

In any case, I think we largely agree.

> (I think this is kind of a restatement of your earlier point which 
> generally pertained to slippery slopes and grot.)

Exactly.  This is the kind of thing that if you're going to have these
sorts of responses, keeping internal records of discarded vs. repaired
might be important for internal tie-breaking: I.e. prefer the routes
that are less broken.

> You have just volunteered to craft an appropriate TLA back-formation. :-)

This seems good wisdom for all route-by-rumor protocols.  I might put
together a 1 April RFC candidate for Weaponized Transitive Foolishness.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Dec 2008 15:41:44 -0500

> might be important for internal tie-breaking: I.e. prefer the routes

A response off-list reminded me that I'd forgotten the smiley here.
This would never be a good idea.

-- Jeff