Subject: [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt

From: Enke Chen <[email-masked]>
Date: Wed, 08 Sep 2010 14:29:16 -0700

Hi, folks:

The draft attempts to improve the error handling, as discussed in the 
introduction:

    Our goal is to minimize the scope of the network that is affected by
    a malformed UPDATE message, and also to limit the impact to only the
    routes involved.  The constrain is that the protocol correctness must
    not be violated.

Will appreciate your comments.

Thanks.   -- Enke

-------- Original Message --------
Subject: 	I-D Action:draft-chen-ebgp-error-handling-00.txt
Date: 	Wed, 8 Sep 2010 14:15:02 -0700 (PDT)
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

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

	Title           : Revised Error Handling for BGP Updates from External Neighbors
	Author(s)       : E. Chen, et al.
	Filename        : draft-chen-ebgp-error-handling-00.txt
	Pages           : 6
	Date            : 2010-09-08

In this document we partially revise the error handling of an UPDATE
message from an external BGP neighbor.  The essence of the revision
is to avoid resetting an external BGP session by using the "treat-
as-withdraw" approach when the whole NLRI field of a malformed UPDATE
message can be parsed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-ebgp-error-handling-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.

---

From: "Bhau, Nehal (Nehal)" <[email-masked]>
Date: Wed, 8 Sep 2010 17:06:42 -0500

Hi Enke,

I have one question/comment on section 3 (Parsing of NLRI fields)

   Traditionally the NLRIs for the IPv4 unicast address family are
   carried immediately following all the attributes in an UPDATE
   [RFC4271].  When such an UPDATE is received, we observe that the NLRI
   field can be determined using the "Message Length" and the "Total
   Attribute Length" (when they are consistent) carried in the message
   instead of relying on the length of individual attributes in the
   message.

Do you think some text needs to be added to clarify the case when total attribute length > sum of all individual attributes ? In such case there is no reliable way to parse IPv4 NLRIs. Hence, "treat-as-withdraw" approach would not be applicable ?

Thanks,

-Nehal

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Enke Chen
Sent: Wednesday, September 08, 2010 2:29 PM
To: [email-masked]
Cc: Keyur Patel
Subject: [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt

Hi, folks:

The draft attempts to improve the error handling, as discussed in the introduction:

Thanks.   -- Enke

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 8 Sep 2010 19:29:01 -0400

When the length field of something is wrong, it is just guesswork
to determine which length is wrong.

For example if the length field of an unknown transitive
attribute is shorter than the actual attribute, the parsing
error will occur after that attribute is (thought to be)
read in. The subsequent bytes will be interpreted as the next
attribute.

The same parsing error would occur if the total attribute
length was too long. How would you tell the difference?
How could you be sure where the NLRI actually started
in order to withdraw the correct NLRI?

The problem is not enough redundancy in the update message.

To help, I would like to propose a "magic number" attribute.
This would contain some constant bit pattern, like "0xAA55"
and the remaining length of the update message. I propose that
this attribute be added as the last attribute in the attribute
list. It may also be added elsewhere for more redundancy, perhaps
right after the MP_(UN)REACH.

If an error is detected in a received update message, the parser
could look for this magic number and verify that the accompanying
length matched with what it thought other lengths should be.
It can also look for the 16 0xFF's to help synchronize.

--
Jakob Heitz.

Hi, folks:

Thanks.   -- Enke

---

From: Jie Dong <[email-masked]>
Date: Thu, 09 Sep 2010 09:51:05 +0800

Hi Enke,

One quick comment...

Sec 3, paragraph 3: “When such an UPDATE is received, we observe that the
NLRI field can be determined using the "Message Length" and the "Total
Attribute Length" (when they are consistent) carried in the message instead
of relying on the length of individual attributes in the message.”

The "Withdrawn Routes Length" also needs to be used in determination of NLRI
field.

Best regards,
Jie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Enke
Chen
Sent: Thursday, September 09, 2010 5:29 AM
To: [email-masked]
Cc: Keyur Patel
Subject: [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt

Hi, folks:

Thanks.   -- Enke

-------- Original Message -------- 
Subject: 
I-D Action:draft-chen-ebgp-error-handling-00.txt
Date: 
Wed, 8 Sep 2010 14:15:02 -0700 (PDT)
From: 
[email-masked]
Reply-To: 
[email-masked]
To: 
[email-masked]

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

	Title           : Revised Error Handling for BGP Updates from
External Neighbors
	Author(s)       : E. Chen, et al.
	Filename        : draft-chen-ebgp-error-handling-00.txt
	Pages           : 6
	Date            : 2010-09-08

---

From: Enke Chen <[email-masked]>
Date: Wed, 08 Sep 2010 21:07:31 -0700

Jie,

Certainly. Will take care of it in the next revision.

Thanks. -- Enke

---

From: Enke Chen <[email-masked]>
Date: Wed, 08 Sep 2010 21:13:41 -0700

Hi, Nehal:

In parsing an UPDATE message, the receiver would not be able to detect 
the case you described ("Total Attribute Length" > "sum of all 
individual attributes") because the "Total Attribute Length" is used to 
loop through all the attributes in the message.  To reach the ipv4 
unicast NLRI field, we can rely on the message length, withdraw length 
and the Total Attribute Length as long as these lengths are consistent.

Thanks.   -- Enke

On 9/8/10 3:06 PM, Bhau, Nehal (Nehal) wrote:
> /    Traditionally the NLRIs for the IPv4 unicast address family are
>     message./
> Do you think some text needs to be added to clarify the case when total attribute length>  sum of all individual attributes ? In such case there is no reliable way to parse IPv4 NLRIs. Hence,"treat-as-withdraw" approach would not be applicable ?
> Thanks,
> -Nehal
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Enke Chen
> *Sent:* Wednesday, September 08, 2010 2:29 PM
> *To:* [email-masked]
> *Cc:* Keyur Patel
> *Subject:* [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt
>
> Hi, folks:
>

---

From: Enke Chen <[email-masked]>
Date: Wed, 08 Sep 2010 21:33:55 -0700

Hi, Jakob:

> read in. The subsequent bytes will be interpreted as the next

Other than comparing the attribute length with the remaining bytes of 
the "Total attribute length", the receiver has no other way to validate 
the length of an unrecognized transitive attribute.  This draft does not 
change that.
> in order to withdraw the correct NLRI?

If the "Total Attribute Length" is too large,  the session will be reset 
(as specified in RFC 4271, and is unchanged by the draft):

    The error handling of the following case described in Section 6.3 of
    [RFC4271] remains unchanged:

       If the Withdrawn Routes Length or Total Attribute Length
       is too large (i.e., if Withdrawn Routes Length + Total Attribute
       Length + 23 exceeds the message Length), then the Error Subcode
       MUST be set to Malformed Attribute List.

As Tony pointed out, we do have the "sync header" in messages.  In 
addition, the approach of "treat-as-withdraw" requires the complete 
parsing of the NLRI field, which may not be possible in a variety of 
error conditions.

-- Enke

>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Enke Chen

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 9 Sep 2010 01:16:05 -0400

Hi Enke,

Thanks for replying.

Sorry, I wasn't specific enough: I meant the total
attribute length is longer than the sum of the attributes in it,
but still short enough to fall within the total message length.
Then the NLRI section will be interpreted as being later into
the message than it actually is. The parser will either misinterpret
the NLRI, miss the first few or most likely get a parsing
error, because a bitlength will be parsed as larger than 32.

If the total attribute length was mistakenly shorter, then the
NLRI section will be interpreted as starting sooner in the message
than it actually is and the end of the attribute list will be interpreted
as NLRI. Again, a bitlength could be larger than 32 and an
NLRI parsing error would result.

Suppose an NLRI parsing error does not result, unlikely I concede,
you will withdraw incorrect prefixes.

Since we are trying to build resilience into BGP, I figured
that a little extra redundancy in the message could help.

Thus my suggestion for the magic number attribute. It would
also help to analyze the malformed message. It seems like
an easy thing to do, not requiring a new capability.

There are probably other ways to build error recovery or
error resilience into the message, but this one is the first
I could think of.

--
Jakob Heitz.

________________________________
From: Enke Chen [mailto:[email-masked]]
Sent: Wednesday, September 08, 2010 9:34 PM
To: Jakob Heitz
Cc: [email-masked]; Enke Chen
Subject: Re: [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt

Hi, Jakob:

Other than comparing the attribute length with the remaining bytes of the "Total attribute length", the receiver has no other way to validate the length of an unrecognized transitive attribute.  This draft does not change that.

If the "Total Attribute Length" is too large,  the session will be reset (as specified in RFC 4271, and is unchanged by the draft):

As Tony pointed out, we do have the "sync header" in messages.  In addition, the approach of "treat-as-withdraw" requires the complete parsing of the NLRI field, which may not be possible in a variety of error conditions.

-- Enke

--
Jakob Heitz.

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Enke Chen
Sent: Wednesday, September 08, 2010 2:29 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Keyur Patel
Subject: [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt

Hi, folks:

Thanks.   -- Enke

---

From: "Neil J. McRae" <[email-masked]>
Date: Thu, 9 Sep 2010 14:45:28 +0100 (BST)

Enke,
This is a fantastic step forward and as an network operator I am very very
pleased (perhaps even delighted) to see Cisco acting on this issue,
however I don't believe you are ambitious enough!

This sort of fix needs to be applied to both _internal_ and external BGP
updates, is it possible to update the draft to include this?

Best Regards,
Neil.

On Wed, September 8, 2010 22:29, Enke Chen wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

--
Neil J. McRae -- Alive and Kicking.
[email-masked]

---

From: Tony Li <[email-masked]>
Date: Thu, 9 Sep 2010 08:06:44 -0700

Neil,

If applied to iBGP, then you effectively would end up with one speaker filtering routes in a manner that was inconsistent with the rest of the AS.  This would lead to inconsistent RIBs and thus forwarding loops.

Regards,
Tony

---

From: Mach Chen <[email-masked]>
Date: Fri, 10 Sep 2010 17:02:06 +0800

Hi Enke,

One comment...

With this improved error handling, since the session will not be teared down 
and the notification messages will not be sent to the peer, should there are 
some other mechanisms (e.g., define a new Notification message that will not 
tear down the session, or using BGP advisory) to notify the peer the errors?

Best regards,
Mach

--------------------------------------------------
From: "Enke Chen" <[email-masked]>
Sent: Thursday, September 09, 2010 5:29 AM
To: <[email-masked]>
Cc: "Keyur Patel" <[email-masked]>
Subject: [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Sep 2010 13:36:55 +0200

Hi Mach,

Just to let you know that we have a mechanism which will exactly address 
your concern. It will be published soon.

Many thx,
R.

> Hi Enke,
>
> One comment...
>
> With this improved error handling, since the session will not be teared
> down and the notification messages will not be sent to the peer, should
> there are some other mechanisms (e.g., define a new Notification message
> that will not tear down the session, or using BGP advisory) to notify
> the peer the errors?
>
> Best regards,
> Mach
>

---

From: "Simpson, Adam (Adam)" <[email-masked]>
Date: Mon, 13 Sep 2010 21:52:04 -0500

Enke,

It seems that you intend for the mechanisms proposed in this draft (draft-chen) to be co-existent with the revised error handling procedures outlined in draft-ietf-idr-optional-transitive (opt-trans). If this is indeed the case there are some overlap cases that need further explanation in one of the two drafts (or both). Specifically -

 1.  What behavior is expected when an optional transitive attribute received in an Update from an EBGP peer is determined to be malformed and the P flag is clear or the NC flag is set? Are we to reset the session (per opt-trans) or treat as withdraw (per draft-chen)?

 1.  What behavior is expected when an optional transitive attribute received in an Update from an IBGP peer is determined to be malformed and the P flag is set and the NC flag is clear? Are we to reset the session (per draft-chen) or treat as withdraw (per opt-trans)? Of note here are the different viewpoints in the two drafts about applicability to IBGP sessions. Opt-trans notes the potential routing inconsistency problems that can result from applying the 'treat as withdraw' approach to Updates from IBGP peers but states that these may still represent the lesser evil. Draft-chen moves IBGP right out of scope due to these potential problems. It would be helpful if there was more consensus between the two drafts on this point.

Thanks for your efforts on this.

Adam

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Enke Chen
Sent: Wednesday, September 08, 2010 5:29 PM
To: [email-masked]
Cc: Keyur Patel
Subject: [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt

Hi, folks:

Thanks.   -- Enke

-------- Original Message --------
Subject:

Date:

From:

[email-masked]<mailto:[email-masked]>

Reply-To:

[email-masked]<mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]>

        Pages           : 6

        Date            : 2010-09-08

message can be parsed.

Internet-Draft.

---

From: Enke Chen <[email-masked]>
Date: Mon, 13 Sep 2010 21:32:13 -0700

Adam,

It is on the to-do list to reconcile the two drafts.  I will sync up 
with John, and we will take care of it soon.

Thanks.   -- Enke

On 9/13/10 7:52 PM, Simpson, Adam (Adam) wrote:
>
> Enke,
>
> It seems that you intend for the mechanisms proposed in this draft 
> (draft-chen) to be co-existent with the revised error handling 
> procedures outlined in draft-ietf-idr-optional-transitive (opt-trans). 
> If this is indeed the case there are some overlap cases that need 
> further explanation in one of the two drafts (or both). Specifically --
>
>    1. What behavior is expected when an optional transitive attribute
>       received in an Update from an EBGP peer is determined to be
>       malformed and the P flag is clear or the NC flag is set? Are we
>       to reset the session (per opt-trans) or treat as withdraw (per
>       draft-chen)?
>
>    2. What behavior is expected when an optional transitive attribute
>       received in an Update from an IBGP peer is determined to be
>       malformed and the P flag is set and the NC flag is clear? Are we
>       to reset the session (per draft-chen) or treat as withdraw (per
>       opt-trans)? Of note here are the different viewpoints in the two
>       drafts about applicability to IBGP sessions. Opt-trans notes the
>       potential routing inconsistency problems that can result from
>       applying the 'treat as withdraw' approach to Updates from IBGP
>       peers but states that these may still represent the lesser evil.
>       Draft-chen moves IBGP right out of scope due to these potential
>       problems. It would be helpful if there was more consensus
>       between the two drafts on this point.
>
> *Sent:* Wednesday, September 08, 2010 5:29 PM
> *To:* [email-masked]
> *Cc:* Keyur Patel
> *Subject: *
> *Date: *
> *From: *
> [email-masked] <mailto:[email-masked]>
>
> *Reply-To: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Rob Shakir <[email-masked]>
Date: Tue, 14 Sep 2010 08:15:03 +0100

> If applied to iBGP, then you effectively would end up with one speaker filtering routes in a manner that was inconsistent with the rest of the AS.  This would lead to inconsistent RIBs and thus for…

Hi Tony, Enke, Keyur,

First off -- thanks for your work on this draft, it is good to see the question of BGP error handling being further addressed.

Whilst there may be inconsistency in routing tables across an AS if this behaviour is implemented for iBGP, I think that the is some utility in not writing this off as something that is unacceptable from an operational perspective. What we are effectively saying is that we expect the most vulnerable BGP speaker within an AS is the one at the border, and hence we should make this speaker somewhat more robust. However, due to the nature of most eBGP deployments, it is very likely that:

a) This speaker carries a small number of AFI per session - one or two (typically, in my experience separate sessions are configured for IPv4/IPv6/IPv4 mcast etc).

b) There is a higher probability that the NLRI received on this session is a subset of the complete routing information the AS requires (this is likely true for PE-CE connectivity, and eBGP peering).

So, whilst these speakers may be most at risk of receiving BGP packets from some untrusted other ASN (be it a customer or a peer), the failure of them is somewhat lower impact than the failure of most iBGP sessions - which tend to carry multiple AFI, and the complete routing table for within an ASN.

Whilst I welcome further work to make BGP more robust to errors, in my opinion it would be  better if an approach that can be adopted for both eBGP and iBGP were developed - as this would ensure that there is less ambiguity about where such a mechanism can or should be implemented. 

I am trying to put together some documentation (in the form of a draft) around some the scenarios/error cases that any error handling revision within BGP needs to resolve, completely from a service provider perspective. It seems that there is limited information available about what a typical BGP deployment might look like within an ASN, where it has essentially replaced the IGP in a lot of cases. Does this sound like something that would be of use for further developing this draft?

I am also keen to understand what the extent of the 'protocol correctness' limitation is with this problem, from an implementor's perspective. It seems that this is where any BGP error handling revision will have some problems. Any UPDATE packet that contains some error also contains routing information, therefore in some cases we are likely to require that we discard some of this information, to be able to be more robust as a protocol. The line appears to have been drawn that this is acceptable for both optional transitive attributes, and for eBGP packets where only the NLRI can be determined - are there firm thoughts on where this might be for iBGP? At the moment, it appears "no error is acceptable" is the line that has been drawn here.

Many thanks for any input on this matter.

Kind regards,
Rob

---

From: Pradosh Mohapatra <[email-masked]>
Date: Tue, 14 Sep 2010 08:25:22 -0700

Hi Rob,

The draft already talks about IBGP in section 4:

   Depending on the network topology, the routing table, routes
   involved, and whether "tunnels" are used inside a network, the
   approach of "treat-as-withdraw" may work for internal BGP sessions
   only in some specific cases.  Thus it may be deployed for internal
   BGP sessions only as a temporary measure to stop continuous session
   flaps due to malformed UPDATE messages.  Such deployment must be
   carefully evaluated on a case-by-case basis.

- Pradosh

---

From: Rob Shakir <[email-masked]>
Date: Tue, 14 Sep 2010 16:41:49 +0100

>   carefully evaluated on a case-by-case basis.

Hi Pradosh,

Unfortunately, this isn't really a useful error handling however, since it basically recommends that one should not enable this mechanism for iBGP. In this case, we are left with the fact that we will continue to send NOTIFICATION for every error, and hence cause disproportionate failure modes.

The intent of my previous mail was to open a discussion around whether we can begin to progress some work (be it based on this draft or not) towards increasing the robustness of iBGP also. From my perspective, it would be better to have a single mechanism that can be deployed on either iBGP or eBGP safely, rather than disjoint behaviour.

Hopefully this is somewhat clearer.

Many thanks,
Rob

---

From: Tony Li <[email-masked]>
Date: Tue, 14 Sep 2010 09:52:55 -0700

Hi Rob,

> The intent of my previous mail was to open a discussion around whether we can begin to progress some work (be it based on this draft or not) towards increasing the robustness of iBGP also. From my…

I suspect most people would agree that a single mechanism would be preferable, but the fact of the matter is that the change that Enke is proposing is cheap and easy and does not apply well to iBGP.  A more general mechanism is going to be much more difficult.

It seems to me that taking the low hanging fruit now does not deter further work later, so I'm not seeing a lot of downside in doing this now.

Tony