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

From: Enke Chen <[email-masked]>
Date: Sat, 24 Jan 2009 13:19:08 -0800

Hi, folks:

The changes from RFC 4893 are summarized in the Appendix of the draft:

      This document clarifies the handling of the confederation path
      segments in the AS4_PATH attribute, and also specifies the error
      handling for the new attributes.

The following are the specific additions:

-----------------------
3. Protocol Extensions

 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.

6. Error Handling

 When a NEW BGP speaker encounters an error (other than the invalid
 confederation path segment types described previously) in parsing the
 AS4_PATH attribute or the AS4_AGGREGATOR attribute of an UPDATE
 message, the speaker MUST discard the attribute in error, and
 continue processing the UPDATE message. The error SHOULD be logged
 locally for analysis.

9. Security Considerations

 It is a misconfiguration to assign a non-mappable 4-octet AS number
 as the "Member AS Number" in a BGP confederation before all the BGP
 speakers within the confederation have transitioned to support 4-
 octet AS numbers. Such a misconfiguration would weaken the AS path
 loop detection within a confederation.
-----------------------------

Your comments are welcome and appreciated.

Thanks.  -- Enke

Subject: I-D Action:draft-chen-rfc4893bis-00.txt
From: [email-masked]
To: [email-masked]
Date: Sat, 24 Jan 2009 13:00:01 -0800 (PST)
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : BGP Support for Four-octet AS Number Space
	Author(s)       : Q. Vohra, E. Chen
	Filename        : draft-chen-rfc4893bis-00.txt
	Pages           : 10
	Date            : 2009-01-24

Currently the Autonomous System (AS) number is encoded as a two-octet
entity in BGP. This document describes extensions to BGP to carry the
Autonomous System number as a four-octet entity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-rfc4893bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Rob Shakir <[email-masked]>
Date: Mon, 26 Jan 2009 18:48:50 +0000

> processing the UPDATE message.

Enke,

Thanks for following up on this matter.

I appreciate that stripping the confederation data from AS4_PATH does deal with
the problem of a neighbour resetting sessions due to an invalid optional
transitive attribute, I am not entirely convinced that it is the best way to
handle invalid data in AS4_PATH.

I understand from the current RFC that if we have a broken set of paths where
the AS4_PATH contains a conferation sequence, but this information has been
stripped from the AS_PATH and replaced with the confederation identifier, then
we will retain loop-prevention (due to the fact that the confed ID will be one
of the AS numbers that is prepended to the AS_PATH during AS4_PATH-AS_PATH
reconciliation).  Hence, by not discarding the update, and merely stripping the
invalid data then we do keep the required underlying functionality.

However, this does introduce some complexity into the implementation of this
standard, we must ensure to strip the correct elements from the AS4_PATH. Whilst
this should not be a matter of great importance - some implementors do not
produce standards-compliant behaviour (see the cause of the session resets that
we observed when connecting to the global table). I am interested to hear
whether you envisage problems being caused by incorrect data being stripped from
the AS4_PATH and hence result in routing information (which was present) being
lost? One possibility of this would be in AS_SET and AS_SEQUENCE being stripped
from the AS4_PATH (a feasible bug in an implementation of this new behaviour).

The other concern that I have is that if some BGP neighbour does not implement
the standard correctly, to what extent can the routing information produced by
and propagated through this neighbour be trusted? One of the advantages of the
approach that we suggested on the IDR list, in my eyes, was the fact that when
routing information is 'corrupted' by the insertion of invalid data into an
attribute, the receiver chooses to not use this routing data.  Operationally, I
feel that this behaviour is advantageous, since those paths that contain
incorrect information have a penalty placed against them.

> continue processing the UPDATE message. The error SHOULD be logged

I appreciate this addition. Given this error, and the possibility for further
problems, there is definitely a requirement for a well defined method of dealing
with errors during the transition to 4-byte AS numbers, where these optional
transitive elements have the possibility to propagate far from the source
without any validation.

I would be very interested in your comments as to why it is felt that stripping
the invalid elements from the AS4_PATH attribute is a better solution than the
alternative we proposed to the IDR list last week.

Kind regards,
Rob

--
Rob Shakir                      <[email-masked]>
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
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Enke Chen <[email-masked]>
Date: Mon, 26 Jan 2009 15:15:20 -0800

Hi, Rob:

Please see my comments inlined.

> from the AS4_PATH (a feasible bug in an implementation of this new behaviour).

Stripping the confed path segments is pretty straightforward.  IMO an 
implementation that can deal with the merge of AS_PATH and AS4_PATH 
should have no difficult in implementing the stripping.

> incorrect information have a penalty placed against them.

This seems to be a perfect case to follow the time-tested principle "Be 
liberal in what you accept".  It is a recoverable, non-fatal error.  
There is no need to use any disruptive procedures.

> transitive elements have the possibility to propagate far from the source

Thanks.  That is exactly the objective of the new section.

> alternative we proposed to the IDR list last week.

Here is an excerpt of your proposal posted to the IDR mailing list last 
week:

-----------------------------------

There are two cases to consider when an invalid AS4_PATH is received:
   (1) A path to the prefix is not already known from that neighbour. 
   (2) A path to the prefix has already been learnt from that neighbour; 
   
In case (1) we recommend that the BGP speaker should discard the UPDATE and log
the fact. The log entry should include the received AS_PATH and
AS4_PATH to aid in debugging.

In case (2) we recommend that the BGP speaker should treat the UPDATE as a
withdrawal of existing path to the prefix. As per case (1) a log entry should be
raised to indicate that this has occurred.

------------------------------------

The proposal for (1) is incorrect from the protocol aspect.  As BGP 
update is incremental, we can not just hold on to the old info and 
discard the new info.

The proposal for (2) is ok from the *pure* protocol aspect, but it would 
cause unnecessary disruption (i.e., loss of connectivity) for this 
recoverable, non-fatal error.

Thanks.   -- Enke

---

From: Rob Shakir <[email-masked]>
Date: Tue, 27 Jan 2009 00:49:55 +0000

Hi Enke,

Thanks for your reply.

> should have no difficult in implementing the stripping.

I concur that stripping the confed path segments should be straight-forward, but
I feel that considering the bugs that could be feasibly introduced through the
implementation of a new standard is valuable. After all, one could say that 4893
was very clear in terms of forbidding AS_CONFED_SET/SEQUENCE from AS4_PATH, yet
as we have seen here, not all implementations obeyed this.

> Here is an excerpt of your proposal posted to the IDR mailing list last  

In the case of (1), there is no old information to hold onto. (1) handles the
case whereby a neighbour hands us a new prefix. At the time we receive this
prefix, we have no path in any RIB that would provide us reachability to the
prefix via that neighbour. Hence, when we parse the UPDATE message and find that
there is an invalid AS4_PATH in it, we choose to not treat this path as valid,
and not add it to any RIB. This ties back to my previous comment that we should
perhaps penalise those paths to prefixes which contain invalid routing
information.

Combining your comments on (2), and earlier comments - one can be liberal in
terms of accepting any prefix to a neighbour, however, if we have a 4-byte ASN
in the path that is manipulating routing data that is important to it (i.e.
AS4_PATH) incorrectly, should we not treat this as we treat invalid data in the
AS_PATH? I believe our suggested approach (treating the UPDATE as WITHDRAWL) is
closer to how rfc4893 currently deals with the invalid data, but takes into
account the optional transitive nature of AS4_PATH.  Is the intended behaviour
to be permissive in handling invalid AS4_PATH data where we are not so with
AS_PATH? It is worth considering that the loss of connectivity is only to a
prefix that has no valid method of propagating itself via RFC-compliant BGP
speakers.

Kind regards,
Rob

---

From: Enke Chen <[email-masked]>
Date: Mon, 26 Jan 2009 17:08:01 -0800

Hi, Rob:

> perhaps penalise those paths to prefixes which contain invalid routing

Apologies that I did not read your message carefully (missed "not").

Then (1) and (2) is really the same - treat the update as a withdraw.

> prefix that has no valid method of propagating itself via RFC-compliant BGP

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.

Thanks. -- Enke

---

From: Enke Chen <[email-masked]>
Date: Mon, 26 Jan 2009 17:23:09 -0800

Rob,

Regarding your comment:

----------------------------------------
It is worth considering that the loss of connectivity is only to a 
prefix that has no valid method of propagating itself via RFC-compliant 
BGP speakers.
-----------------------------------------

The loss of connectivity (with your proposal) could be for all the 
prefixes exchanged over a session, in which case your proposal would 
have virtually identical effect as tearing down a session, and that is 
something we try to prevent with the current work.

Regards,   -- Enke

Enke Chen wrote:
>>> Stripping the confed path segments is pretty straightforward.  IMO 
>>> an  implementation that can deal with the merge of AS_PATH and 
>>> AS4_PATH  should have no difficult in implementing the stripping.
>>>     
>>
>>> Here is an excerpt of your proposal posted to the IDR mailing list 
>>> last  week:
>>>
>>>   (1) A path to the prefix is not already known from that 
>>> neighbour.   (2) A path to the prefix has already been learnt from 
>>> that neighbour;    In case (1) we recommend that the BGP speaker 
>>> should discard the UPDATE and log
>>> The proposal for (2) is ok from the *pure* protocol aspect, but it 
>>> would  cause unnecessary disruption (i.e., loss of connectivity) for 
>>> this  recoverable, non-fatal error.
>>>     
>>
> The particular error involves "over supply of information" which can 
> be repaired by removing the unnecessary information. At the risk of

---

From: Rob Shakir <[email-masked]>
Date: Tue, 27 Jan 2009 16:52:15 +0000

> 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.

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. 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.
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
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: John Leslie <[email-masked]>
Date: Tue, 27 Jan 2009 12:38:40 -0500

Rob Shakir <[email-masked]> wrote:
> 
> 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:

   Agreed.

> present if there wasn't an AS_TRANS in the AS_PATH.

   Actually, no.

   Option (a) removes any possibility that you're propagating the error,
at the possible expense of losing reachability to the CIDR block.

   Option (b) removes the possibility of a loop, keeping reachability
in most cases; but does not protects BGP speakers you may pass this
NLRI to.

   The possibility of losing reachability in option (a) is unfortunately
significant, because any NEW speaker receiving this NLRI from your OLD
neighbor will likewise discard it. Note particularly that the OLD speaker
has done nothing wrong (unless you call failure to upgrade it to a NEW
speaker) and that the NLRI you received is its honest "best" route.

   I prefer imlementing option (b) independently of what we do with an
erroneous AS4_PATH, largely because I doubt we can catch all the cases
where a bug may cause AS_TRANS to show up in a (possibly reconstructed)
NLRI.

--
John Leslie <[email-masked]>
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 27 Jan 2009 14:58:13 -0400

> speaker cannot know if its AS number was in the path. The only loop  

While intuitively obvious, this isn't correct.  As long as there's no  
corresponding damage to the AS_PATH, the loop free property is  
preserved.  Here's the argument:

On Dec 17, 2008, at 11:52 AM, John G. Scudder wrote:
> On Dec 17, 2008, at 3:13 AM, Paul Jakma wrote:
>> On Tue, 16 Dec 2008, John G. Scudder wrote:
>>
>>> 1. All the ASes in the path are 4-byte capable, in which case the  
>>> issue does not exist.
>>> 2. At least one AS in the path is not 4-byte capable. In that  
>>> case, if there is a loop it will eventually be caught by the  
>>> regular 2-byte AS_PATH.
>>>
>>> In neither case is what you describe needed, AFAICT.
>>
>> We're talking about the case where the AS4_PATH has been removed by  
>> a preceding NEW speaker though.
>>
>> Your 2 seems to suggest that in such paths, loop-detection should  
>> only be done by the OLD speakers (and NEW speakers preceding it may  
>> happily install the path).
>
> That's more or less correct, modulo the adverb :-).  The point is  
> that as long as the loop gets broken, regardless of by whom (in this  
> case the OLD speaker preceding the NEW speaker which removed the  
> AS4_PATH), it will proceed to unwind.  That is to say, it's only a  
> transient loop.
>
> Keep in mind this behavior SHOULD never be seen in the wild since  
> it's predicated on broken behavior along the path someplace to begin  
> with; with luck this is just a chalkboard exercise.  I for one find  
> it heartening that the protocol appears to be robust even in the  
> face of certain types of mangling of the AS4_PATH.

One may still debate whether it's preferable to "fix" the broken route  
by dropping the AS4_PATH or treat the broken route as a withdraw  
(which as you point out is effectively what your options a+b are), but  
if the latter is chosen it should be for some reason other than "may  
cause loops".

--John

---

From: Enke Chen <[email-masked]>
Date: Tue, 27 Jan 2009 11:18:01 -0800

Rob,

> We therefore accept the new handling of this specific error condition as 

Good.

> 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 

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

---

From: David Freedman <[email-masked]>
Date: Tue, 27 Jan 2009 19:39:53 +0000

> also result in the loss of connectivity, and thus can also be used as a

Yes, but the attack would be constrained to all prefixes with the
malformed AS4_PATH attribute and not all prefixes received over the session.

> more preferred than rejecting the route.

How about not making it mandatory to accept it?

Dave.

---

From: Enke Chen <[email-masked]>
Date: Tue, 27 Jan 2009 11:49:41 -0800

David,

> malformed AS4_PATH attribute and not all prefixes received over the session.

All the prefixes could have the malformed AS4_PATH attribute (from a 
remote router).  In that case, rejecting the routes has the same effect 
as tearing down the session.

> How about not making it mandatory to accept it?

I am concerned about it.  Please see the above comment.

Regards,   -- Enke

---

From: David Freedman <[email-masked]>
Date: Tue, 27 Jan 2009 20:20:07 +0000

> as tearing down the session.

You are correct that, in the tradeoff scenario we sever connectivity to
the prefix, but the implications of this "in the wild" are not as
worrying since a malicious network attempting to cause a user's
disconnection to his upstream through mass prefix advertisement is made
significantly more difficult due to the nature of both the network and
BGP's bestpath selection algorithm.

>by dropping the AS4_PATH or treat the broken route as a withdraw (which
>as you point out is effectively what your options a+b are), but if the
>latter is chosen it should be for some reason other than "may cause
>loops".

I'd like to see the "withdraw if you have something to withdraw or
simply don't accept" such that everybody converges to a consistent view
and we don't end up with having a patchwork of attributes recorded for a
prefix, some with and some without an AS4_PATH (depending on who is
doing what).

Dave.

---

From: Rob Shakir <[email-masked]>
Date: Tue, 27 Jan 2009 21:37:29 +0000

On Tue, Jan 27, 2009 at 11:18:01AM -0800, Enke Chen wrote:
>> 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:

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

---

From: Paul Jakma <[email-masked]>
Date: Thu, 29 Jan 2009 05:59:52 +0000 (GMT)

On Tue, 27 Jan 2009, John G. Scudder wrote:

> corresponding damage to the AS_PATH, the loop free property is preserved. 
> Here's the argument:

That's an argument as to why it doesn't break down completely if 
everything else is working in spec, which is indeed a nice property. 
I'm still puzzled as how this is an argument to not restore AS-path 
checking back to its full-strength.

- It's not robust if two OLD speakers in a cycle each remove the
   other's ASN, with the remaining speakers on the cycle all being
   NEW.

- It's not robust in a cycle of all NEW speakers where one session,
   for some reason, is both OLD and causes the AS4_PATH to be ignored.

I really don't see what benefits there are to leave loop-detection 
degraded in this way in a mixed world.

But hey..

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Extremism in the defense of liberty is no vice... moderation in the pursuit
of justice is no virtue.
 		-- Barry Goldwater
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr