Subject: [sidr] origin attribute

From: Randy Bush <[email-masked]>
Date: Tue, 23 Oct 2012 10:14:27 -0500

sandy asked so i investigated.

bgp has an origin atttribute.  it looks as if we need to protect it.

the origin attribute may have three values, 
  unspecified
  igp
  egp
supposedly denoting from where the route was injected into bgp.

jeff haas has a better memory than i, and noted that

the key is that 'egp' does not mean an abstract egp, but the old egp
protocol which was classful and aggregated.

if it aggregated, you had to be careful that this did not suddenly hide
things and ignorance thereof could open you up to loops.  so the origin
attribute was added.

but it is in the bgp decision process.  it is prettly low down, but
could be used for traffic engineering or other, less nice, influencing
of the decision process.

hence, bgpsec should probably should protect it.

randy

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 23 Oct 2012 17:36:50 +0200

randy,

do we really want to go down that road:
i mean do we want to protect all the attributes which ever could
affect BGPs path decision process ?

/hannes

On Oct 23, 2012, at 5:14 PM, Randy Bush wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 23 Oct 2012 16:13:57 +0000

The issue is: once it's signed, it can't be removed. (you could always add another one, but that would change BGP significantly).
"origin" does not seem to be an attribute subject to change.

--
Jakob Heitz.

---

From: Danny McPherson <[email-masked]>
Date: Tue, 23 Oct 2012 16:05:20 -0400

> could be used for traffic engineering or other, less nice, influencing

s/could be/is/

> hence, bgpsec should probably should protect it.

Agreed.  

I would also note that this has been brought up here many times (e.g., [1]), glad to see folks giving it consideration now, and hoping it can find it's way into a future threats document.

-danny

[1] http://www.ietf.org/mail-archive/web/sidr/current/msg03464.html

---

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Oct 2012 16:44:23 -0400

> could be used for traffic engineering or other, less nice, influencing

Yes. And it *is* used for TE purposes in simple places...

> hence, bgpsec should probably should protect it.

Not sure I agree with this part -- simply because it can be used in the decision process doesn't automatically mean it needs to be protected. It (and med and IGP cost and routerID) "feel" to me like they are low enough down that they can be (and should be) left alone, to allow operators some flexibility (Yes, Origin is set by the originator, the rest of these things are more about the local network, but I still don't think that this automatically means that it needs to be protected).

By allowing folk to turn (ok, stomp all over :-)) the setting of Origin those folk that have networks with more than one AS can influence their inbound, folk who want the ability to chance things further down in the decision process still have that, etc…

W

--
She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name".

    -- (Terry Pratchett, Maskerade)

---

From: Randy Bush <[email-masked]>
Date: Tue, 23 Oct 2012 16:00:42 -0500

>> hence, bgpsec should probably should protect it.

i should admit to trolling

> By allowing folk to turn (ok, stomp all over :-)) the setting of
> Origin those folk that have networks with more than one AS can
> influence their inbound, folk who want the ability to chance things
> further down in the decision process still have that, etc…

ty for tech arg.  makes sense.

well, it's kinda how far down a slippery slope we wanna go.  i actually
have no strong opinion, so just trolling.

randy

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 23 Oct 2012 21:04:33 +0000

>I would also note that this has been brought up here

Reviewing that was what led to my question to Randy.  (something like "what is the reason for having ORIGIN  in the first place".)

The responses when this came up in the past have been that protecting integrity of ORIGIN might be conceivable, but the authenticity of the value was not.  That is, who says that the AS did indeed get the info from EGP.  Sounds like at one time, that mattered.

To consider this a threat, we would need to decide what attacks are of interest.  Is corruption the only concern?  Is spoofing a value (mis-ORIGIN-ing) a concern?  If authenticity of the value is a concern, who could be an authority to attest to the authenticity?  And so forth.

--Sandy, speaking as regular ol' member

________________________________________
From: [email-masked] [[email-masked]] on behalf of Danny McPherson [[email-masked]]
Sent: Tuesday, October 23, 2012 4:05 PM
To: sidr wg list
Subject: Re: [sidr] origin attribute

s/could be/is/

Agreed.

-danny

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 23 Oct 2012 17:05:33 -0400

> "origin" does not seem to be an attribute subject to change.

In theory you're right, if the attribute were being used as originally envisioned. In practice, as Warren points out, you're not because it's not. People do set Origin once the route is in flight, as a handy low-order policy thing they can fiddle with. 

BGPSec protecting Origin would stomp on current operational practice, so it would need to be justified more strongly than "seemed like a good idea at the time".

--John

---

From: Danny McPherson <[email-masked]>
Date: Tue, 23 Oct 2012 17:21:05 -0400

> Reviewing that was what led to my question to Randy.  (something like "what is the reason for having ORIGIN  in the first place".)

Nice :-)

> The responses when this came up in the past have been that protecting integrity of ORIGIN might be conceivable, but the authenticity of the value was not. That is, who says that the AS did indeed g…

I don't understand, if the origin router employs , say, a BGPsec Router Certificate to sign the origin code attribute, whom else would attest to such a thing?

Of course, if the origin BGP router was iBGP only  (which _very often is) or non-BGPSec this could be a problem -- that's why we need to start with threats and requirements.  

This whole "only some BGP speaking routers will be running this extension" gives me concerns for other reasons I suspect will surface as well.

-danny
!DSPAM:50870a2e120619193911432!

---

From: Danny McPherson <[email-masked]>
Date: Tue, 23 Oct 2012 17:25:51 -0400

> BGPSec protecting Origin would stomp on current operational practice, so it would need to be justified more strongly than "seemed like a good idea at the time".

What does this mean?  What operational practice?  

-danny

!DSPAM:50870b4d120611733092591!

---

From: Danny McPherson <[email-masked]>
Date: Tue, 23 Oct 2012 17:33:16 -0400

> Not sure I agree with this part -- simply because it can be used in the decision process doesn't automatically mean it needs to be protected. It (and med and IGP cost and routerID) "feel" to me lik…

Where do you draw that line?  Where do you force attackers to move when you draw the line and what's the impact?  An origin AS wanting to  protect the origin code integrity seems perfectly sensible to me, else upstream ASes can effect not what they meant, but what they said, and drive more traffic across links that they manage, or move traffic, and that's a real problem that exists today that we ought to be able to accommodate.

-danny

!DSPAM:50870d09120615471543354!

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 23 Oct 2012 21:49:22 +0000

Thanks John. That's the comment I was fishing for.

--
Jakob Heitz.

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]] 
> Sent: Tuesday, October 23, 2012 2:06 PM
> To: Jakob Heitz
> Cc: Hannes Gredler; sidr wg list
> In theory you're right, if the attribute were being used as 
> originally envisioned. In practice, as Warren points out, 
> you're not because it's not. People do set Origin once the 
> route is in flight, as a handy low-order policy thing they 
> can fiddle with. 
> 
> BGPSec protecting Origin would stomp on current operational 
> practice, so it would need to be justified more strongly than 
> "seemed like a good idea at the time".
> 
> --John
>

---

From: Shane Amante <[email-masked]>
Date: Tue, 23 Oct 2012 16:03:33 -0600

Danny,

> What does this mean?  What operational practice?  

I suspect John is referring to the operational practice employed by some networks, right now, whereby they overwrite ORIGIN during receipt of an UPDATE into their network to 'normalize' ORIGIN to a consistent value.  This is especially valuable in cases where one network, A, is multi-homed to an adjacent network, B, and network A may not be announcing a consistent set of BGP path attributes associated with a set of IP prefixes at all locations.  Ultimately, this practice allows network B to consistently skip over ORIGIN and, instead, evaluate more well-understood BGP Path Selection criteria like MED's, IGP metric, etc. across the full set of "common" BGP routes, (i.e.: those with the same AS_PATH, LOCAL_PREF, etc.), learned across all exit points to network B.

Oh, and FWIW, I agree with the sentiment that "securing" BGP ORIGIN in BGPSEC is a bad idea, for the very reason that I've stated above and others have provided on the list.  

-shane

P.S. -- I would like to coin the saying: "The difference between theory and practice in BGP is, in practice, BGP works in today's Internet, because it's not confined by any theory." :-)

> -danny

!DSPAM:50871436120611221711528!

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 24 Oct 2012 08:11:32 +0000

Hi Shane,

I always found this presentation very instructive to educate on the practice you are describing: http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTIwMCZuYW5vZzQ1&nm=nanog45

I agree that this is common practice, particularly between content operators.

Roque

---

From: Danny McPherson <[email-masked]>
Date: Wed, 24 Oct 2012 11:11:12 -0400

On Oct 23, 2012, at 6:03 PM, Shane Amante wrote:

> I suspect John is referring to the operational practice employed by some networks, right now, whereby they overwrite ORIGIN during receipt of an UPDATE into their network to 'normalize' ORIGIN to a consistent value.

Ironically, if "normalize[ing] ORIGIN to a consistent value" at an upstream AS results in a change to the ORIGIN code for a given path, you've _created INconsistent ORIGIN codes for the prefix in the routing system.  I suppose I understand why this might be desirable for a transit network provider, but as an edge AS I'd prefer to not have intermediate networks changing the values I set.
 
>  This is especially valuable in cases where one network, A, is multi-homed to an adjacent network, B, and network A may not be announcing a consistent set of BGP path attributes associated with a set of IP prefixes at all locations.  Ultimately, this practice allows network B to consistently skip over ORIGIN and, instead, evaluate more well-understood BGP Path Selection criteria like MED's, IGP metric, etc.
> across the full set of "common" BGP routes, (i.e.: those with the same AS_PATH, LOCAL_PREF, etc.), learned across all exit points to network B.

I'm pretty sure MEDs and "IGP metric" are far more ambiguous and broken in practice than ORIGIN code (e.g., [1]), especially when comparing across paths learned from different adjacent ASes.

-danny

[1] <http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njk2Jm5hbm9nMjk=&nm=nanog29>

---

From: Shane Amante <[email-masked]>
Date: Wed, 24 Oct 2012 10:53:58 -0600

Danny,

> Ironically, if "normalize[ing] ORIGIN to a consistent value" at an upstream AS results in a change to the ORIGIN code for a given path, you've _created INconsistent ORIGIN codes for the prefix in t…

Fair enough.  In my defense :-), RFC 4271 does state that ORIGIN code "SHOULD NOT" be changed by any other speaker <http://tools.ietf.org/html/rfc4271#section-5.1.1>.  Fortunately, it doesn't say: "MUST NOT".  :-)

Perhaps a better question should be: is ORIGIN code still required, particularly from a BGP path selection perspective, in today's networks?  I would say "no".  (If you wanted to know the 'source' of a BGP route, there are already a plethora of BGP communities to help operators narrow this down ... but, this is more for convenience of troubleshooting, it doesn't need to be in path selection).

IOW, instead of "securing" ORIGIN, maybe folks should be looking at deprecating it?  IMO, this would have likely been a far more productive use of time than the deprecation of AS_SET's, (the latter of which I still maintain was a bad idea, done primarily for convenience w/out adequate consideration of it's _long-term_ usefulness).

> I'm pretty sure MEDs and "IGP metric" are far more ambiguous and broken in practice than ORIGIN code (e.g., [1]), especially when comparing across paths learned from different adjacent ASes.

FWIW, I wasn't actually referring to to MED or IGP metric comparison across different AS_PATHs, rather MED or IGP metric comparison across same AS_PATHs.

Regardless, your point is valid that comparison of MED's, even just across the same AS_PATH, is oftentimes fraught with operational headaches/brokenness.  However, in defense of MED's :-), I believe that the root cause problem here is, most likely, an inability (or, worse, unwillingness) for the network sending MED's to continually fine-tune not only the MED value(s), but at the same time (just as importantly) to __intelligently__, (i.e.: only when necessary), deaggregate [very] large prefixes in order that more relevant MED values can be targeted at those more specifics resulting in better 'signals' toward upstream networks.  Then again, we might agree to disagree on this.   :)

To the larger point of going back to actual requirements for this work, then why hasn't there been discussion in the requirements or threats documents about 'securing':
- ORIGIN
- NEXT_HOP: third-party NEXT_HOP at IXP's anyone?
  BTW, I would note that the above would be an extremely clever way to divert traffic through a bad guy's network that would be completely invisible within the AS_PATH, (but could show up in traceroutes).  w00t!
- MED's
- BGP communities: which are quite commonly used to manipulate an upstream's BGP path selection algorithm (i.e.: raise/lower LOCAL_PREF) and/or _scope_ the announcement toward adjacent ASN's/routers, (i.e.: no-export, no-advertise, being the two standards-based ones)?

... not even a mention of being "out-of-scope" and for what reason(s), even though draft-ietf-sidr-bgpsec-reqs-05 states: "As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this work is limited to threats to the BGP protocol."  

Then again, there still isn't a serious acknowledgement that 'route leaks' are, in fact, a much more serious "threat to the BGP protocol", than manipulation of most of those BGP attributes even though the route-leaks problem has been crisply defined in 1.5 pages:
http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01
... with further elaboration in this and associated drafts:
http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-03

<sigh>

-shane

---

From: heasley <[email-masked]>
Date: Wed, 24 Oct 2012 16:58:07 +0000

> IOW, instead of "securing" ORIGIN, maybe folks should be looking at deprecating it?  IMO, this would have likely been a far more productive use of time than the deprecation of AS_SET's, (the latter…

its used as a "TE" knob, whether danny likes it or not.  given the lack of
TE knobs, a lot of hatred should be expected if its taken away (deprecated or
"secured").

---

From: Danny McPherson <[email-masked]>
Date: Wed, 24 Oct 2012 13:09:59 -0400

On Oct 24, 2012, at 12:58 PM, heasley wrote:

> its used as a "TE" knob, whether danny likes it or not.  

I didn't say I disliked it.  I said that I disliked intermediate ASNs manipulating the values an originating AS configured, because it has system wide implications and could impact things that were expressly intended by the originator of the route.

As a matter of fact, a mandatory transitive attribute provides a nice capability for an operator to influence ingress traffic from upstream ASes multiple hops away -- and I certainly have realized utility from that in the past.

-danny

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Oct 2012 13:46:37 -0400

On Wed, Oct 24, 2012 at 12:58 PM, heasley <[email-masked]> wrote:
>
> its used as a "TE" knob...

[snip].

 given the lack of
> TE knobs, a lot of hatred should be expected if its taken away (deprecated

Just to educate anyone who is not familiar with *why* it is used, I'll
explain the most common *how*:

Since it has 3 possible values, and is used immediately after
as-path-length in the BGP path selection process,
it can be treated as a "fractional" as-path-length value (0/3, 1/3, or 2/3)
for breaking ties in as-path-length.

If two received routes for the same prefix/length have the same
as-path-length, and the same ORIGIN attribute, the ORIGIN is effectively
ignored.
If the ORIGIN attribute differs, then ORIGIN breaks the tie, and no other
attributes are compared (only with respect to those two routes, of course).

One way I've seen it used, is in an attempt to influence return traffic
along the same path as sent traffic, e.g. to achieve non-asymmetric traffic
flows.
These are helpful in identifying (and avoiding) high latency/loss links not
directly under one's control.

The places this is most commonly done are:
By the originator
By the originator's upstream transit provider(s) (or their providers,
etc.), who is/are not default-free
By the recipients' upstream transit provider(s).
By the recipient

In the case of the recipient, he/she is clearly free to munge it *after*
all BGPSEC validation is done.
So only the other three cases need to be taken into consideration.

Maybe there should be a way to optionally include attributes to sign &
protect?
This would be a good candidate.
First one to stomp on it and sign it wins.

Brian