Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Jan 2012 20:45:32 -0500

[Explicit cc on the draft-ietf-idr-error-handling authors for the comments below.]

Warren,

On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote:
> On Dec 16, 2011, at 8:05 PM, Enke Chen wrote:
> >  1) Is it really necessary to make AS 0 an error in the AGGREGATOR and AS4_AGGREGATOR attributes?  What is the gain?
> 
> I'll double check with co-authors on Monday -- I don't think it is strictly necessary to prevent attack, rather it seemed more elegant to check AS 0 where ever it occurs.

While I generally agree with Enke that treating as a malformed route is
probably excessive, I think the recommended behavior is desirable.  The
mandate that the error-handling draft procedures must be used makes it
acceptable.  Without those procedures, bouncing the session is almost
certainly the wrong thing to do.

> It was brought up on the NANOG list that some vendors support zero'ing out the AGGREGATOR (see Junipers "no-aggregator-id" as an example -- this appears to only zero out the router ID, but I haven't checked all implementations), so checking for AS 0 in the .*AGGREGATOR may be a bad idea, so at the moment I'm leaning towards removing it (obviously, this being a WG doc, with the WG's approval)

Older varieties of gated had bugs with respect to the AS number that was
selected to be placed in the aggregator AS field.  JunOS may have had
similar bugs at one point but the behavior that I can see in a cursory check
of the code should result in a system AS number being placed there.

My recommendation for the as0 draft is that we leave in the current text and
let the attribute be treated as "malformed" by the error-handling draft.
The behavior in that draft of attribute-discard is reasonable.

> >  2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be referenced if you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR.
> > 
> 
> Doh! This was mentioned a few times and I intended to do so, but it completely slipped my mind when typing... Thanks for reminding me....

Similarly, there should be references for these attributes added to the
error-handling draft.

-- Jeff

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 4 Jan 2012 20:51:17 -0500

+1

Regards,
Jeff
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Wednesday, January 04, 2012 5:46 PM
To: Warren Kumari
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt

Warren,

> I'll double check with co-authors on Monday -- I don't think it is strictly necessary to prevent attack, rather it seemed more elegant to check AS 0 where ever it occurs.

While I generally agree with Enke that treating as a malformed route is probably excessive, I think the recommended behavior is desirable.  The mandate that the error-handling draft procedures must be used makes it acceptable.  Without those procedures, bouncing the session is almost certainly the wrong thing to do.

> It was brought up on the NANOG list that some vendors support zero'ing 
> out the AGGREGATOR (see Junipers "no-aggregator-id" as an example -- 
> this appears to only zero out the router ID, but I haven't checked all 
> implementations), so checking for AS 0 in the .*AGGREGATOR may be a 
> bad idea, so at the moment I'm leaning towards removing it (obviously, 
> this being a WG doc, with the WG's approval)

Older varieties of gated had bugs with respect to the AS number that was selected to be placed in the aggregator AS field.  JunOS may have had similar bugs at one point but the behavior that I can see in a cursory check of the code should result in a system AS number being placed there.

My recommendation for the as0 draft is that we leave in the current text and let the attribute be treated as "malformed" by the error-handling draft.
The behavior in that draft of attribute-discard is reasonable.

> Doh! This was mentioned a few times and I intended to do so, but it completely slipped my mind when typing... Thanks for reminding me....

Similarly, there should be references for these attributes added to the error-handling draft.

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Jan 2012 18:53:06 -0500

Thank you.

I have just uploaded a new version with this text slightly changed, please confirm that this version is still acceptable to you.

Keyur also pointed out that AS numbers show up in all sorts of other places (as an example, AS specific Extended Communities) -- as they may show up in yet more places as BGP gets extended I also inserted some fairly generic text saying that you SHOULD handle these as malformed and respond appropriately. While not ideal, I think it is OK.

W

> Similarly, there should be references for these attributes added to the error-handling draft.

---
Don't be impressed with unintelligible stuff said condescendingly .
    -- Radia Perlman.

Warren Kumari
[email-masked]

---

From: Tony Tauber <[email-masked]>
Date: Tue, 10 Jan 2012 23:21:04 -0500

A zero in the "ASN portion" of a community value may not be a good practice
in that it may be harder to figure out who injected it, but I don't think
it needs to be considered an error from a software processing point of view.

Tony

On Tue, Jan 10, 2012 at 6:53 PM, Warren Kumari <[email-masked]> wrote:

> I have just uploaded a new version with this text slightly changed, please
> confirm that this version is still acceptable to you.
>
> Keyur also pointed out that AS numbers show up in all sorts of other
> places (as an example, AS specific Extended Communities) -- as they may
> show up in yet more places as BGP gets extended I also inserted some fairly
> generic text saying that you SHOULD handle these as malformed and respond
> appropriately. While not ideal, I think it is OK.
>
>
> W
>
>
> > Regards,
> > Jeff
> >>> 1) Is it really necessary to make AS 0 an error in the AGGREGATOR and
> AS4_AGGREGATOR attributes?  What is the gain?
> >>
> >> I'll double check with co-authors on Monday -- I don't think it is
> strictly necessary to prevent attack, rather it seemed more elegant to
> check AS 0 where ever it occurs.
> >
> similar bugs at one point but the behavior that I can see in a cursory
> check of the code should result in a system AS number being placed there.
> >
> > My recommendation for the as0 draft is that we leave in the current text
> and let the attribute be treated as "malformed" by the error-handling draft.
> >>> 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in
> rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be referenced
> if you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR.
> >>>
> >>
> >> Doh! This was mentioned a few times and I intended to do so, but it
> completely slipped my mind when typing... Thanks for reminding me....
> >

---

From: <[email-masked]>
Date: Thu, 12 Jan 2012 08:45:31 +0000

Hi Warren, Keyur, all,

>From: Warren Kumari >Sent: Wednesday, January 11, 2012 12:53 AM

[...]

>Keyur also pointed out that AS numbers show up in all sorts of other places (as
>an example, AS specific Extended Communities) -- as they may show up in yet
>more places as BGP gets extended I also inserted some fairly generic text
>saying that you SHOULD handle these as malformed and respond appropriately.
>While not ideal, I think it is OK.

Warren, thanks for highlighting the diff on the IDR mailing list.

v02 of the draft adds: "As UPDATE with zero in any other field where an AS number is expected	(for example, "4-Octet AS specific Extended Community" [RFC5668]) SHOULD be treated as malformed and handled appropriately."

1) This is in contradiction with the use of AS number 0 for "well known" / IANA assigned communities. Both regular ones as defined in RFC 1997 and extended ones as defined in draft-ietf-idr-reserved-extended-communities. So at the minimum, these 2 usages must be allowed.

2) More generally, I tend to disagree with this addition:
- for existing fields, this document should specify where the use of AS 0 is accepted or not (and hence treated as error). (for simplicity, I guess it's enough to defined fields when it's not accepted)
- for future fields, IMO this document should only call for asking further specifications to define what should be the behavior with AS 0.

And for existing fields, IMHO, this document should be conservative with regards to its change on existing specifications. IMHO it should only forbid the use of AS 0 when necessary (for your new use case).
As an another example, I don't think treating as an error a BGP/MPLS VPN route having an AS 0 in its Route Target or Route Distinguisher field is a good idea. This may unexpectedly withdraw VPN routes in some live networks. And I don't see a reason for this.

Thanks,
Regards,
Bruno

PS: Obviously my comment also applies to the following v02 addition "A BGP speaker SHOULD NOT generate or propagate an UPDATE with zero in any field where an AS number is expected (for example,	"4-Octet AS specific Extended Community" [RFC5668])

>>> I'll double check with co-authors on Monday -- I don't think it is strictly
>necessary to prevent attack, rather it seemed more elegant to check AS 0 where
>ever it occurs.
>>
>probably excessive, I think the recommended behavior is desirable.  The mandate
>that the error-handling draft procedures must be used makes it acceptable.
>Without those procedures, bouncing the session is almost certainly the wrong
>thing to do.
>>
>selected to be placed in the aggregator AS field.  JunOS may have had similar
>bugs at one point but the behavior that I can see in a cursory check of the
>code should result in a system AS number being placed there.
>>
>rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be referenced if
>you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR.
>>>>
>>>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: Enke Chen <[email-masked]>
Date: Thu, 12 Jan 2012 09:52:40 -0800

Hi, Bruno:

This is really well said, and I share the same concern:

      And for existing fields, IMHO, this document should be conservative with regards to its
      change on existing specifications. IMHO it should only forbid the use of AS 0 when necessary
      for your new use case).

So far I have not seen much justifications (nor need) for expanding 
error conditions of AS 0 beyond the AS_PATH / AS4_PATH.

Thanks.   -- Enke

On 1/12/12 12:45 AM, [email-masked] wrote:
> Hi Warren, Keyur, all,
>
>> From: Warren Kumari>Sent: Wednesday, January 11, 2012 12:53 AM
> [...]
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Jan 2012 13:13:43 -0500

> error conditions of AS 0 beyond the AS_PATH / AS4_PATH.

I also agree.  I think the text as written tends to violate the Robustness
principle.

-- Jeff

---

From: Jie Dong <[email-masked]>
Date: Fri, 13 Jan 2012 01:27:59 +0000

Hi Bruno, 

> And for existing fields, IMHO, this document should be conservative with
> regards to its change on existing specifications. IMHO it should only forbid the
> use of AS 0 when necessary (for your new use case).

> As an another example, I don't think treating as an error a BGP/MPLS VPN route
> having an AS 0 in its Route Target or Route Distinguisher field is a good idea.
> This may unexpectedly withdraw VPN routes in some live networks. And I don't
> see a reason for this.

Also agree with this. Should be conservative with changes to existing fields.

Regards,
Jie

---

From: Russ White <[email-masked]>
Date: Thu, 12 Jan 2012 20:29:13 -0500

+1

:-)

Russ