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

[Enke Chen <enkechen at cisco.com>]

Rob,

Rob Shakir wrote:
> On Mon, Jan 26, 2009 at 05:08:01PM -0800, Enke Chen wrote:
>   
> > The particular error involves "over supply of information" which can be  
> > repaired by removing the unnecessary information. At the risk of  
> > repeating myself, this is a recoverable, non-fatal error. The  
> > time-tested principle of "be liberal in what you accept" is precisely  
> > for dealing with this kind of non-fatal errors in protocol design.
> >     
>
> We do not agree with your statement that this is "over supply of 
> information" as an AS_CONFED_SET/SEQUENCE is garbage data outside of the 
> network making use of confederations, and infact it could be considered 
> harmful misinformation if the neighbouring network also makes use of 
> confederations.
>
> We do, however, agree that your suggested method for handling the 
> presence of an AS_CONFED_SET/SEQUENCE is suitable for dealing with this 
> specific bug, and comparatively easy to implement. Fom an operational 
> perspective, this is also probably the best way to deal with the 
> specific case since there are a large number of JunOS devices deployed 
> that may to continue to insert AS_CONFED_SET/SEQUENCE into AS4_PATH in 
> the future.
>
> We therefore accept the new handling of this specific error condition as 
> being a necessary evil.
>   

Good.

> Section 6 of the new draft defines handling for a general error case 
> with behaviour that we do not believe is safe. Considering that the 
> AS4_PATH is mechanism for transporting unsupported AS_PATH information 
> through a number of AS4-unaware devices we must bear in mind that there 
> is a reconciliation process with AS_PATH. Given the role of AS_PATH in 
> loop prevention we feel that general lax treatment of AS4_PATH may have 
> harmful concequences in the future.
>
> We feel that the general behaviour on an error should be the withdrawal 
> of the path, as discarding the attribute is equivalent in effect to 
> discarding part of the AS_PATH and may cause loops. 

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.

In the case of a malform AS4_PATH attribute,  rejecting the route would 
also result in the loss of connectivity, and thus can also be used as a 
remote attack vehicle.

Considering the following factors:

    1) the tradeoffs,
    2) especially the concern for the remote attack,
    3) AS4_PATH being optional,

I believe that what is proposed in the draft (accepting the routes) is 
more preferred than rejecting the route.

Admittedly, a malformed AS4_PATH attribute would fall into the category 
of inconsistency and would subject to the risks described in the document:

---------------------------------------------------------------------------------------
9. Security Considerations

  The inconsistency between the AS_PATH attribute and the AS4_PATH
  attribute can create loss of the AS path information, and potential
  routing loops in certain cases as discussed in the document.  This
  could be exploited by an attacker.
---------------------------------------------------------------------------------------

Regards,  -- Enke

> Option a and b are equivalent since the AS4_PATH attribute would not be 
> present if there wasn't an AS_TRANS in the AS_PATH.
>
> While your "be liberal in what you accept" approach is commendable, and 
> often an excellent idea, a line does need to be drawn. We cannot and 
> should not extend the standards with special cases every time someone 
> makes an implementation error or we risk creating an RFC that's almost 
> impossible to implement without making further silly mistakes.
>
> Kind regards,
> 	Jonathan Oddy (Hostway UK)
> 	Rob Shakir (GX Networks)
>   

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