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

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

Enke,

Please see comments in-line to this diff.

> *** draft-chen-rfc4893bis-00.txt	Fri Jan 23 16:09:47 2009
> --- draft-chen-rfc4893bis-01.txt	Mon Feb  2 09:34:53 2009
> ***************
> *** 147,158 ****
>      To prevent the possible propagation of confederation path segments
>      outside of a confederation, the path segment types AS_CONFED_SEQUENCE
>      and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH
> !    attribute.  A NEW BGP speaker SHOULD NOT send these path segment
> !    types in the AS4_PATH attribute of an UPDATE message.  A NEW BGP
> !    speaker that receives these path segment types in the AS4_PATH
> !    attribute of an UPDATE message MUST discard these path segments,
> !    adjust the relevant attribute fields accordingly, and continue
> !    processing the UPDATE message.
>   
>      Similarly, this document defines a new aggregator attribute called
>      AS4_AGGREGATOR, which is optional transitive.  The AS4_AGGREGATOR
> --- 147,153 ----
>      To prevent the possible propagation of confederation path segments
>      outside of a confederation, the path segment types AS_CONFED_SEQUENCE
>      and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH
> !    attribute, and MUST NOT be carried in an UPDATE message.
>   
>      Similarly, this document defines a new aggregator attribute called
>      AS4_AGGREGATOR, which is optional transitive.  The AS4_AGGREGATOR
> ***************

This change seems to be reasonable -- the fact that this behaviour has been
observed does not mean that we should become permissive of errors in the
implementation. 


> *** 198,208 ****
>      peer, and MUST assume that these attributes in the updates received
>      from the peer encode Autonomous System numbers as 4-octet entities.
>   
> !    The new attributes, AS4_PATH and AS4_AGGREGATOR SHOULD NOT be carried
> !    in the UPDATE messages between NEW BGP peers.  A NEW BGP speaker that
> !    receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE
> !    message from a NEW BGP speaker SHOULD discard these path attributes
> !    and continue processing the UPDATE message.
>   
>   
>   4.2. Interaction Between NEW and OLD BGP Speakers
> --- 198,208 ----
>      peer, and MUST assume that these attributes in the updates received
>      from the peer encode Autonomous System numbers as 4-octet entities.
>   
> !    The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried
> !    in an UPDATE message between NEW BGP speakers.  A NEW BGP speaker
> !    that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute
> !    in an UPDATE message from another NEW BGP speaker MUST discard the
> !    path attribute and continue processing the UPDATE message.
>   
>   
>   4.2. Interaction Between NEW and OLD BGP Speakers
> ***************

This approach is problematic in my opinion. RFC 4271 defines how to handle
errors in UPDATE messages:

rfc4271>  6.3.  UPDATE Message Error Handling
rfc4271> 
rfc4271>    All errors detected while processing the UPDATE message MUST be
rfc4271>    indicated by sending the NOTIFICATION message with the Error Code
rfc4271>    UPDATE Message Error.  The error subcode elaborates on the specific
rfc4271>    nature of the error.

It then goes on to say:

rfc4271>    If an optional attribute is recognized, then the value of this
rfc4271>    attribute MUST be checked.  If an error is detected, the attribute
rfc4271>    MUST be discarded, and the Error Subcode MUST be set to Optional
rfc4271>    Attribute Error.  

In the new wording of your draft, this would then allow us to receive AS4_PATH
or AS4_AGGREGATOR from a neighbour which which we have negotiated 4-byte ASN
capabilities (and hence is a NEW BGP speaker). In this case, I don't see a
problem with sending NOTIFICATION and tearign down the session to this neighbour
-- my reading of rfc4271 would actually seem to suggest we MUST do this.

The approach that you have suggested appears overly reactionary -- there must
have been some thinking that led to invalid AS4_PATHs being responded to with a
NOTIFICATION, why now does there appear to have been a shift towards being
permissive of invalid routing information from a BGP speaker? What made
implementations of the original RFC dangerous was the fact that we punished an
OLD speaker for passing us attributes that it did not validate or parse, given
that a NEW speaker should validate this information, why should we accept it?


>   6. Error Handling
>   <removed text, see original mail>

One error handling approach after we have discarded this attribute is stating in
this RFC that any AS_TRANS that is observed in AS_PATH is assumed to be our own
AS, unless we are able to replace it with data from AS4_PATH. As someone
commented to me off-list, loops are very destructive, and we should try to avoid
them at almost any cost -- if we assume AS_TRANS is us , then we don't 'punish'
prefixes that are propagated with invalid data to us, but we do take measures to
ensure that we are not causing a loop.

However, there are of course some problems with doing this -- which I'd like to
open for discussion on this list. If we take into account that features such as
'as-override' and 'set as-path prepend last-as N', when an OLD speaker
manipulates the AS_PATH, then the AS4_PATH attribute is not updated.  When we
handle these manipulated AS_PATHs no 4-byte AS will be available to 'patch' out
the added AS_TRANS. This is suboptimal behaviour, as we'll discard this UPDATE
as a loop. This reverses the behaviour we saw originally (punishing an OLD
speaker for a NEW speaker's error), since we attach a penalty to a prefix
propagated by a NEW speaker due to a manipulation that an OLD speaker has made.

From my interpretation of the RFCs, the precedent that has been set is that when
a neighbour hands us invalid attributes, we will send a NOTIFICATION. The root
of the problems with rfc4893 are that we implemented this behaviour to an OLD
speaker that, from its perspective, was propagating completely valid attributes.
I would appreciate some feedback on whether rfc4893 should introduce
'permissive' behaviour, where invalid attributes are discarded, and we attempt
to workaround the lack of them -- or whether we should still penalise the
invalid attribute by treating this UPDATE as WITHDRAW.

Please let me know if I've made any errors in this analysis -- I'd like to try
and ensure that we're taking the best way forward with this RFC, and don't 
react to an observed issue by becoming overly permissive of badly implemented
BGP speakers.

Many thanks in advance for your comments.

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