May a tier1 transit change bgp origin attribute?
Dear WG, We (ACOnet, the Austrian NREN, AS1853) do have several upstreams. More or less per random we detected that one of them delivers prefixes with a different route origin parameter (IGP instead of incomplete) than others. This obviously has a big influence in the BGP best-path selection. After asking why this is the case we learned from them: On 28.11.13 10:32, support@xxx.com wrote:>
Hi Harald,
The XXX standard route map sets origin IGP as standard across all customer learned routes...
Now we are currently debating with them whether this is ok or not. We are arguing that the origin is an attribute that _only_ the originating AS can set and that transit providers _must not_ change that. Especially on (not even cheap) paid upstream connections from a tier1. Now we would be interested what the routing-community thinks about that. Are we picky or do they breaching best current practices? Has anyone else (had) the same issues? Any feedback is appreciated. Cheers, Harald -- Harald Michl <harald.michl@univie.ac.at> Vienna University - ACOnet www.ACO.net - VIX www.VIX.at Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe Tel: +43 1 4277 - 14078 (Fax: - 814078) HM3550-RIPE
On Fri, Dec 13, 2013 at 08:31:39PM +0100, Harald Michl wrote:
We (ACOnet, the Austrian NREN, AS1853) do have several upstreams. More or less per random we detected that one of them delivers prefixes with a different route origin parameter (IGP instead of incomplete) than others. This obviously has a big influence in the BGP best-path selection. After asking why this is the case we learned from them:
On 28.11.13 10:32, support@xxx.com wrote:>
Hi Harald,
The XXX standard route map sets origin IGP as standard across all customer learned routes...
Now we are currently debating with them whether this is ok or not.
For me the igp attribute falls in same category as MED. If your routing policy is not to accept MEDs (thus rewriting them), you should for consistency purposes, also reset route origin attribute. It is likely your upstream is resetting the origin to draw more traffic towards themselves. To level the playing field in your case, it might be beneficial to reset origin on outbound advertisement across all your upstreams. Kind regards, Job
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Job, On 13.12.13 21:08, Job Snijders wrote:
On Fri, Dec 13, 2013 at 08:31:39PM +0100, Harald Michl wrote:
We (ACOnet, the Austrian NREN, AS1853) do have several upstreams. More or less per random we detected that one of them delivers prefixes with a different route origin parameter (IGP instead of incomplete) than others. This obviously has a big influence in the BGP best-path selection. After asking why this is the case we learned from them:
On 28.11.13 10:32, support@xxx.com wrote:>
Hi Harald,
The XXX standard route map sets origin IGP as standard across all customer learned routes...
Now we are currently debating with them whether this is ok or not.
For me the igp attribute falls in same category as MED. If your routing policy is not to accept MEDs (thus rewriting them), you should for consistency purposes, also reset route origin attribute.
Of course we could rewrite all origin attributes to be the same. But that's like removing it from the best-path calculation. (this is not a problem, just a conclusion)
It is likely your upstream is resetting the origin to draw more traffic towards themselves. To level the playing field in your case, it might be beneficial to reset origin on outbound advertisement across all your upstreams.
Yes attracting more traffic could be a reason. But I think there is no reason why someone _has to_ rewrite the origin parameter. So I'd expect this data set by origin not to be changed during the bgp propagation. I also wonder which attributes will be signed in a more secure BGP environment in the long run. If the origin attribute is going to be one of these parameters then signature-checks will/would fail... - -Harald
Kind regards,
Job
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKsKZsACgkQszNfQwh3cvRyKwCeL2viSzvpvd1Jy3Nf8q2Gu4wY XZwAoPNxBf4enTMtI1be9NnHIYPUPkqf =2/dl -----END PGP SIGNATURE-----
Hi Harald, On Dec 14, 2013, at 4:49 AM, Harald Michl <harald.michl@univie.ac.at> wrote:
I also wonder which attributes will be signed in a more secure BGP environment in the long run. If the origin attribute is going to be one of these parameters then signature-checks will/would fail...
This has been addressed already in SIDR WG: "A chair consensus statement on the BGP ORIGIN Attribute The ORIGIN attribute has been discussed in the working group several times. One view is that the ORIGIN attribute, according to the BGP specification, is supposed to be set at the originating AS and “SHOULD NOT” be reset by other ASs. In this view, changing the ORIGIN was a threat of traffic attraction and so the source authentication and integrity of this attribute should be protected throughout its propagation. The opposing view was that the original purpose for this attribute (ie, conveying the state at the originating AS) has been obsolete for a very long time, and that operators have re-purposed this attribute to their use and that that use (altering the ORIGIN) was legitimate, common and important to them. In this view, altering the ORIGIN should not be prohibited by the security protections. The rough consensus of the working group is that the current operational use and the ability to change the ORIGIN attribute should not be included in the threats that must be countered by the security protections. --Sandy, speaking for the co-chairs” http://www.ietf.org/mail-archive/web/sidr/current/msg06013.html Cheers, -dorian
This has been addressed already in SIDR WG: "A chair consensus statement on the BGP ORIGIN Attribute
perhaps a short i-d would be useful and no, i am not volunteering :) randy
participants (4)
-
Dorian Kim -
Harald Michl -
Job Snijders -
Randy Bush