Re: [Idr] draft-ietf-idr-as0-02

[Enke Chen <[e-mail]>]

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, [e-mail] wrote:
> 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])
>
>> W
>>
>>
>>> Regards,
>>> Jeff
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Jeffrey
>> Haas
>>> Sent: Wednesday, January 04, 2012 5:46 PM
>>> To: Warren Kumari
>>> Cc: [e-mail]; [e-mail]
>>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
>>>
>>> [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
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>>
>> ---
>> Don't be impressed with unintelligible stuff said condescendingly .
>>     -- Radia Perlman.
>>
>> Warren Kumari
>> [e-mail]
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr