Subject: [sidr] ORIGINs

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 8 Mar 2013 18:10:07 +0000

In reviewing the discussions about the threat document, the wg eventual consensus wrt one topic was not clear to the chairs.

The ORIGIN attribute was mentioned by some as having the potential to be used out-of-spec to influence routing through the neighbor (and their neighbors, etc.).

One response was that there is no way to verify the authenticity of the ORIGIN's original value, so the origin AS could mis-use this attribute no matter what we do.

Also, a later discussion pointed out that the original need for the ORIGN attribute had long since been OBE, but that ISPs had re-purposed the attribute for influencing traffic.  Several operators mentioned that ISPs find it useful to modify this attribute and spoke against protecting the integrity (ie preventing the modification).

The current draft does not mention the ORIGIN attribute as a threat.

Is that the right outcome?  That is, was the desired outcome:

(1)  yes, we know it is a threat but we know we can't & don't want to protect it, so might as well leave it out.   (current state). why do make-work.

(2)  we should mention it as a threat but then mention the bits about can't authenticate the original value and don't want to protect the integrity (ie want to permit modification).

If there's no interest in changing, the threats draft stands as it is on this point.

--Sandy

---

From: Danny McPherson <[email-masked]>
Date: Sun, 10 Mar 2013 10:00:53 -0600

On 2013-03-08 11:10, Murphy, Sandra wrote:
> In reviewing the discussions about the threat document, the wg
> eventual consensus wrt one topic was not clear to the chairs.
>
> The ORIGIN attribute was mentioned by some as having the potential to
> be used out-of-spec to influence routing through the neighbor (and
> their neighbors, etc.).
>
> One response was that there is no way to verify the authenticity of
> the ORIGIN's original value, so the origin AS could mis-use this
> attribute no matter what we do.

The origin AS sets the value of the attribute to whatever THEY desire 
-- the concern was that upstream ASes can manipulate this to launch 
"traffic attraction attacks".  This happens today with some of our 
transit providers, and we'd like the option to be able to mitigate that 
attack if we're going to put a bunch of stuff in place to secure 
inter-domain routing on the Internet.

> Also, a later discussion pointed out that the original need for the
> ORIGN attribute had long since been OBE,

Many origin ASes set the value to various upstreams intentionally today 
to impact path selection in upstream ASes, so it is very much in use 
today, even if not for the originally envisaged application.

> but that ISPs had re-purposed
> the attribute for influencing traffic.  Several operators mentioned
> that ISPs find it useful to modify this attribute and spoke against
> protecting the integrity (ie preventing the modification).

Right, that want to be able to exploit traffic attraction attack 
vectors, whereas, as an origin AS I'd like to have the capability to 
prevent that.

> Is that the right outcome?

No.

> That is, was the desired outcome:
>
> (1)  yes, we know it is a threat but we know we can't & don't want to
> protect it, so might as well leave it out.   (current state). why do
> make-work.

It's not make-work, it is a clear threat - you say yourself in the 
question.  It needs to be reflected in the threats draft and 
accommodated in subsequent requirements and solutions work.  We should 
not keep it out of the threat draft simply because the solution does not 
currently accommodate it (we've done lots of that already).

> (2)  we should mention it as a threat but then mention the bits about
> can't authenticate the original value and don't want to protect the
> integrity (ie want to permit modification).

It's a threat, we don't need to have a solution here, we're talking 
about the threats draft.  It should lead to a requirement and then the 
solution can be developed.

> If there's no interest in changing, the threats draft stands as it is

How many times do I need to defend this operational feedback before 
it's considered and accommodate in the threats draft?

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 10 Mar 2013 14:05:14 -0400

On Sun, Mar 10, 2013 at 12:00 PM, Danny McPherson <[email-masked]> wrote:
> The origin AS sets the value of the attribute to whatever THEY desire -- the
> concern was that upstream ASes can manipulate this to launch "traffic
> attraction attacks".  This happens today with some of our transit providers,
> and we'd like the option to be able to mitigate that attack if we're going
> to put a bunch of stuff in place to secure inter-domain routing on the
> Internet.
>
>
> Many origin ASes set the value to various upstreams intentionally today to
> impact path selection in upstream ASes, so it is very much in use today,
> even if not for the originally envisaged application.
>
>
> Right, that want to be able to exploit traffic attraction attack vectors,
> whereas, as an origin AS I'd like to have the capability to prevent that.
>
>
> It's not make-work, it is a clear threat - you say yourself in the question.
> It needs to be reflected in the threats draft and accommodated in subsequent
> requirements and solutions work.  We should not keep it out of the threat
> draft simply because the solution does not currently accommodate it (we've
> done lots of that already).
>
>
> It's a threat, we don't need to have a solution here, we're talking about
> the threats draft.  It should lead to a requirement and then the solution
> can be developed.
>
>
> How many times do I need to defend this operational feedback before it's
> considered and accommodate in the threats draft?

I think the question was a survey sort of question: 'Should this be in
the threats doc? Is the intent to come back and say: "Yes, origin
changes along the path for many reasons, we want to protect against
this." (ie: origin changes are a threat) OR "Yes, origin changes along
the path, we actually want to keep this feature available.'

There were at least 2 people talking about origin, one from either
side I think... so clarification would be good.

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

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 10 Mar 2013 14:05:59 -0400

> side I think... so clarification would be good.

oops, unfinished thought: "your message provides at least 1 bit of
clarification"

would you be interested in providing stephen with some text for the
threats doc about this?

-chris

---

From: "John G. Scudder" <[email-masked]>
Date: Sun, 10 Mar 2013 18:34:08 -0400

Danny and Sandy,

It seems to me that the question of whether an intermediate AS monkeying with ORIGIN is an "attack" or not depends on what one understands the correct and intended operation of ORIGIN to be. The problem is, as you've rightly said, ORIGIN's (ahem) original purpose was obsolete almost as soon as it was introduced, and since then we have decades of uncoordinated operational (ab)use of ORIGIN. I'm not aware of any broad consensus on best practice for the current use of ORIGIN, and I'm sure there's no standard for it, other than what the BGP standard says which is as previously noted, effectively obsolete. 

If I parse Danny's email right, he's saying that he wishes he could rely on ORIGIN to be untouched by intermediate ASes, so that he can use it to "impact path selection" by them. I presume that he's not actually relying on this, though, since the facts on the ground (as he points out) are that various intermediate ASes do adjust the value of ORIGIN.

I'm not aware of any of the operators who do adjust ORIGIN in their networks having spoken up (though I may easily have overlooked some). If correct, I suspect this is simply because they're not following SIDR. However, I don't interpret this silence as meaning that all operators agree that ORIGIN should be immutable once launched.

So, we have the following schools of thought on ORIGIN:

- It's an interdomain policy knob to be used solely by the originator.
- Or, it may be used as an intradomain policy knob by a transit AS.

It's tempting, though futile, to say "a plague on both your houses!", because the standard doesn't say it's either of those things. It does say it "SHOULD NOT be changed by any other speaker", which offers some support for Danny's point of view. But really, spec-lawyers can't convincingly support either approach, since the spec doesn't frame ORIGIN as a policy tool at all.

For my own part, I think twiddling ORIGIN at any point on the path is an abomination and I wish it had never become practice. However, as with so many things about BGP, it's an abomination that HAS become practice, and I think we would be well-advised to be careful in trying to stuff this little genie back into its bottle.

All that said, I guess I prefer Sandy's option (2) -- given there's an identified issue, why not write it down, if only to avoid recapitulating quite so much of this conversation in the future? (And for the sake of this discussion I assume characterizing it as a "threat" uses "threat" as a term of art and not a value judgement -- see my first paragraph above regarding "attack".)

--John

On Mar 10, 2013, at 12:00 PM, Danny McPherson <[email-masked]> wrote:

> The origin AS sets the value of the attribute to whatever THEY desire -- the concern was that upstream ASes can manipulate this to launch "traffic attraction attacks".  This happens today with some of our transit providers, and we'd like the option to be able to mitigate that attack if we're going to put a bunch of stuff in place to secure inter-domain routing on the Internet.
> 
> Many origin ASes set the value to various upstreams intentionally today to impact path selection in upstream ASes, so it is very much in use today, even if not for the originally envisaged application.
> 
> Right, that want to be able to exploit traffic attraction attack vectors, whereas, as an origin AS I'd like to have the capability to prevent that.
> 
> It's not make-work, it is a clear threat - you say yourself in the question.  It needs to be reflected in the threats draft and accommodated in subsequent requirements and solutions work.  We should not keep it out of the threat draft simply because the solution does not currently accommodate it (we've done lots of that already).
> 
> It's a threat, we don't need to have a solution here, we're talking about the threats draft.  It should lead to a requirement and then the solution can be developed.
> 
> How many times do I need to defend this operational feedback before it's considered and accommodate in the threats draft?
> 
> -danny
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Mar 2013 15:31:08 -0400

Danny,

We have been told by several operators that the values stated in Section 
4.3 of RFC 4271 are not what is used today. We also have been told that, 
contrary to the "SHOULD NOT" in Section 5.1.1 of this RFC, it is not 
uncommon for ASes to change this value, en route. Given these two 
observations, I don't see how one can argue that protecting this 
attribute via a PATHSEC mechanism makes sense.

Separately, there is the issue of whether it makes sense to address the 
security of the ORIGIN attribute in the threats document. The SIDR 
charter states that the path security goal is "Is the AS-Path 
represented in the route the same as the path through ?which the NLRI 
traveled" There are a variety of other attributes that do not directly 
support this goal, and which are not being addressed as part of the 
PATHSEC model. The threats document already addresses this issue, in the 
Residual Vulnerabilities section. I suggest the following updated text 
for that section, to better explain the criteria for inclusion and 
exclusion in that document:

PATHSEC is not planned to protect all attributes associated with an 
AS_PATH,even though some of these attributes may be employed as inputs 
to routing decisions.Thus attacks that modify (or strip) these other 
attributes are not prevented/detected by PATHSEC.The SIDR charter calls 
for protecting only the info needed to verify that a received route 
traversed the ASes enumerated in the AS_PATH, and that the NLRI in the 
route is what was advertised.(The AS_PATH data also may have traversed 
ASes within a confederation that are not represented. However, these 
ASes are not externally visible, and thus do not influence route 
selection, so their omission in this context is not a security concern.) 
Thus, protection of other attributes is outside the scope of the 
charter, at the time this document was prepared.

---

From: heasley <[email-masked]>
Date: Mon, 11 Mar 2013 20:46:23 +0000

> inter-domain routing on the Internet.

Whether anyone likes it, it has become a TE knob of sorts, in a protocol
with few such knobs, and many smaller transit providers rely upon it to
affect route selection for non-malicious reasons, such as to balance their
own transit links.  Without providing an alternative, it will be crippling
to many to inhibit its use as such.

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Mar 2013 15:45:17 -0700

heas,

> to many to inhibit its use as such.

that is not exactly the qestion, thought i gives a hint.  by "smaller
transit providers rely on it" do you mean that the value is legitimately
set or altered by other than the originating AS?  if so, then signing it
would be bad.  if not, it could be good.  so could you please clarify?

randy

---

From: heasley <[email-masked]>
Date: Mon, 11 Mar 2013 22:47:38 +0000

> would be bad.  if not, it could be good.  so could you please clarify?

that is exactly what I am implying/saying.

---

From: Matthew Lepinski <[email-masked]>
Date: Mon, 11 Mar 2013 18:59:32 -0400

I do not have an opinion about what in particular the Threats document
should say (or not say) about the ORIGIN attribute. However, I am quite
concerned about potential hurdles to BGPSEC deployment. It appears that
breaking a current (non- standard) use of ORIGIN had little if any benefit
since no one seems to use ORIGIN for its originally intended purpose.
Therefore, I would like not create a new reason for some operators to
deploy BGPSEC.

-Matt L.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 11 Mar 2013 23:04:44 +0000

>Therefore, I would like not create a new reason for some operators to deploy BGPSEC.

>From the tone of the remarks preceding this sentence, it seems that you might have misplaced a "not" in here somewhere.

Could you clarify?

--Sandy

---

From: Matthew Lepinski <[email-masked]>
Date: Mon, 11 Mar 2013 20:33:03 -0400

I am sorry.

"I do not want to sign ORIGIN if doing so will create a new obstacle to
deploying BGPSEC"
On Mar 11, 2013 7:05 PM, "Murphy, Sandra" <[email-masked]> wrote:

>  From the tone of the remarks preceding this sentence, it seems that you
> might have misplaced a "not" in here somewhere.
>
>  Could you clarify?
>
>  --Sandy
>
>>
>>

---

From: Danny McPherson <[email-masked]>
Date: Mon, 11 Mar 2013 21:17:31 -0600

On 2013-03-11 18:33, Matthew Lepinski wrote:
> I am sorry.
>
> "I do not want to sign ORIGIN if doing so will create a new obstacle
> to deploying BGPSEC"

And I'm saying that the ability (i.e., option) to protect the ORIGIN as 
set by the originating AS is IMO one reason that's a positive to deploy 
BGPSEC for me (i.e., to minimize traffic attraction attacks and hose me 
as a stub for the ASes we have that are stub ASes).  If 84% of the ASes 
are stubs, I gotta believe some of the others would agree with this, 
while I certainly understand why intermediate ASes want to muck with it.

If others disagree, well, I'm at peace with that...

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 11 Mar 2013 21:34:30 -0600

On 2013-03-11 13:31, Stephen Kent wrote:
> Danny,
>
>  We have been told by several operators that the values stated in
> Section 4.3 of RFC 4271 are not what is used today. We also have been
> told that, contrary to the "SHOULD NOT" in Section 5.1.1 of this RFC,
> it is not uncommon for ASes to change this value, en route. Given
> these two observations, I don't see how one can argue that protecting
> this attribute via a PATHSEC mechanism makes sense.

84% of ASes are stubs, apparently.  Many of our own ASes are stubs and 
we buy transit services in some places from some of the ISPs that like 
to muck with the ORIGIN code to exploit traffic attraction attacks. I'd 
like a secure routing protocol to be derived from requirements that 
accommodate issues that both ISPs and stub ASes are concerned with.  
That's what I'd like as an operator. If this is yet another thing that 
you believe is beyond the scope of SIDR because the current BGPSEC spec 
doesn't accommodate it then why don't we stop pretending to be writing 
threats and requirements documents and you just publish your BGPSEC 
spec?

>  Separately, there is the issue of whether it makes sense to address
> the security of the ORIGIN attribute in the threats document. The 
> SIDR
> represented in the route the same as the path through  which the NLRI
> traveled"

Careful, I'm not sure the current BGPSEC spec does that at all for the 
"AS_PATH", and it actually diverges in some places.  If you're going to 
use the charter again to nix this requirement as an acceptable residual 
vulnerability in the threats draft then it's crystal clear to me that 
you and the BGPSEC design team simply want to publish the BGPSEC draft 
as you've already envisioned and you don't want to accommodate my 
operational requirements.  If that's the case then let's just kill the 
threats and requirements documents and save everyone's time.

> There are a variety of other attributes that do not directly
> PATHSEC model.

Right, and I think they should be, as they all impact BGP path 
selection in various ways.

> The threats document already addresses this issue, in
> the Residual Vulnerabilities section.

Out of curiosity, does anyone intend to ever address the growing list 
of "residual vulnerabilities" or is this merely a place to catalog 
requirements that would rather not be addressed?

> I suggest the following updated
> text for that section, to better explain the criteria for inclusion
> and exclusion in that document:
>
> AS_PATH, even though some of these attributes may be employed as
> inputs to routing decisions. Thus attacks that modify (or strip) 
> these
> other attributes are not prevented/detected by PATHSEC. The SIDR
> charter calls for protecting only the info needed to verify that a
> received route traversed the ASes enumerated in the AS_PATH, and that
> the NLRI in the route is what was advertised. (The AS_PATH data also
> may have traversed ASes within a confederation that are not
> represented. However, these ASes are not externally visible, and thus
> do not influence route selection, so their omission in this context 
> is
> not a security concern.) Thus, protection of other attributes is
> outside the scope of the charter, at the time this document was
> prepared.

Again, I'd like some clarity on how long we're going to hide behind an 
explicitly worded charter, or if we're actually going to address any of 
these issues?

-danny

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Mar 2013 09:07:50 -0400

Danny,
> to muck with the ORIGIN code to exploit traffic attraction attacks. 
> I'd like a secure routing protocol to be derived from requirements 
> that accommodate issues that both ISPs and stub ASes are concerned 
> with.  That's what I'd like as an operator. If this is yet another 
> thing that you believe is beyond the scope of SIDR because the current 
> BGPSEC spec doesn't accommodate it then why don't we stop pretending 
> to be writing threats and requirements documents and you just publish 
> your BGPSEC spec?
I am writing a threats doc consistent with the SIDR WG charter. WGs have 
charters to help scope the
set of problems that they address. If the WG recharters to extend the 
scope of what security concerns are to be addressed, then this doc will 
be revised accordingly.
>> the security of the ORIGIN attribute in the threats document. The SIDR
> "AS_PATH", and it actually diverges in some places.  If you're going 
> to use the charter again to nix this requirement as an acceptable 
> residual vulnerability in the threats draft then it's crystal clear to 
> me that you and the BGPSEC design team simply want to publish the 
> BGPSEC draft as you've already envisioned and you don't want to 
> accommodate my operational requirements.  If that's the case then 
> let's just kill the threats and requirements documents and save 
> everyone's time.
I'm sorry that you seem to be uncomfortable working within the WG charter.
> requirements that would rather not be addressed?
The previous bullet in this section deals with route leaks, and says:

       If, at a latertime, the SIDR charter is amended to include route 
leaks, and an

appropriate definition exists, this document should be revised.

I'm happy to add an analogous sentence to this bullet as well.
>> inputs to routing decisions. Thus attacks that modify (or strip) these
>> do not influence route selection, so their omission in this context is
> explicitly worded charter, or if we're actually going to address any 
> of these issues?
As far as I'm concerned, we're going to follow IETF procedures.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Tue, 12 Mar 2013 07:26:50 -0600

> As far as I'm concerned, we're going to follow IETF procedures.

That charter was intentionally worded when it was written so that the 
solution envisaged would be the only thing worked on here, absent being 
information by any actual threats or subsequent requirements, which are 
being carefully backwards engineered here to the solution that was 
brought into the WG.

Alas....

-danny

---

From: Matthew Lepinski <[email-masked]>
Date: Tue, 12 Mar 2013 09:38:55 -0400

A quick clarification: The current BGPSEC protocol specification can easily
be modified to protect the ORIGIN attribute. (That is, prevent it from
being modified by intermediate ASes.)

I can very quickly put out an update to the BGPSEC protocol specification
if the working group decides that there is a requirement to protect the
ORIGIN attribute.

It is valuable to have this discussion. I am personally sceptical of
preventing the modification of the ORIGIN attribute. However, if others in
the writhing group see value in protecting the ORIGIN attribute, then I
want to know about it. (And it is certainly the case that I understand the
issue better now than I did before this discussion started.)

-Matt Lepinski
On Mar 11, 2013 11:34 PM, "Danny McPherson" <[email-masked]> wrote:

> 84% of ASes are stubs, apparently.  Many of our own ASes are stubs and we
> buy transit services in some places from some of the ISPs that like to muck
> with the ORIGIN code to exploit traffic attraction attacks. I'd like a
> secure routing protocol to be derived from requirements that accommodate
> issues that both ISPs and stub ASes are concerned with.  That's what I'd
> like as an operator. If this is yet another thing that you believe is
> beyond the scope of SIDR because the current BGPSEC spec doesn't
> accommodate it then why don't we stop pretending to be writing threats and
> requirements documents and you just publish your BGPSEC spec?
>
> "AS_PATH", and it actually diverges in some places.  If you're going to use
> the charter again to nix this requirement as an acceptable residual
> vulnerability in the threats draft then it's crystal clear to me that you
> and the BGPSEC design team simply want to publish the BGPSEC draft as
> you've already envisioned and you don't want to accommodate my operational
> requirements.  If that's the case then let's just kill the threats and
> requirements documents and save everyone's time.
>
> Right, and I think they should be, as they all impact BGP path selection
> in various ways.
>
> Out of curiosity, does anyone intend to ever address the growing list of
> "residual vulnerabilities" or is this merely a place to catalog
> ______________________________**_________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 12 Mar 2013 10:21:33 -0400

On Tue, Mar 12, 2013 at 9:38 AM, Matthew Lepinski
<[email-masked]> wrote:
> be modified to protect the ORIGIN attribute. (That is, prevent it from being
> modified by intermediate ASes.)
>
> I can very quickly put out an update to the BGPSEC protocol specification if
> the working group decides that there is a requirement to protect the ORIGIN
> attribute.

I wonder if it's worth protecting it as an option?
In other words protect origin at the origin's discretion.

> preventing the modification of the ORIGIN attribute. However, if others in

it seems like there are thorns to watch out for, for sure... and
mandatory action will certainly have us falling into the thorns minus
protection.

> the writhing group see value in protecting the ORIGIN attribute, then I want

autocorrect or freudian slip? :)

> to know about it. (And it is certainly the case that I understand the issue
> better now than I did before this discussion started.)
>
> -Matt Lepinski
>
>> like as an operator. If this is yet another thing that you believe is beyond
>> the scope of SIDR because the current BGPSEC spec doesn't accommodate it
>> then why don't we stop pretending to be writing threats and requirements
>> documents and you just publish your BGPSEC spec?
>>
>> and the BGPSEC design team simply want to publish the BGPSEC draft as you've
>> already envisioned and you don't want to accommodate my operational
>> "residual vulnerabilities" or is this merely a place to catalog requirements
>> that would rather not be addressed?
>>

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Mar 2013 08:00:16 -0700

> A quick clarification: The current BGPSEC protocol specification can
> easily be modified to protect the ORIGIN attribute. (That is, prevent
> it from being modified by intermediate ASes.)

ops with deep clue and who i respct have spoken.  don't do it.

randy

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 12 Mar 2013 15:23:46 -0400

> In other words protect origin at the origin's discretion.

Although I was skeptical of origin code validation, this seems like another
reasonable alternative.  As an operator, I wouldn't mind the option of only
optionally validating origin code, or conversely on sending side allow those
who choose to have it validated as you suggest take the risk that the only
path in some cases may be dropped by others doing validation (if the majority
of their transit providers are already doing origin code manipulation for
instance). I'm seeing origin manipulation already from certain peers and I
believe some in the same situation many have choosen to flatten origin
themselves (set to igp on incoming) as a result to prevent it from affecting
their BGP decision process.  Other stub AS may use origin code as a traffic
engineering knob internally.  For these reasons, I think origin code
validation should be optional at best (this threat is not high on my list
frankly).

Jon

---

From: Andrew Chi <[email-masked]>
Date: Tue, 26 Mar 2013 18:27:25 -0400

On 3/11/2013 3:31 PM, Stephen Kent wrote:
> <snip>

-bgpsec-threats-05 has been updated with the revised paragraph.

Editorial change: I also removed the TCPMD5 reference at the end since 
it's within a quote (and obsoleted).

Andrew