Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt]

[Rob Shakir <rjs at eng.gxn.net>]

On Tue, Jan 27, 2009 at 11:18:01AM -0800, Enke Chen wrote:
> Yes, indeed. A routing loop may (or may not) occur when the AS4_PATH  
> should carry useful info but is either malformed or is absent.
>
> There is no perfect solution here.  There are some tradeoffs, however,  
> between accepting the route and rejecting the route:
>
>     o rejecting the route would guarantee disruption (i.e., loss of  
> connectivity).
>     o accepting the route would maintain connectivity, but may (or may  
> not) introduce a routing loop.
>
>> Take for example the case when an BGP speaker in a 32bit AS receiving 
>> an invalid AS4_PATH attribute. With the AS4_PATH unreadable and 
>> therefore discarded the BGP speaker cannot know if its AS number was in 
>> the path. The only loop free options are:
>> (a) treat it as a withdrawal
>> (b) treat any AS_TRANS in the AS_PATH as the local AS
>> (c) drop the session.
>>
>> Option c is the behaviour that has led us to needing a change to the  
>> RFC, so is obviously unacceptable.
>>   
>
> Why is Option C "obviously unacceptable"?
>
> I think the reason is that it would result in loss of connectivity for  
> all the routes over the session, and can be used as a remote attack 
> vehicle.

Enke,

Forgive me for replying only to this section of your mail -- however, I'd like
to clarify this statement. 

The reason that I originally picked up this problem is because I had a
requirement to deploy a software release that happened to include 4-byte ASN
support. The target device is a router that terminates a BGP transit session
from our upstream. With this code, since my transit provider is (as far as I am
aware) AS4-unaware through a large proportion (or maybe all) of their network,
my router is likely to be the first router in the path that supports 4-byte ASN,
and hence parses the AS4_PATH.

In this case, I am learning a full BGP table from this transit provider of
which only one prefix may contain invalid AS4_PATH information. According to the
existing RFC, my device sends a notification, and tears down the session. With
this behaviour, I have lost connectivity to all prefixes learnt via this
session, rather than a single prefix that has invalid data. I believe what makes
(c) 'obviously unacceptable' is that I am penalising all paths via my transit
provider due to invalid data in the update for one prefix.

The suggestion we provide differs from this in the important regard that I do
not penalise all prefixes that my transit provider announces to me, but only
those with invalid routing data. In the case where the invalid data is added by
a router that is not within the originating AS, then (if the originating ASN is
multi-homed - and not all routes propagate through the broken AS), I should see
this prefix via some other (valid) path.

It is only in the case that a prefix has no valid path to be propagated by that
I would lack a valid route to this destination, and hence lose connectivity.
You are correct that this could be all prefixes on a session, however, one must
consider /what/ prefixes these are, and not just what proportion are affected.
The current specification means that regardless of how many prefixes on a
session contain this invalid data, my network will lose the path to all prefixes
via the session.

I do accept the point that if an OLD speaker propagates this route to me, then
they are unaware of this invalid data, and hence I am penalising a path to which
my direct neighbour (and OLD speakers path) has propagated correctly (by
transiting an optional-transitive).

Kind regards,
Rob

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html

_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr