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

From: Enke Chen <[email-masked]>
Date: Mon, 02 Feb 2009 11:16:46 -0800

Hi, folks:

The revised version includes the following changes from the -00.txt version:

   o The Error Handling section has been enhanced, with the error conditions
      for the new attributes spelled out.

   o Several "SHOULD NOT" are changed to "MUST NOT".

The diff is attached.

Thanks.   -- Enke

-------- Original Message --------
Subject: 	I-D Action:draft-chen-rfc4893bis-01.txt
Date: 	Mon, 2 Feb 2009 11:00:01 -0800 (PST)
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

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-01.txt
	Pages           : 11
	Date            : 2009-02-02

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

*** 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
***************
*** 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
***************
*** 225,231 ****
     AS numbers.  The NEW speaker MUST also send the AS path information
     in the AS4_PATH attribute (encoded with 4-octet AS numbers), except
     for the case where the entire AS path information is composed of 2-
!    octet AS numbers only.  In this case, the NEW speaker SHOULD NOT send
     the AS4_PATH attribute.
  
     In the AS_PATH attribute encoded with 2-octet AS numbers, non-
--- 225,231 ----
     AS numbers.  The NEW speaker MUST also send the AS path information
     in the AS4_PATH attribute (encoded with 4-octet AS numbers), except
     for the case where the entire AS path information is composed of 2-
!    octet AS numbers only.  In this case, the NEW speaker MUST NOT send
     the AS4_PATH attribute.
  
     In the AS_PATH attribute encoded with 2-octet AS numbers, non-
***************
*** 264,270 ****
     value of the AS4_AGGREGATOR attribute, and sets the AS number field
     in the existing AGGREGATOR attribute to the reserved AS number,
     AS_TRANS.  Note that if the AS number is 2-octets only, then the
!    AS4_AGGREGATOR attribute SHOULD NOT be sent.

  4.2.3. Processing Received Updates
--- 264,270 ----
     value of the AS4_AGGREGATOR attribute, and sets the AS number field
     in the existing AGGREGATOR attribute to the reserved AS number,
     AS_TRANS.  Note that if the AS number is 2-octets only, then the
!    AS4_AGGREGATOR attribute MUST NOT be sent.

  4.2.3. Processing Received Updates
***************
*** 372,390 ****
     As specified in [RFC1997], when the high-order two-octets of the
     community attribute is neither 0x0000 nor 0xffff, these two octets
     encode the Autonomous System number.  Quite clearly this would not
!    work for BGP speakers that use 4-octets Autonomous System numbers.
     Such BGP speakers should use the Four-octet AS Specific Extended
     Communities [AS-EXT-COM] instead.

  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.

  7. Transition
--- 369,441 ----
     As specified in [RFC1997], when the high-order two-octets of the
     community attribute is neither 0x0000 nor 0xffff, these two octets
     encode the Autonomous System number.  Quite clearly this would not
!    work for a NEW BGP speaker with a non-mappable 4-octet AS number.
     Such BGP speakers should use the Four-octet AS Specific Extended
     Communities [AS-EXT-COM] instead.

  6. Error Handling
  
!    The AS4_PATH attribute in an UPDATE message is considered malformed
!    under the following conditions:
! 
!       - the attribute type appears more than once in the UPDATE
!         message, or
! 
!       - the attribute is not marked "optional and transitive", or
! 
!       - the attribute length is inconsistent with the "Total Path
!         Attribute Length" in the UPDATE message, or
! 
!       - the path segment length in the attribute is either zero, or
!         is inconsistent with the attribute length, or
! 
!       - the path segment type in the attribute is not one of the
!         types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE
!         and AS_CONFED_SET.
! 
!    A NEW BGP speaker that receives a malformed AS4_PATH attribute in an
!    UPDATE message from an OLD BGP speaker MUST discard the attribute,
!    and continue processing the UPDATE message.  The error SHOULD be
!    logged locally for analysis.
! 
!    In addition, 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.  A NEW BGP
!    speaker that receives these path segment types in the AS4_PATH
!    attribute of an UPDATE message from an OLD BGP speaker MUST discard
!    these path segments, adjust the relevant attribute fields
!    accordingly, and continue processing the UPDATE message.
! 
!    The AS4_AGGREGATOR attribute in an UPDATE message is considered
!    malformed under the following conditions:
! 
!       - the attribute type appears more than once in the UPDATE
!         message, or
! 
!       - the attribute is not marked "optional and transitive", or
! 
!       - the attribute length is of a value other than 8, or
! 
!       - the AS number in the attribute is zero, or
! 
!       - the BGP Identifier in the attribute is zero.
! 
!    A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute
!    in an UPDATE message from an OLD BGP speaker MUST discard the
!    attribute, and continue processing the UPDATE message.  The error
!    SHOULD be logged locally for analysis.

  7. Transition

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

---

From: Rob Shakir <[email-masked]>
Date: Wed, 4 Feb 2009 11:33:50 +0000

Enke,

Please see comments in-line to this diff.

> --- draft-chen-rfc4893bis-01.txt	Mon Feb  2 09:34:53 2009

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. 

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

---

From: John Leslie <[email-masked]>
Date: Wed, 4 Feb 2009 09:54:03 -0500

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

   This is actually two different cases:

1) we have an ASN > 65535, so this indeed might _be_ a loop;

2) we don't have an ASN > 65535, but we don't trust other ASs to perform
   this loop-prevention algorithm.

   For either of these, treating AS_TRANS as matching our ASN is the only
sure loop-prevention method.

> As someone commented to me off-list, loops are very destructive, and
> we should try to avoid them at almost any cost --

   If a routing loop actually happens, packets must travel the loop until
TTL is exhausted. TTL, alas, is set to 255 fairly often...

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

   I'm not sure we're keeping a clear distinction between routes actually
used propagated to a NEW speaker from an OLD speaker and AS4 information
which the OLD speaker was totally unaware of.

   (If we were keeping such a clear distinction, it's hard to believe we
would continue to insist upon blindly substituting the latter for the
former.)

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

   Obviously true...

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

   There is an unavoidable tradeoff between the possibilities of looping
vs. unreachability. :^(

> 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

   IMHO, doing this is better, because the problem can be detected a
single hop after the manipulation done by the OLD speaker (assuming it
has at least one NEW peer). At some point, OLD speakers need to be
discouraged from doing such manipulations.

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

   This never was a good idea for transitive attributes that the
neighbor has made no attempt to validate.

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

   Or, more exactly, propagating as _required_ by the spec.

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

   I see it as inherently dangerous to discard an attribute and assume
we can "workaround" its absence without possibly creating a loop.

   But the balancing act remains...

   If we believe the risk of loops to be negligible, we could reasonably
concentrate on the risk of unreachability. For myself, I'm afraid I
don't consider the risk of loops as "negligible".

> Please let me know if I've made any errors in this analysis --

   I believe Rob's analysis is correct.

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

   I wouldn't even call them "badly implemented". Our observed problem
probably stems from pre-4893 implementations which were correct when
coded. _My_ biggest worry is that we end up with a 4893bis which is
amenable to differing implementations -- and I'm seriously worried that
we're heading in that direction. Left to myself, I'd step back and
design a transition scheme from scratch, considering the tradeoff
between looping and unreachability, before publishing a quick-fix.

   YMMV, of course...

--
John Leslie <[email-masked]>

---

From: Paul Jakma <[email-masked]>
Date: Mon, 9 Feb 2009 18:21:45 +0000 (GMT)

On Wed, 4 Feb 2009, Rob Shakir wrote:

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

This was suggested already. However it seems there is no need for 
this as, on any cycle, there should be at least one OLD speaker that 
will see its own, non-AS_TRANS, ASN and stop the loop. (See, e.g., 
emails from John Scudder).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Kilroe hic erat!