Subject: [Idr] RFC-4893 handling malformed AS4_PATH attributes

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Thu, 11 Dec 2008 19:41:10 +0530

Dear Authors, IDR-list, 

I tend to suggest couple changes in the following RFCs:

RFC-4893: In section "4.2.3.  Processing Received Updates":
--------
Please consider Adding this text:
   If a NEW BGP speaker receives an Update message containing the path 
   segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] in the 
   AS4_PATH attribute, it may discard the Update after logging the event
   locally containing details like the attribute (type, length, and
value), 
   peer-address, as-path (may help in determining the originator of the 
   malformed-attribute) etc. 

RFC-4271: section "6.3 UPDATE Message Error Handling"
---------
Please consider Changing this text:
   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded, and the Error Subcode MUST be set to Optional
   Attribute Error.  The Data field MUST contain the attribute (type,
   length, and value).
To:
   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the update
   MUST be discarded, and a warning logged locally containing details
like
   the attribute (type, length, and value), peer-address, as-path (may
help
   in determining the originator of the malformed-attribute) etc.

Motivation behind the suggestion:
---------------------------------
This suggestion is focused on error-handling of "optional transitive
attributes" recognized by a BGP speaker receiving them. Because any
errors in the semantics of the optional-transitive-attribute will be
caught by a BGP-speaker which could be far away from the place of
origination of the error(as the speaker who don't recognize the
opt-trans-attribute will just propagate them to their peers), it may be
good idea to be more-lenient in the way the error is handled. i.e. I
feel tearing down the BGP session with the immediate neighbor must be
avoided. Because this affects the session between two BGP speakers
neither of whom are-responsible-for(originated) the
malformed-optional-transitive-attribute. 

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

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 11 Dec 2008 13:36:21 -0500

Hi Kaliraj,

There are well-known correctness problems with simply discarding an  
UPDATE.  This gets discussed on the list every few years, every time  
some implementation bug crops up which causes a lot of NOTIFICATIONS.   
To date, the WG has resisted the temptation to compromise the  
protocol's correctness.  You do have a good point that optional  
transitives are especially problematic; however, the correctness  
problem still exists if you start dropping UPDATEs, so this would seem  
to be a case of cutting off the patient's head to cure the flu.

Now that you bring it up though, the text from RFC 4271 you quote is  
kind of bizarre:

Can anyone offer an explanation of what it's supposed to mean that the  
attribute MUST be discarded given that the section also says that  
you're going to send a NOTIFICATION and tear down the entire session?   
Seems as though the clause "the attribute MUST be discarded" should  
itself be discarded.

--John

---

From: Florian Weimer <[email-masked]>
Date: Fri, 12 Dec 2008 09:11:11 +0100

* John G. Scudder:

> protocol's correctness.

Discarding the UPDATE is probably not a good idea.  Ignoring the
option (and propagating it, just to be sure) should be sufficient.

> Seems as though the clause "the attribute MUST be discarded" should

The update could be propagated further just before the session is torn
down.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 10:04:02 -0700

On Dec 11, 2008, at 11:36 AM, John G. Scudder wrote:

> some implementation bug crops up which causes a lot of  
> NOTIFICATIONS.  To date, the WG has resisted the temptation to  
> compromise the protocol's correctness.  You do have a good point  
> that optional transitives are especially problematic; however, the  
> correctness problem still exists if you start dropping UPDATEs, so  
> this would seem to be a case of cutting off the patient's head to  
> cure the flu.
>
> Can anyone offer an explanation of what it's supposed to mean that  
> the attribute MUST be discarded given that the section also says  
> that you're going to send a NOTIFICATION and tear down the entire  
> session?  Seems as though the clause "the attribute MUST be  
> discarded" should itself be discarded.

John et al.,
I believe this is actually a pretty serious issue here that we must
address in some manner.  Essentially, this "tunneling" of AS_CONFED_*
via AS4_PATH attributes creates a remote session-reset attack vector
(versus a nearly identical issue that was much more manageable that
led to my (our :-) adding the RFC 3065 confed segment handling text
in the first place) which could be either very wide-spread, or
targeted(!), in particular once more OLD->NEW peering sessions are
setup.

While I agree that we don't ever want to ignore updates or provide
non-deterministic behavior, this "tunneling" of attributes we're
doing here leads me to strongly agree with Kaliraj that we need to
update RFC 4893 update error handling procedures in this instance.
However, my recommended text is a bit more stringent:

Recommended addition to RFC 4893 - S 4.2.3:

   If a NEW BGP speaker receives an UPDATE message containing the path
   segment types AS_CONFED_SEQUENCE or AS_CONFED_SET [RFC3065] in the
   AS4_PATH attribute, it MUST strip and discard those segments from the
   attribute and continue processing the the AS4_PATH attribute.  The
   BGP speaker MUST log the event in a manner that assists network
   operators in determining the originator of the malformed attribute.

Likewise, some text added to the Security section highlighting the
purpose for this text is in order as well.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 12:38:17 -0700

On Dec 15, 2008, at 12:14 PM, Enke Chen wrote:
>
> The issue of receiving unexpected AS_CONFED_xxx segment was actually  
> considered when we were working on the 4byte AS document before. The  
> thinking was that it's a generic issue with the confederation that  
> has been addressed by the confederation document.

But it's not, because you're now tunneling these attributes
in AS4_PATH and can result in *remote* non-adjacent session
tear downs or even craft targeted attacks with such a behavior,
not just adjacent eBGP speakers.

> While the confederation document (RFC 5056) treats it as an error  
> condition to maintain the protocol correctness, the implementations  
> commonly just ignore the segments.  "be conservative in what you  
> send, and be liberal in what you accept".

I'm not sure what that means, are you saying that you propagate
those segments and ignore the spec?  or that you discard them
and ignore the spec?  If the latter, you're saying that's what you
currently do, but the spec need not be updated to reflect this?

And what if those segments were there because a broken generating
implementation put them, rather than a confederation identifier,
in the AS4_PATH attribute?  Could this not result in routing
information loops?  Should the operator not be notified of this?

Either way, I get the "people do stupid things, don't let them
hurt you bit", but the fact that RFC 4893 enables this is a
problem.

-danny

---

From: Enke Chen <[email-masked]>
Date: Mon, 15 Dec 2008 12:09:58 -0800

> currently do, but the spec need not be updated to reflect this?

For the implementations of confederation that I am familiar with, the 
AS_CONFED_xxx segments are discarded if received unexpectedly (e.g., 
from eBGP).  The offense is not considered serious enough to tear down 
the session.

Regarding the confederation spec, do not ask me.  You are one of the 
co-authors of the latest version.

> information loops?  Should the operator not be notified of this?

These questions have been answered by 15 years of confederation 
deployment.  Don't they?

> hurt you bit", but the fact that RFC 4893 enables this is a

Again, I do not see any reason why RFC 4893 should be different from RFC 
5056 w.r.t. the processing of unexpected confed segments.

-- Enke

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Dec 2008 15:22:54 -0500

> 5056 w.r.t. the processing of unexpected confed segments.

Orthogonal to the "could we do something better about it" discussion:
In 5065, the pain is isolated to an adjacent peering edge.
In 4893, the pain originates far away.

The penalty for pedantically obeying the spec is higher.  We saw this
even for something as simple as the motivation for the 5065 rewrite.

-- Jeff

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 13:25:21 -0700

>
> For the implementations of confederation that I am familiar with,  
> the AS_CONFED_xxx segments are discarded if received unexpectedly  
> (e.g., from eBGP).  The offense is not considered serious enough to  
> tear down the session.
>

The comment was about your use of "the implementations commonly..",
not the spec.  I know why it says this, and apparently, this is yet
another reason why folks should follow it.

> Again, I do not see any reason why RFC 4893 should be different from  
> RFC 5056 w.r.t. the processing of unexpected confed segments.

Assuming you actually mean 5065 here, it says:

If a BGP speaker receives such an UPDATE message, it SHALL
treat the message as having a malformed AS_PATH according
to the procedures of [BGP-4], Section 6.3 ("UPDATE Message
Error Handling").

And S 6.3 of 4271, as you well know, says send a
notification indicating malformed path and shut the
session down.

So, you're saying YOU (Cisco) doesn't do what AS 5065 says,
or what RFC 4893 says, but the specification should NOT be
updated to fix this problem with AS4_PATH and remote attack
vulnerabilities?

I'm confused Enke?

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 13:31:22 -0700

On Dec 15, 2008, at 1:25 PM, Danny McPherson wrote:

>> Regarding the confederation spec, do not ask me.  You are one of  
>> the co-authors of the latest version.
>
>> Again, I do not see any reason why RFC 4893 should be different  
>> from RFC 5056 w.r.t. the processing of unexpected confed segments.
>

I should clarify that it does say SHALL, not MUST,
and that your point is that you don't believe the
offense is bad enough to tear the session down, which
is reasonable.

But clearly, in this case, more explicit guidance is
needed, given the ability of a remote attacker to do
something, v. an adjacent BGP speaker or AS.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 14:09:07 -0700

On Dec 15, 2008, at 1:31 PM, Danny McPherson wrote:

>>> (e.g., from eBGP).  The offense is not considered serious enough  
>>> to tear down the session.
>>>

OK, this (me replying to myself) is probably getting
annoying, but after being reminded that SHALL does
indeed == MUST in 2119 context:

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the  
definition is an absolute requirement of the specification.

So, ALL my points remain, and I still contend that 4893
needs to be updated.

-danny

---

From: Enke Chen <[email-masked]>
Date: Mon, 15 Dec 2008 16:16:43 -0800

> updated to fix this problem with AS4_PATH and remote attack

The logic here appears twisted. I have never said that either RFC should 
NOT be updated. I just gave the rational why the behavior was not 
spelled out explicitly in the 4byte AS document (because we thought 
that's covered by the confed documentation). Also I stated that the 
behavior for processing unexpected confed segments should be the same in 
both RFCs.

If the WG consensus is to update RFC 5056 / RFC 4893, or both, I will be 
glad to do my share with Quaizar on RFC 4893.

-- Enke

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 18:14:52 -0700

On Dec 15, 2008, at 5:16 PM, Enke Chen wrote:
>
> The logic here appears twisted. I have never said that either RFC  
> should NOT be updated. I just gave the rational why the behavior was  
> not spelled out explicitly in the 4byte AS document (because we  
> thought that's covered by the confed documentation). Also I stated  
> that the behavior for processing unexpected confed segments should  
> be the same in both RFCs.

Heh, ok then :-)

> If the WG consensus is to update RFC 5056 / RFC 4893, or both, I  
> will be glad to do my share with Quaizar on RFC 4893.

Very well, thanks Enke!

-danny

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Tue, 16 Dec 2008 14:20:41 +0530

I agree with the text proposed by Danny, to handle this particular
malformed-ness in AS4_PATH attribute.

>   operators in determining the originator of the malformed attribute.

Further, may be the general handling of "malformed
optional-transitive-attributes" needs a closer look (RFC-4271) too -
given the fact that whenever new-features using newer
opt-trans-attributes are deployed, we may hit this issue. 

May be implementations should provide the operator with means to be
cognizantly lenient and skip the malformed optional-transitive-attribute
without dropping the session.

i.e.

RFC-4271: section "6.3 UPDATE Message Error Handling"
---------
May be we can consider Changing this text:
   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded, and the Error Subcode MUST be set to Optional
   Attribute Error.  The Data field MUST contain the attribute (type,
   length, and value).
To:
   If an optional transitive attribute is recognized, then the value of
this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded. And the speaker MAY continue processing the UPDATE

   after logging the event in a manner that assists network operators in

   determining the originator of the malformed attribute; this decision 
   should be taken on a case-by-case basis as specified by the
attribute's 
   error-handling mechanisms. If the speaker chooses to send a
Notification, 
   Error Subcode MUST be set to Optional Attribute Error.  The Data
field 
   MUST contain the attribute (type, length, and value).

Thanks,
Kaliraj 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Danny McPherson
Sent: Tuesday, December 16, 2008 6:45 AM
To: Enke Chen
Cc: Inter-Domain Routing List; [email-masked]
Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes

Heh, ok then :-)

Very well, thanks Enke!

-danny

---

From: Paul Jakma <[email-masked]>
Date: Tue, 16 Dec 2008 09:34:34 +0000 (GMT)

On Mon, 15 Dec 2008, Enke Chen wrote:

> If the WG consensus is to update RFC 5056 / RFC 4893, or both, I will be glad 
> to do my share with Quaizar on RFC 4893.

If there's to be a re-spin, can we fix some other nits? E.g. silently 
discarding AS4_PATH if the length of AS_PATH is less than it.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: John Leslie <[email-masked]>
Date: Tue, 16 Dec 2008 09:02:12 -0500

> discarding AS4_PATH if the length of AS_PATH is less than it.

   In the various cases where AS4_PATH cannot be accurately matched to
an appropriate portion of the AS_PATH received from an OLD BGP speaker,
it seems best to me to discard it.

   Note, however, that this adds yet more cases where the reconstructed
path may contain AS_TRANS. Whenever a NEW BGP speaker which would use
AS_TRANS to represent itself in an AS_PATH sent to an OLD BGP speaker
encounters an incoming AS_PATH which contains AS_TRANS after 4893
processing, the question of whether that indicates a routing loop must
be considered.

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

---

From: Paul Jakma <[email-masked]>
Date: Tue, 16 Dec 2008 17:07:22 +0000 (GMT)

> it seems best to me to discard it.

And what happens then? If a NEW speakers must discard AS4_PATH, then 
it will later do loop-detection on an AS_PATH that very likely 
contains AS_TRANS. The first speaker with a >65535 ASN will ignore it 
during route selection.

a) It's not entirely clear to me whether that was the intention.

    - note that the speaker which dropped the AS4_PATH might be far
      away from the speaker which ignores the route and so perhaps
      causes the problem to be noticed.

b) It's no doubt implied, but perhaps any RFCbis should make it clear
    that AS_TRANS MUST be considered to match all ASNs > 65535 when
    doing AS-Path (in the abstract) loop detection.

I'm thinking the AS4_PATH/AS_PATH reconciliation failure needs to be 
terminal, at least for the propogation of the UPDATE (even if the 
receiving NEW speaker can still use the route) if nothing else. 
Perhaps something stronger?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Cohen's Law:
 	There is no bottom to worse.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: John Leslie <[email-masked]>
Date: Tue, 16 Dec 2008 12:27:15 -0500

> contains AS_TRANS. The first speaker with a >65535 ASN will ignore it 

   I sincerely hope so...

>      causes the problem to be noticed.

   The NEW BGP speaker that discarded the AS4_PATH had a view completely
consistent with the OLD BGP speaker it received it from. (Anything else,
IMHO, would be dangerous.)

   The NEW BGP speaker that finally discards it has an unhappy choice:
to accept a route which may contain a loop, or to ignore a route which
may be far better than any alternative.

   (I did not mean to say which choice is better...)

>    doing AS-Path (in the abstract) loop detection.

   That's the obvious solution -- IMHO it's better to specify something
safe -- but I'm open to other suggestions.

> Perhaps something stronger?

   Worth considering...

---

From: Enke Chen <[email-masked]>
Date: Tue, 16 Dec 2008 11:01:09 -0800

Hi, Paul:

The case is already specified in the document:

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

4.2.3.  Processing Received Updates
    
   ...

   If the number of AS numbers in the AS_PATH attribute is less than the
   number of AS numbers in the AS4_PATH attribute, then the AS4_PATH
   attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken
   as the AS path information.

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

Regards,   -- Enke

Paul Jakma wrote:
>> If the WG consensus is to update RFC 5056 / RFC 4893, or both, I will 
>> be glad to do my share with Quaizar on RFC 4893.
>

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 16 Dec 2008 15:58:44 -0500

>   doing AS-Path (in the abstract) loop detection.

Seems to me that this is not required in order to preserve the loop  
free property. We have two possible cases:

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.

--John

---

From: Paul Jakma <[email-masked]>
Date: Wed, 17 Dec 2008 08:13:36 +0000 (GMT)

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

regardsm
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Bus error -- driver executed.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Paul Jakma <[email-masked]>
Date: Wed, 17 Dec 2008 08:27:09 +0000 (GMT)

> The case is already specified in the document:

Yes, that's the text I'm referring to.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
A likely impossibility is always preferable to an unconvincing possibility.
 		-- Aristotle
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 17 Dec 2008 10:52:10 -0500

On Dec 17, 2008, at 3:13 AM, Paul Jakma wrote:
>> 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.
>>
> We're talking about the case where the AS4_PATH has been removed by  
> a preceding NEW speaker though.
>

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.

--John

---

From: Paul Jakma <[email-masked]>
Date: Wed, 17 Dec 2008 17:33:34 +0000 (GMT)

On Wed, 17 Dec 2008, John G. Scudder wrote:

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

Things like private-AS removal technically are broken, I guess, yes.

Also, it's not clear to me whether the "the number of AS numbers" in 
the reconciliation scheme means literally that or the traditional 
path-length metric from 4271. I presume it means it literally. That 
might come into play for things like where an OLD speaker receives:

 	1_2_{23456,23456,23456}

and then re-announces the set as, say due to how it implements as-set 
sorting:

 	1_2_{23456}

Though, I guess that's not much of a worry.

> heartening that the protocol appears to be robust even in the face 
> of certain types of mangling of the AS4_PATH.

It's reassuring, that it's robust in this way, yes. It would be more 
robust if NEW speakers considered AS_TRANS to == any >65535 ASN. E.g. 
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.

I don't see why we would want to leave loop-detection degraded in 
this way, given a respin, when it seems so trivial to strengthen it.

But anyway.. :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Anger kills as surely as the other vices.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Enke Chen <[email-masked]>
Date: Wed, 17 Dec 2008 09:44:19 -0800

Hi, Paul:

Paul Jakma wrote:
>> 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;
>
> path-length metric from 4271

It is specified in RFC 4893, Sect. 4.2.3:

   In order to construct the AS path information, it would be necessary
   to first calculate the number of AS numbers in the AS_PATH and
   AS4_PATH attributes using the method specified in Section 9.1.2.2
   [BGP] and [RFC3065] for route selection.

-- Enke

> . I presume it means it literally. That might come into play for 
> things like where an OLD speaker receives:
>
>     1_2_{23456,23456,23456}
>
> 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.
>
> I don't see why we would want to leave loop-detection degraded in this 
> way, given a respin, when it seems so trivial to strengthen it.
>
> But anyway.. :)
>
> regards,

---

From: Paul Jakma <[email-masked]>
Date: Wed, 17 Dec 2008 18:30:27 +0000 (GMT)

> this way, given a respin, when it seems so trivial to strengthen 

Oh, the other possibility in such a case is to take the union of the 
AS_PATH and AS4_PATH.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Do people know you have freckles everywhere?
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr