Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath

Wed, Mar 28, 2012 at 05:00:43PM +0000, Murphy, Sandra:
> Replacing ASs in the AS_PATH sounds like a behavior you would want the security protections to prohibit.  It would enable attacks.
> 
> Can you explain how you would distinguish legitimate uses of this feature?

I've not used this feature, but from cisco's documentation, it doesnt appear
to function as raszuk described.

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html

if local-as is configured for a peer(-group), ie: if configured to peer as
a different AS than your own, such as for merging two ASes or changing your
ASN, then:
"The replace-as keyword is used to prepend only the local autonomous-system number (as configured with the ip-address argument) to the AS_PATH attribute. The autonomous-system number from the local BGP routing process is not prepended."

though I think that is unclear, I interpret it to mean that if my ASN is 1
and, I peer as ASN 2 with ebgp peer 3, then a route received from AS 3 will
have the path [2 3], but if configured with replace-as, it will be [3].

I do not believe that the feature allows the arbitrary replacement of AS path
elements.

> --Sandy
> 
> ________________________________________
> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Raszuk [robert@raszuk.net]
> Sent: Wednesday, March 28, 2012 12:43 PM
> To: Christopher Morrow
> Cc: idr@ietf.org List; Paul Jakma; sidr wg list
> Subject: Re: [sidr] [Idr]  AS_SET depreciation (RFC6472) and BGP multipath
> 
> >> Are we going to freeze any AS_PATH modifications by operator's policy too ?
> >> I mentioned replace-as which all major vendors support. There can be more
> >> knobs like this coming in the future.
> >
> > replace as i think is dealt with .... sign again and pcount=0 and move along.
> 
> replace-as allows to replace any arbitrary match of list of ASes in the
> AS_PATH by your own AS. Does not need to be the last one.
> 
> I don't think SIDR has a solution to deal with such policy.
> 
> Best regards,
> R.
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr