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

[Tony Tauber <[e-mail]>]

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 <[e-mail]> wrote:

>
> On Jan 4, 2012, at 8:51 PM, Jeff Tantsura wrote:
>
> > +1
> >
>
> 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
>
>
> > 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
>