Subject: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00

From: "John G. Scudder" <[email-masked]>
Date: Sun, 1 Mar 2009 08:40:28 -0500

FYI.  We plan to present this at the upcoming IDR meeting.

URL: http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt

--John

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: March 1, 2009 8:35:33 AM GMT-05:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for  draft-scudder-idr-optional- 
> transitive-00
>
>
> A new version of I-D, draft-scudder-idr-optional-transitive-00.txt  
> has been successfuly submitted by John Scudder and posted to the  
> IETF repository.
>
> Filename:	 draft-scudder-idr-optional-transitive
> Revision:	 00
> Title:		 Error Handling for Optional Transitive BGP Attributes
> Creation_date:	 2009-03-01
> WG ID:		 Independent Submission
> Number_of_pages: 6
>
> Abstract:
> According to the base BGP specification, a BGP speaker that receives
> an UPDATE message containing a malformed attribute is required to
> reset the session over which the offending attribute was received.
> This behavior is undesirable in the case of optional transitive
> attributes.  This document revises BGP's error-handling rules for
> optional transitive attributes, and provides guidelines for the
> authors of documents defining new optional transitive attributes.  It
> also revises the error handling procedures for several existing
> optional transitive attributes.
>
>
>
> The IETF Secretariat.
>
>

---

From: Danny McPherson <[email-masked]>
Date: Tue, 3 Mar 2009 01:12:14 -0700

> URL: http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt

Some comments on the draft...

-
I'm not sure I like the recommended behavior in S 2
where we're treating malformed updates "as though all
contained prefixes had been withdrawn".  I'd strongly
prefer that in ALL cases the update be discarded.
Making assumptions and providing rules for how to
selectively handle mal-formed updates seems much like
something you yourself would caution us against.  I'd
much prefer a 'discard and log' requirement.

-
I could see how this text is S 2. might not be the case,
if varying implementations handle a given update in
different ways:

"This is likewise the case if an optional transitive
attribute is received whose Partial bit is not set --
this is because the detected error can be imputed to
the direct peer."

No other comments, I think this is a useful document.

-danny

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Mar 2009 02:11:25 -0800

Hi Danny,

 > prefer that in ALL cases the update be discarded.

Wouldn't making "silent" update discard lead to stale BGP paths sitting 
in the network as long as the session they were received on is up ? I am 
  thinking about implicit/explicit withdraws in fact in both ebgp and 
ibgp cases.

Do we making in this draft an implicit assumption that transitive 
attribute malformation must always happen day one and not after the 
original advertisement have already left the originator ?

I think the current text at least suggest that if withdraw of NLRIs is 
possible when we drop the update let's dispatch it.

I personally don't like the "if" part. If we make a protocol decision 
optimized for "most common" scenarios and not "all cases" IMHO we are 
already starting to cut the branch we are sitting on.

    "While lamentable, this
    issue is expected to be rare in practice, and more importantly is
    seen as less problematic than the session-reset behavior it
    replaces."

I would actually propose to drop the update _only_ if withdraw of NLRIs 
it contains can be generated. If not continue today's behavior to drop 
the session. Having even if "rear in practice" black wholes is quite 
scary if some folks are already looking at using IP to control for 
example commercial aircrafts.

Two additional points to the claim that dropping the session is worst 
thing ...

* We design a mechanism without any assumption if 1% or 99% or received 
updates contain a malformed transitive optional attribute. If it is the 
latter wouldn't dropping the session be actually much cleaner solution 
network wide ?

* Considering bigger picture and the consequence of dropping the session 
it is true that today it may result in BGP churn and potential for 
traffic disruption. But let's keep in mind that more and more tools are 
being introduced across vendors to allow you to have path redundancy 
already in place for each net. That combined with peering redundancy 
would effectively result in a very localized path switchovers with 
almost negligible network wide consequences of single session drop.

Cheers,
R.

>> URL: 
>> http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt 
>>
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
> 
>

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 3 Mar 2009 08:40:45 -0500

> much prefer a 'discard and log' requirement.

The example below should refresh your memory of why "discard" doesn't  
fly.  "Treat as withdraw" is basically the closest *safe* version of  
"discard".

--John

> From: "John G. Scudder" <[email-masked]>
> Date: December 15, 2008 2:34:34 PM GMT-05:00
> To: Danny McPherson <[email-masked]>
> Cc: Jeffrey Haas <[email-masked]>, [email-masked], Enke  
> Chen <[email-masked]>, [email-masked], [email-masked],  
> Inter-Domain Routing List <[email-masked]>, Yakov Rekhter <[email-masked] 
> >, Tony Li <[email-masked]>, Quaizar Vohra <[email-masked]>
> Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes
>
> On Dec 15, 2008, at 2:21 PM, Danny McPherson wrote:
>> After thinking about this for a few minutes, I can't currently
>> come up with any configuration where a forwarding loop would occur
>> as a result of just dropping the update (because the "translation"
>> occurs on ingress to an AS), so discarding the update is likely
>> to be a cleaner action.
>
>
> AS1---AS2
>   \   /
>    \ /
>    AS3
>
> - AS1 prefers to reach AS3 directly, and advertises its route to AS2.
> - AS2 prefers to reach AS3 directly, and advertises its route to AS1.
> - Connections AS3-AS1 and AS3-AS2 fail simultaneously.
> - AS1 switches to prefer AS2's route, and sends an update message  
> which
>   includes a withdraw of its previous announcement.  The withdraw is
>   bundled with some advertisements.  It includes a bad attribute.   
> As a
>   result, AS2 ignores the message.
> - AS2 switches to prefer AS1's route, and sends an update message  
> which
>   includes a withdraw of its previous announcement.  The withdraw is
>   bundled with some advertisements.  It includes a bad attribute.   
> As a
>   result, AS1 ignores the message.
>
> End result is that AS1 forwards traffic for AS3 towards AS2, and AS2  
> forwards traffic for AS3 towards AS1.  This is a permanent (until  
> corrected) forwarding loop.
>
> I'm sure a less-contrived example can also be constructed, but this  
> one should be sufficient to prove the point.
>
> --John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 3 Mar 2009 08:50:47 -0500

> this is because the detected error can be imputed to

Can you be more specific about this?  It seems to me that the behavior  
for setting the Partial bit is fully specified, so all compliant &  
correct implementations should behave more or less the same in that  
respect.

Since the relevant corollary in this case is that if the Partial bit  
is not set we know that the direct peer recognized the path attribute  
(else it would have set the Partial bit), I guess we can focus on what  
the consequences are if that is NOT done.  Case 1 is when the direct  
peer doesn't set Partial even though it doesn't recognize the  
attribute.  In that case we would falsely "blame" the direct peer for  
the detected malformation and reset the session.  I think this is OK  
insofar as the direct peer *does* have a bug in its path attribute  
handling in this scenario, although not the one we think it does.   
Case 2 is when the direct peer recognizes the attribute but sets  
Partial anyway.  In that case we would mistakenly give the direct peer  
a free pass instead of "blaming" it, and would follow the treat-as- 
withdraw behavior instead of resetting the session.  This isn't ideal,  
but we already think treat-as-withdraw is OK as the general-case error- 
handling behavior -- session reset is an optimization.  So I think  
that's OK.  (Also I think these scenarios are pretty far-fetched.)

Based on this I'm comfortable with relying on the Partial bit.  If we  
weren't going to do this the question would be, what to do instead?

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 3 Mar 2009 09:00:15 -0500

Hi Robert,

> original advertisement have already left the originator ?

No, the draft applies equally regardless of where the malformation is  
introduced.

> I think the current text at least suggest that if withdraw of NLRIs  
> is possible when we drop the update let's dispatch it.

Sorry, didn't follow the above.

> Two additional points to the claim that dropping the session is  
> worst thing ...

I'd be interested in feedback from the WG regarding the question of  
withdrawing the routes (what the draft proposes) vs. dropping the  
session (current behavior).  Especially feedback from network operators.

--John

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Mar 2009 07:22:28 -0800

Hi John,

Let me clarify ...

    Note
    that this option requires that the NLRI field and/or MP_REACH
    [RFC4760] attribute be successfully parsed.  In the case of an
    optional transitive attribute which has no effect on route selection
    or installation, the malformed attribute MAY instead be discarded.
    An example of such an attribute is the AGGREGATOR attribute.  In any
    case, an error in an optional transitive attribute whose Partial bit
    is set MUST NOT be responded to by sending a NOTIFICATION message or
    resetting the BGP session.

The draft in the current form says to withdraw the routes if malformed 
partial transitive optional attribute which has an effect on routing is 
received within the BGP update msg. That is fine. (My email was actually 
in support on this behavior in response to Danny's mail).

On the other hand the draft is confusing in defining the behavior on 
when such NLRI can not be parsed. That would effectively mean that the 
update itself can not be parsed and is silently dropped. I am just 
questioning that part of this draft.

The draft says: "In any case, an error in an optional transitive 
attribute whose Partial bit is set MUST NOT be responded to by sending a 
NOTIFICATION message or resetting the BGP session."

So if an optional transitive attribute whose Partial bit is set has an 
error in it's length field we can not reset the session. That is IMHO 
too strong of requirement.

 > session (current behavior).  Especially feedback from network

Exactly.

In particular I would like to get other's opinion of the previously 
stated questions ...

* What is better to drop the session or to drop 99% of updates with such 
session ?

* What people who design mission critical applications based on BGP feel 
about protocol not being robust in all cases and allowing for "rare in 
practice" black wholes ?

In other words today we pretty well know how to build redundant and 
robust networks for such applications by introducing additional peering 
sessions, dual vendor networks etc .. But that works as long as protocol 
is 100% accurate. If you would start optimizing it for most common cases 
that will likely result in introduction of whole new dimension to 
network design best practices. More over such silent update drop 
dimension may be very difficult to architect around.

Cheers,
R.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 3 Mar 2009 11:50:48 -0500

Thanks for clarifying, Robert.

On Mar 3, 2009, at 10:22 AM, Robert Raszuk wrote:
> The draft in the current form says to withdraw the routes if  
> malformed partial transitive optional attribute which has an effect  
> on routing is received within the BGP update msg. That is fine. (My  
> email was actually in support on this behavior in response to  
> Danny's mail).
>
> when such NLRI can not be parsed. That would effectively mean that  
> the update itself can not be parsed and is silently dropped. I am  
> just questioning that part of this draft.

Ah!  That was not the intent.  That sentence ("Note that this option  
requires that the NLRI field and/or MP_REACH [RFC4760] attribute be  
successfully parsed") is non-normative and is meant to draw the  
attention of implementors to exactly the problem you're pointing out.   
Two paragraphs down the draft says that if the UPDATE is broken in any  
other way the normal reset behavior is followed.  ("In the event that  
an UPDATE message is deemed to be malformed in any other way... the  
procedures of [RFC4271] continue to apply.")

I'll take a note to clarify this in -01, either by removing the  
sentence which caused the confusion, explicitly calling out non- 
parseable NLRI as an example of a fatal error, or both.

> attribute whose Partial bit is set MUST NOT be responded to by  
> sending a NOTIFICATION message or resetting the BGP session."
>
> So if an optional transitive attribute whose Partial bit is set has  
> an error in it's length field we can not reset the session. That is  
> IMHO too strong of requirement.

Not sure why you see this as a problem -- as long as the error is  
restricted to that particular optional transitive attribute, that is  
exactly the error case this draft is trying to cover.  Indeed for  
practical purposes length field errors are the majority of  
discoverable errors in optional transitives.  And the same exact  
problems apply for length field as any other error -- that is, routers  
which do not recognize that particular attribute are unable to  
validate the length field since they don't know what the length is  
supposed to be.  I do agree (see above) that if there is any error in  
the UPDATE other than one restricted to an optional transitive Partial  
attribute, RFC 4271 rules should continue to apply.

> More over such silent update drop dimension may be very difficult to  
> architect around.

To reiterate, "silent update drop" isn't the intent of the draft and  
we'll strive to make this even clearer in the next version.

Thanks,

--John

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Mar 2009 09:44:41 -0800

Hi John,

It's so great to be in sync !

 > we'll strive to make this even clearer in the next version.

I would just propose a one sentence to be added to make it cristal clear 
...

"If due to an errors, including those propagated in transitive 
attributes, the other attributes of the update message can not be 
correctly parsed the entire update is considered invalid and procedures 
of [RFC4271] continue to apply.

that would clearly contradict with the text below which perhaps needs to 
be re-edited a bit too.

 >> sending a NOTIFICATION message or resetting the BGP session."

Cheers & Thx
R.

>> partial transitive optional attribute which has an effect on routing 
>> is received within the BGP update msg. That is fine. (My email was 
>> actually in support on this behavior in response to Danny's mail).
>>
> other way the normal reset behavior is followed.  ("In the event that an 
> UPDATE message is deemed to be malformed in any other way... the 
> I'll take a note to clarify this in -01, either by removing the sentence 
> which caused the confusion, explicitly calling out non-parseable NLRI as 
> an example of a fatal error, or both.
> 
>> attribute whose Partial bit is set MUST NOT be responded to by sending 
>> a NOTIFICATION message or resetting the BGP session."
>>
> practical purposes length field errors are the majority of discoverable 
> errors in optional transitives.  And the same exact problems apply for 
> length field as any other error -- that is, routers which do not 
> recognize that particular attribute are unable to validate the length 
> field since they don't know what the length is supposed to be.  I do 
> agree (see above) that if there is any error in the UPDATE other than 
> one restricted to an optional transitive Partial attribute, RFC 4271 
> rules should continue to apply.
>

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 3 Mar 2009 12:51:38 -0500

On Mar 3, 2009, at 12:44 PM, Robert Raszuk wrote:
> I would just propose a one sentence to be added to make it cristal  
> clear ...
>
> correctly parsed the entire update is considered invalid and  
> procedures of [RFC4271] continue to apply.

I'll add that or something like it.

> that would clearly contradict with the text below which perhaps  
> needs to be re-edited a bit too.
>

I think your concern would be addressed by a simple change: s/in/ 
limited to/, so: "In any case, an error limited to an optional  
transitive attribute whose Partial bit is set MUST NOT be responded to  
by sending a NOTIFICATION message or resetting the BGP session."  Agree?

Thanks,

--John

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Mar 2009 10:43:35 -0800

Hi John,

> I'll add that or something like it.

Thx !

>> that would clearly contradict with the text below which perhaps needs 
>> to be re-edited a bit too.
>>
> I think your concern would be addressed by a simple change: s/in/limited 
> to/, so: "In any case, an error limited to an optional transitive 
> NOTIFICATION message or resetting the BGP session."  Agree?

Well if you want to massage this sentence to make it sound right one 
would need to also mention that this applies only if such an error 
limited to given transitive attribute has no impact on routes. For 
example transitive ext community route target attribute can not be just 
dropped as vpnv4 routes in an implicit withdraw propagated further would 
be of quite a limited use.

Cheers,
R.

---

From: Rob Shakir <[email-masked]>
Date: Wed, 4 Mar 2009 12:33:12 +0000

> session (current behavior).  Especially feedback from network operators.

John,

Thanks very much for the work on this draft by Enke and yourself.

>From my perspective (and I think a number of other operators that I have spoken
with), the approach of treating the invalid update as a withdraw of the routes
within it is the best way to handle this problem -- as I posted to the list
earlier in the year.

Whilst I think that there is perhaps scope for comments on this draft that ask
for this behaviour to be extended to all optional transitive attributes, rather
than just those with the partial bit set, I do not think that this is the best
way forward on this matter. The major operational problem with tunneled
attributes (as well as the security implications), is that the operator does not
have a direct relationship with the party that has caused the session to be torn
down -- any errors in a direct neighbour's BGP implementation can generally be
addressed by existing communication channels with the neighbouring AS, and hence
a comparitively easier to resolve.

With regards to the question posed earlier in this thread as to whether it is
preferable to see session teardown, or 99% of the prefixes on this session
withdrawn, I would definitely lean towards the prefixes being withdrawn. The
reasoning is even clearer when taking the opposite extreme -- a single prefix
tearing down a session carrying the global table. In this case, the impact to
the network that receives this update is that we lose visibility of the global
BGP table  (by one of our paths at least), rather than just 'punishing' a single
prefix with unreachability.

Operationally -- I think that any 'harmful' implications of this issue are
well-handled by section 3 -- the requirement to provide debugging features
should allow operators to easily identify why this prefix has been withdrawn. It
is also worth considering the number of scenarios in which the prefix will
become completely unreachable from a multi-homed network -- I believe that this
will be rare in practice.

Once again -- thanks for the work on this.

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: David Freedman <[email-masked]>
Date: Tue, 10 Mar 2009 14:32:59 +0000

> should allow operators to easily identify why this prefix has been withdrawn. 

http://tools.ietf.org/html/draft-scholl-idr-advisory-00

I'm waiting for this to hit the list.

Tom is just back from hols though so expect delay.

Dave.

---

From: Rob Shakir <[email-masked]>
Date: Tue, 10 Mar 2009 20:28:35 +0000

> Tom is just back from hols though so expect delay.

Dave,

Thanks for bringing this one to my attention! :-)

I'll keep my comments on draft-scholl-idr-advisory-00 for the appropriate
thread, but I think that this is not a replacement for
draft-scudder-idr-optional-transitive (I don't think it is intended to be),
since in this case, sending an advisory message to our directly connected
neighbour will not help (since this draft applies only those attributes that
have not been checked by them).

Kind regards,
Rob

---

From: "David Freedman" <[email-masked]>
Date: Tue, 10 Mar 2009 23:30:17 -0000

No, actually this draft will aid the "debugging" as quoted 
------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]]
Sent: Tue 3/10/2009 20:28
To: David Freedman
Cc: John G. Scudder; idr List
Subject: Re: Fwd: New Version Notification   fordraft-scudder-idr-optional-transitive-00

Dave,

Kind regards,
Rob