Subject: Re: [sidr] BGPSEC Threat Model ID

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Nov 2011 09:57:03 -0400

At 4:20 PM -0400 10/29/11, Danny McPherson wrote:
>Some comments on sidr-bgpsec-threats-00 below..
>
>Most substantial of my concerns is Section 5's "Residual
>Vulnerabilities", specifically:
>
>  "BGPSEC has a separate set of residual vulnerabilities:
>
>   - BGPSEC is not able to prevent what is usually referred to as
>     route leaks, because BGP itself does not distinguish between
>     transit and non-transit ASes- BGPSEC signatures do not protect
>     all attributes associated with an AS_path. Some of these
>     attributes are employed as inputs to routing decisions. Thus
>     attacks that modify (or strip) these other attributes are not
>     detected by BGPSEC."
>
>Do we really consider it acceptable that the solution and machinery
>we're recommending will NOT prevent "route leaks",

Route leaks represent a violation of an ISPs local policy, i.e., the ISP
is propagating routes that it, locally, did not intend to propagate. 
There is no semantic in BGP that captures this aspect of local 
policy. (The "NO EXPORT" community is not relevant here. An upstream 
or peer ISP may not know that the "leaking" ISP does not intend to 
export the routes in question. Also, the "leaking" ISP may 
legitimately plan to announce these routes to downstream ISPs.) So, 
since a route leak is an error only relative to the policy of the
offending ISP  BGPSEC cannot be expected to detect and reject this behavior.

>and also does
>NOT protect the integrity of the very path attributes that are used
>to apply preferences (i.e., policy derived from business logic that
>dictates most routing decisions on the Internet today)?

I don't understand the text immediately above. Can you rephrase?

>I'm having a really hard time subscribing to this as being an
>acceptable residual threat after we reach full deployment,
>particularly without a clear path outlining the development of
>controls that mitigate that risk.

BGPSEC (or any analogous technology) can provide protection for BGP relative to
two constraints:
	- the semantics of BGP have to align with the protection
	- the underlying PKI has to align with the protection

Thus, for example, other attributes carried by BGP and for which the resource
allocation system has no reference, cannot be protected. Similarly, 
route leaks, because they are a violation of a local policy, which is 
not expressed in BGP Update messages, cannot be addressed.

>
>More comments below....
>
>---
>s/to determine of/to determine if/

fixed

>---
>In terminology section include "(AS)" after "Authonomous System"
>per subsequent use of acronym.

fixed

>---
>s/AS Number (ANS)/AS Number (ASN)/

fixed.

>---
>"False Origination" should probably be "network operator", not
>ISP, in particular given the subsequent definition of ISP.

please explain.

>---
>s/Local Internet registries/Local Internet Registries/

fixed.

>---
>The definition of "Route" seems to be missing the full set of
>path attributes associated with the NLRI, it currently only
>focuses on the AS_PATH attribute, and even omits the ORIGIN
>code of the path.

I think the definition does not omit the origin AS, but I will 
clarify the text.
Our context assumes use of the RPKI, and the RPKI attests to only 
prefix and ASN holdings of entities, hence the focus on these 
attributes. For example, MPLS attributes are not supported in the 
RPKI, so they are out of scope here.

>---
>Regarding your definition of "Threat":
>
>    Threat - A threat is a motivated, capable adversary. An adversary
>    that is not motivated to launch an attack is not a threat. An
>    adversary that is motivated but not capable of launching an attack
>    also is not a threat.
>
>With many "route leaks" and similar incidents, the network operator
>may not have been motivated to launch an attack, but the impact of a
>leak is the same and it is certainly still a "threat".

The definition I used here has been widely used for many years in contexts
where folks understand the importance of distinguishing among 
attacks,  adversaries, and motivations. Unlike the RPKI focus on 
config errors, BGPSEC
focuses on attacks. As noted in above, route leaks are out of scope, because
they do not represent violations of BGP semantics, as expressed externally.

>---
>In "Threat Characterization" it would seem that for simplicity we
>should refer to BGP speakers as "network operators", not just ISPs
>as the current text suggests, particuarly in the case where an
>attacker may well be a subscriber that intentionally interconnects
>between two ISPs (in order to exploit business logic and derived
>preferences), or leaks routes unintentionally as is commonly the
>case today?

I have made the suggested change.

>---
>"Hackers might be recruited, without their knowledge, by criminals
>or by nations, to act on their behalf." are you referring to social
>engineering or other attacks here that would be employed to gain
>access to a network operator's systems?  If so, that doesn't make
>the victim a "hacker"?

I am referring to the adversaries, not to types of attacks. The target
of a social engineering attack is not an adversary; he/she is an instrument
used by an adversary.

>---
>Wouldn't "attacker" be a better term here, "hacker" is fairly
>ambiguous.  Also, from a threat model perspective here I see little
>difference between "criminals" and "nations", can you explain the
>difference and why it's called out expressly anywhere beyond the
>discussion of jurisdictional issues dictating network operator or
>CA/INR functions?

I think the motivation and capabilities discussion justifies the 
distinctions between these classes of adversaries. The term 
"attacker" is generic and not
useful as an adversary characterization.

>---
>Regarding "Registries", an attack on a registry in this case (e.g.,
>social engineering) could have the same or broader impacts as an
>attack on an ISP (network operator), I think you capture this in
>later sections but this text does not adequately represents this.

I'll revisit this text.

>---
>s/act as a rogue capacity/act in a rogue capacity/ ?

fixed

>---
>The end of Section 3 seems to be incomplete, i.e.:
>
>"A manifest associated with a CA's repository publication point
>  contains a list of:
>
>4. Attacks"

yep. that was a whoops at my end. the manifest text should not have
appeared there.

>---
>Regarding Section 4.1, passive attacks, and "confidentiality" from
>MITM as a non-goal, shouldn't protections there be an objective in
>order to minimize the exposure of data that could lead to replay and
>other similar attacks -- in order to further minimize that exposure
>window we're trying to address with periodic updates?

The mechanisms used to protect against replay attacks assume a MITM and
knowledge of the plaintext. This is consistent with general IETF security
analyses.

>---
>This discusses TCP-AO or IPSec, whereas the rquirements draft avoids
>TCP-AO and talks about TLS?

I'm sure my text does not mention "IPSec" (vs. IPsec) :-). I will add
TLS to the list.

>---
>S 4.3:
>
>"This type of behavior cannot be externally detected as an attack."
>
>/cannot/may not/

I said "cannot" here because of the modifier "externally." To external
observers, such behavior by an ISP may be viewed as odd behavior, but 
enough ISPs
behave oddly enough to make this indistinguishable from an attack.

>---
>"PA allocation" - Define PA here.

I removed the "PA" qualifier.

>---
>My read of most of the attacks in S 4.3 is about DoS-esque functions,
>not certificate issuance that might be employed at a later time.
>Perhaps we should capture this more clearly in this section, as it's
>certainly one of the more obvious issues we're seeing with the CA
>sieve today...?

S 4.3 is titled "Attacks on ISP management computers (non-CA 
computers)" so CA-specific attacks do not belong in that section. S 
4.5 addresses attacks focused on CAs.

Not sure what you mean by "CA sieve."

>---
>S 4.4
>
>Regarding this text:
>
>   "An RP can continue to use the last valid instance of the
>    deleted object as a local policy option), thus minimizing
>    the impact of such an attack."
>
>Such guidance and implementation may be precisely what an attacker
>was hoping to instigate, no?  Further:

The RPKI and BGPSEC designs place a high priority on maintaining
the ability of ISPs to continue routing in the face of outages. Using 
cached, previously validated RPKI data is a good way to support this 
goal, in the face of outages, benign or malicious. So, I think we are 
making an appropriate decision here. An attacker can always try to 
effect DoS on targeted RPs, and has has fewer attack options when RPs 
can revert to cached data.

>   "An RP cannot know the content of the new certificates or ROAs
>    that are not present, but it can continue to use what it has
>    cached."

yes.

>and S 5's Residual Vulnerabilities:
>
>    - the RPKI repository system may be attacked in ways that make
>    its contents unavailable, or not current. It is anticipated that
>    RPs will cope with this vulnerability through local caching of
>    repository data, and through local settings that tolerate
>    expired or stale repository data.
>
>I think we should be clear that expired information should not be
>used?

I disagree. First, note that certs expire, but CRLs are defined as 
stale when the next issue date passes.  Manifests are defined as 
stale when the bundled EE cert is expired. Other signed objects that 
have bundled EE certs expire with their certs. In the absence of 
current, valid objects,

>---
>In the cases where notifying a CA of the error in order to remedy
>the problem is the recommended action, what threats arise if the
>CA cannot be reached or authenticated?  Should those be enumerated
>here?

I assume this comment refers to the discussion in S 4.5, right?  If 
the CA does not
take action to remedy the attack effects, then the situation is equivalent to
a CA as adversary (vs. attack victim). I will add a sentence to note this.

>---
>S 5.
>
>s/were been discussed in the/were discussed in the/

fixed.

>---
>I'm surprised I don't see anything here about timing dependencies
>between RPKI and BGPSEC routers, and variances across a BGPSEC system
>having considerable potential impacts.  I think some discussion of
>this is in order in a threats draft.

There is no requirement that a BGPSEC router interact directly with 
the RPKI repository system. However, your question is still relevant 
if we substitute
"local RPKI server" for "BGPSEC router." S 4.4 already deals with 
attacks against publication points, many of which are relevant to the 
timing concerns you cite above. The RPKI, is a distributed repository 
system with many maintainers. RPs ought not assume that they always 
have the very latest data from the system, and maintainers ought not 
assume that all RPs have the latest data.  This issue is addressed in 
detail in the RPKI key rollover doc.

>---
>Shouldn't there also be some discussion of coherency the RPKI
>repository system?  I.e., timing dependencies can result in some
>amount of considerable exposure if a manifest or CRL regarding a
>particular certificate have not been refreshed yet?

Section 5 already addresses this, at a high level, see bold text:

	- the RPKI repository system may be attacked in ways that make
         its contents unavailable, or not current. It is anticipated that
         RPs will cope with this vulnerability through local caching of
         repository data, and through local settings that tolerate
         expired or stale repository data.

I have changed this to say

	contents unavailable, not current current, or inconsistent.

Steve

---

From: "Danny McPherson" <[email-masked]>
Date: Tue, 1 Nov 2011 15:27:37 -0400 (EDT)

> is propagating routes that it, locally, did not intend to propagate.

Perhaps the network operator DID fully intend to propagate ("leak") those
routes in order to hijack and MITM traffic?  Any multi-homed customer can
launch such an attack today of this sort, and as a matter of fact, it
happens all the time, for benign or malicious purposes.

To say that this is not a "semantics violation" and therefore in scope
does not mitigate the risk.  How that risk can be considered as a
"Residual Risk" in a "Threat Model for BGP Path Security" document totally
escapes me?

> BGPSEC (or any analogous technology) can provide protection for BGP
> relative to two constraints:
> Thus, for example, other attributes carried by BGP and for which the
> resource allocation system has no reference, cannot be protected.
> Similarly, route leaks, because they are a violation of a local policy,
> which is not expressed in BGP Update messages, cannot be addressed.

But they are certainly still risks, whether the proposals at
hand can mitigate them or not is orthogonal.  And even policy
expressed in IRRs and via RPSL can result in controls that can
be put in place to mitigate various aspects of those risk.  I
don't understand how we can ignore this as an objective here,
and we certainly cannot discard it so casually as a trivial
residual threat.  If some non-obvious or undisclosed roadmap
exists to solve this piece then I'm truly anxious to see it -
else it would seem to me secure IRRs bootstrapped by resource
certification data and perhaps even deployed to routers via some
rpki-rtr-esque protocol would provide a lot better protection
with a lot less overhead.

>>ISP, in particular given the subsequent definition of ISP.

You use ISP in this draft as if they're the only ones who
may be multi-homed or trigger leaks or other functions, "network
operator" is much more broadly applicable and well beyond "ISP"
in the traditional sense.

> I think the definition does not omit the origin AS, but I will

I'm not talking about Origin AS, I'm talking about "ORIGIN Type
Code" Path Attribute (i.e., i, e, or ?).

> RPKI, so they are out of scope here.

I think the "Threat Model" document should give consideration
to Path Attributes beyond just AS_PATH, particularly because most
are used in path selection.  If we think we don't need to protect
these because they are not in RPKI, then we should consider what
that means rather than assume RPKI contains the information for
all that we need to protect.

> The definition I used here has been widely used for many years
> in contexts where folks understand the importance of
> distinguishing among attacks,  adversaries, and motivations.
> Unlike the RPKI focus on config errors, BGPSEC focuses on attacks.
> As noted in above, route leaks are out of scope, because they
> do not represent violations of BGP semantics, as expressed
> externally.

If Enterprise_E is multi-homed to ISP_1 and ISP_2 and is a
transit customer of both, and then decides (or is compromised
and used to decide) that he wants to hijack traffic from ISP_1
towards ISP_2 for Prefix_P by announcing ISP_2's Enterprise_E2
Prefix_P to ISP_1 through Enterprise_E's local interconnect,
and "policy" makes it a more preferred path, how is this not
an attack?

And it's most certainly a threat and one that some consider
out of scope at that?

> "attacker" is generic and not useful as an adversary
> characterization.

Contextual use "attacker" is more generic than "hacker"?  Umm,
ok, I'm not attached to either..

> enough ISPs behave oddly enough to make this indistinguishable from
> an attack.

But it "may" be externally detectable, which was my point that
you've reinforced :-)

> can revert to cached data.

While I agree, this can enable downgrade or other attacks, no?
Just like clicking on that self-signed or expired intermediate
CA certificate warning in a web browser, right?  If so, the threat
model should indicate as such.

> have bundled EE certs expire with their certs. In the absence of

OK, see above..  Going through all this effort, and then using
"expired data" just seems dirty and opens up a bunch of ugliness
to me...

> detail in the RPKI key rollover doc.

But it's a threat and this is the threat document, right?  If
we're not going to include it here we should at least reference
those sections.

> 	contents unavailable, not current current, or inconsistent.

Not current == expired.  I'll defer to crypto types here, but as
a first order function, I would like to see explicit text and reach
agreement that expired data should be used in the absence of current
data, and what the attack surface implications of using expired data
are.

As usual, thanks for the thoughtful responses Steve.  I really am trying
to come to grips with what's being proposed, but I'm just not there on the
cost/benefit analysis at the moment.

-danny

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Nov 2011 10:52:58 -0400

>"Residual Risk" in a "Threat Model for BGP Path Security" document totally

I interpret the task at hand as trying to secure BGP, not a new EGP. 
Since BGP semantics (and syntax) do not provide a basis for deciding 
when an advertisement constitutes a route leak, I think it reasonable 
that the BGPSEC threat model view this as out of scope. If BGP were 
modified to express semantics we're discussing, then it would be in 
scope, and I would expect BGPSEC to address it.

>hand can mitigate them or not is orthogonal.

The threat model is based on using the RPKI as the starting point.
I will add text that clearly articulates that.

>And even policy
>be put in place to mitigate various aspects of those risk.

yes, one can use RPSL to express more info, but these are just 
assertions by the
maintainers of RPSL objects. For some of this data, there is no basis 
for validating it via external, authoritative sources. That makes 
such data a poor
basis for security controls.

>   I

We disagree about the advisability of relying on some types of IRR 
data, e.g., an assertion that AS X will advertise (not originate) 
routes for prefix Z.

>in the traditional sense.

OK; I have changed all instances of ISP to network operator.

>Code" Path Attribute (i.e., i, e, or ?).

Sorry, I misunderstood your question. Now I know the data item to 
which you were referring. I checked with a network operator here at 
the RIPE meetings, to understand how/why it is used.  I now believe 
that the ORIGIN attribute is a poster boy for an attribute that is 
unsuitable for inter-AS protection. This attribute can be set to one 
of 3 values by an AS sending an Update. (One of these values cites 
EGP as the source of the data, so unless the Update has been terribly 
delayed, this is not a credible value :-).)  The other two values are 
IGP and INCOMPLETE (i.e., mystery). How would an AS that sees this 
value externally verify that the value is accurate? I am unable to 
imagine how this would work.

>all that we need to protect.

Let me try again. If we can't identify a suitable, authoritative 
source of data that could be used to verify an assertion about an 
attribute in an Update, that attribute is not a candidate for 
inter-AS security mechanisms.

>and "policy" makes it a more preferred path, how is this not

How does BGP indicate (i.e., where are the bits that say) that the 
Update sent to E is not to be propagated to another ISP?  I've been 
told that the NO_EXPORT community does not have the right semantics, 
and that network operators do not pay attention to this anyway.

>And it's most certainly a threat and one that some consider

I presume that you mean in scope, right?

>...

"May" is not a suitable basis for a secruity protocol :-).

>model should indicate as such.

I can add text to note that use of cached data enables some types of 
attacks resulting from use of stale data.

>we're not going to include it here we should at least reference

I can add text that notes the implications for RPs of using any distributed
repository system with data supplied by object owners.

>data, and what the attack surface implications of using expired data

In PKIs it is always the case that, in the absence of the current 
CRL, use the old one. This is because, with one ugly exception, once 
you are revoked, you are revoked, you stay revoked. So, expired and 
stale are meaningful differences to us PKI experts. But, I agree that 
more text can be added to note the vulnerabilities associated with 
using stale or expired PKI data.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Wed, 2 Nov 2011 12:08:05 -0400

On Wed, Nov 2, 2011 at 10:52 AM, Stephen Kent <[email-masked]> wrote:
> I interpret the task at hand as trying to secure BGP, not a new EGP. Since
> BGP semantics (and syntax) do not provide a basis for deciding when an
> advertisement constitutes a route leak, I think it reasonable that the
> BGPSEC threat model view this as out of scope. If BGP were modified to
> express semantics we're discussing, then it would be in scope, and I would
> expect BGPSEC to address it.

BGPSEC is an _extension_ to BGP. (This is according to the WG Charter.)
Adding ways of identifying updates as "bad", whether because of
failure to authenticate,
or because of authenticated data which indicates a semantic violation,
is in-charter.
Blocking updates does not fundamentally change the BGP path selection process.
Thus, it isn't more than an enforced filtering methodology. It fits
squarely within the
model proposed by BGPSEC.

If there is a need to address _malicious_ route leaks, and it is not
possible to address
without securing the necessary added semantic elements, then clearly those added
elements can't and won't be done by the IDR WG, since securing those elements
would be the responsibility of SIDR.

Put another way - adding elements to BGP to address accidental route
leaks will do
nothing to address malicious route leaks.

On the other hand, anything which addresses malicious route leaks, by
definition,
will also address accidental route leaks.

Malicious route leaks and accidental route leaks are two of the
biggest threats to BGP.
Having two solutions, one done by IDR and another by SIDR, is clearly redundant,
since the SIDR solution would make the IDR solution moot.

Thus, it make the most sense to include the solution to malicious
route leaks in SIDR's mandate.

If need be, I request the WG chairs expressly poll the WG on this issue.

I suggest that the issue remain in-charter for some period of time,
until a solution to the problem is presented,
at which time it be included in the main protocol document for BGPSEC,
at which time it become mandatory.

(BTW - I have already given a preliminary proposal, which is not an
I-D yet, and which needs some work.
But, this establishes the feasibility of achieving the semantics
needed to mitigate the risk of route leaks.)

> Sorry, I misunderstood your question. Now I know the data item to which you
> were referring. I checked with a network operator here at the RIPE meetings,
> to understand how/why it is used.  I now believe that the ORIGIN attribute
> is a poster boy for an attribute that is unsuitable for inter-AS protection.
> This attribute can be set to one of 3 values by an AS sending an Update.
> (One of these values cites EGP as the source of the data, so unless the
> Update has been terribly delayed, this is not a credible value :-).)  The
> other two values are IGP and INCOMPLETE (i.e., mystery). How would an AS
> that sees this value externally verify that the value is accurate? I am
> unable to imagine how this would work.
>
> Let me try again. If we can't identify a suitable, authoritative source of
> data that could be used to verify an assertion about an attribute in an
> Update, that attribute is not a candidate for inter-AS security mechanisms.

Here's the thing:
(1) RPKI authenticates the Originator.
(2) The Originator signs "stuff"
(2a) "stuff" MUST include all the things from RPKI.
(3) Every additional AS in the path adds itself and signs the result.
(4) "Stuff" can include additional elements in addition to the things
already identified in the -00 version of the protocol document.
(4a) The signature allows the receiver to validate that it was sent by
the Originator. The RPKI assures that the Originator is allowed to
originate the Update.
(4b) It follows that there is no reason not to trust all Transitive
values set by Originator, and Signed by the Originator
(4c) It also follows that Non-Transitive values could be set by one's
Neighbor AS, signed by that AS, and have those values Secured.
(5) If any BGP path attribute used in Path Selection is not signed,
then BGPSEC has failed to meet its charter requirements.

> How does BGP indicate (i.e., where are the bits that say) that the Update
> sent to E is not to be propagated to another ISP?  I've been told that the
> NO_EXPORT community does not have the right semantics, and that network
> operators do not pay attention to this anyway.
>

I believe what Danny was saying is, "some consider this out of scope",
where "some" means at a minimum the authors of the Threat document,
and that since it is a threat, it really should be *in* scope.

Consider this a +1 on this as being in scope of the Threat document, regardless
of whether or not it should be in-scope for the protocol itself.

Brian

---

From: Russ White <[email-masked]>
Date: Wed, 02 Nov 2011 12:32:45 -0400

> values set by Originator, and Signed by the Originator

It does not follow. Policy is per AS, not per route or destination.

> Neighbor AS, signed by that AS, and have those values Secured.

Can you define "secure" here?

> then BGPSEC has failed to meet its charter requirements.

Then MED and Local Pref must also be signed, along with a number of
communities, and even the next hop.

> and that since it is a threat, it really should be *in* scope.

Maybe there's a reason for this particular capability not existing
within BGP. Perhaps it is because it's always been recognized that
transmitting reachability is routing, but failing to transmit
reachability that exists because you don't want someone else to use it,
or --even more-- asking someone you send reachability information to not
to forward that reachability information --is a matter of policy.

The failure to define and separate policy from routing has caused a
great deal of confusion within the BGP security space over the years.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Nov 2011 12:35:42 -0400

>model proposed by BGPSEC.

Dropping an update because it fails BGPSEC validation is certainly in scope,
and it is consistent with the BGP model, which allows any AS to drop 
any update for any reason.

>would be the responsibility of SIDR.

logical, and likely to be true :-).

>nothing to address malicious route leaks.

I don't agree that this follows, but it might be true anyway.

>will also address accidental route leaks.

probably.

>since the SIDR solution would make the IDR solution moot.

I doubt that we will have two solutions, so I will not worry about this.

>route leaks in SIDR's mandate.

that does not follow. In addition to the charter question (for which 
I think there is a clear, out-of-scope answer) the other major issue 
is whether a solution to route leaks is consistent with the basic BGP 
model. if so, then I suspect that IDR will be happy to have SIDR 
proceed with such a solution, under a revised, extended charter. If 
not, then IDR could rightfully object that our extensions are 
inappropriate.

>at which time it become mandatory.

The SIDR charter is very brief and it lays out some clear 
requirements which I cite below. These do not extend to route leaks.

>needed to mitigate the risk of route leaks.)

I've been busy replying to Danny's messages, so I have not looked at your
proposal.

>(2) The Originator signs "stuff"

carefully restricted stuff.

>(2a) "stuff" MUST include all the things from RPKI.

not really. look at the BGPSEC protocol sig block.

>already identified in the -00 version of the protocol document.

it could, if appropriate.

>the Originator. The RPKI assures that the Originator is allowed to

and the sig is matched against RPKI data to verify that the BGP 
speaker that signed the update did so on behalf of an ASN that the 
speaker is authorized to represent. when the data covered by the sig 
is AS path info, the semantics of the RPKI certs and ROAs match the 
signed data. when we consider adding other data under a sig, we have 
to ask whether it is sufficient to know that a specific speaker 
signed the data. As an example, if one receives an S/MIME message, 
and the sig validates, that does NOT mean that you can trust he FROM 
field in the message header!

>values set by Originator, and Signed by the Originator

disagree, for the reasons alluded to above.

>Neighbor AS, signed by that AS, and have those values Secured.

huh?

>then BGPSEC has failed to meet its charter requirements.

Look at the charter again.  In particular it begins by saying:

The purpose of the SIDR working group is to reduce vulnerabilities in
the inter-domain routing system. The two vulnerabilities that will be
addressed are:

* Is an Autonomous System (AS) authorized to originate an IP prefix
* Is the AS-Path represented in the route the same as the path through
which the NLRI traveled

The charter does NOT say that other path attributes need to be secured.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Wed, 2 Nov 2011 13:08:40 -0400

> It does not follow. Policy is per AS, not per route or destination.

Trust policy is necessarily per AS. Routing policy is de facto per route.
Each prefix will be independently signed, so it follows that including other
parameters in the signature is not unreasonable. It does not change the
number of signatures needed, only the size of the blob being signed,
and generally speaking marginally.

> Can you define "secure" here?

Signed.

> communities, and even the next hop.

Yes.

> great deal of confusion within the BGP security space over the years.

Correct. And given that there exist malicious use cases for violating implicit
policy, it makes sense that it be addressed in conjunction with BGPSEC.

The particulars on how to implement marking and enforcement are important,
and there are pros and cons to the variety of ways of doing this.

However, the high-level semantics can be captured easily, on a per-prefix,
per-peering basis:

"You're not my transit provider"
vs
"Please be my transit provider"

Perhaps this would best be done as a BGP Option negotiated on a
peering session, in each direction:
"Transit Requested" / "Transit Offered"

(In the oddball case of mutual transit, both flags would be set in
both directions).

Even if there isn't enforcement of behavior per se, the ability to
view the asserted policy
on a per-AS-hop basis allows for local receiver filtering based on the
presence/absence
of such a flag bit anywhere in the path, per-prefix.

Having the bit signed by the Sender (as part of the signed data, that
is) means that anyone wishing
to honor the sender's intent, is able to do so automatically.

(There are two options - enforce behavior per AS hop within the
protocol, or expose the per-hop values.
The latter is more robust, protecting against malicious
implementations as well as poor configurations.)

Brian

---

From: Russ White <[email-masked]>
Date: Wed, 02 Nov 2011 13:41:49 -0400

> Signed.

I wonder --if I sign my door knob, does that make it secure?

Cryptographic signatures are not security. In fact, for all our wailing
about "obscurity is not security," cryptography is just a more
sophisticated form of obscurity. Somewhere along the way we've lost
sight of the original meaning of that phrase, and the original goals of
security.

> policy, it makes sense that it be addressed in conjunction with BGPSEC.

There are several problems here.

1. Most providers apparently want to enforce policy without telling
anyone what their policy actually is. That this is a logical
contradiction doesn't seem to disturb anyone.

2. You can't "enforce" your policy --all you can do is signal to someone
else what that policy is, and ask them nicely to enforce it for you.

2a. If you have a business relationship with this other party, then you
already have an enforcement mechanism at hand --signatures and other
sorts of things won't provide anything additional.

2b. If you don't have a business relationship with this other party,
then there's no point in asking, because they're going to do what's best
for them, not for you.

There's some sort of dream world where you can not tell anyone what your
policies are, and people you don't have a business relationship with
will somehow enforce those policies (that they don't know about, because
you refuse to tell them) for you. It's a nice dream, but I don't see how
it has any bearing on reality.

Until we can get past this little dream world, I don't see how SIDR is
going to make any real progress towards actually securing BGP. Either
policies --all policies-- must be off limits, even ones masquerading as
"man in the middle attacks," or all policies must be within bounds, and
we must enumerate and deal with them honestly.

:-)

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Nov 2011 19:00:17 +0100

> contradiction doesn't seem to disturb anyone.

Policy on the global Internet changes every 36ms, new circuits, new
customers, new peers, ...

We already have a protocol to distribute policy or its effects, it is
called BGP

We can not know intent, should Mary have announced the prefix to Bob

But Joe can formally validate that Mary did announce the prefix to Bob

BGPsec validates that the protocol has not been violated, and is not
about intent or business policy

randy

---

From: Brian Dickson <[email-masked]>
Date: Wed, 2 Nov 2011 14:11:03 -0400

> sorts of things won't provide anything additional.

Actually, this is not strictly true.

Let's consider the smallest case where there are more than two parties,
where route leaks cause problems (whether malicious or accidental).

Parties: A, B, C.
Relationships, all formalized via contracts (whether for transit or peering).
C is a customer of A.
C is a customer of B.
B and A are peers.
For sake of argument, presume that A and B also have upstream transit providers.

The intended policies have A and B exchanging routes of only their
customers, and
their internal routes.

C receives the full Internet routing table from both A and B.

The agreements between A and C, and between B and C, prohibit C sending anything
other than C's own routes to A and B.

Then consider what happens in the case of C sending B's routes (and
B's upstream routes) to A.

A prefers routes learned from customers over peer or transit routes.

A now prefers the path via C to the entire Internet, including traffic
from A to B.

There is no _technological_  mechanism for B to stop this, short of
turning down C's BGP session.
And, this also presumes that B has some definitive way of discovering
this, which is not necessarily
the case.

When we add in D, a transit customer of C, we can see the challenging
nature of the problem.

How to we distinguish C sending B's routes to D (which is good and
expected and allowed),
from C sending B's routes to A (not good/unexpected/not "allowed" by contracts)?

If there isn't some easy way for A to see that their customer is
sending routes which are not
their own or their customers', by way of "marking" in the middle of
the AS path, then the scale
of the problem is huge (having prefix filters and AS-path filters
built on ... the IRR).
With marking, we gain easy filtering to honor the senders' intentions, and
the ability to authenticate things and still limit the information on
a need-to-know basis.

Observe the following - information about relationships encoded within
the path will be visible
only to those who receive the path. If the path signals "block me",
the relationship information
is also blocked.

This may be an acceptable degree of information leakage - which
happens to coincide with
path information, which necessarily must be leaked.

Brian

---

From: Russ White <[email-masked]>
Date: Wed, 02 Nov 2011 14:17:27 -0400

> B and A are peers.

Which means they have a business relationship...

> other than C's own routes to A and B.

The only way A and B would know they are C's upstream is for them to
tell one another about it --as you say, this isn't possible within BGP.

According to the folks I've talked to, BGPSEC was specifically not
designed to resolve the problem you're discussing, and there is no way
within the specification to resolve this problem.

:-)

Russ

---

From: Danny McPherson <[email-masked]>
Date: Wed, 2 Nov 2011 14:12:55 -0400

> contradiction doesn't seem to disturb anyone.

While I see it in the BGPSEC requirements work I'm not sure it's "most", and 
I don't recall reaching any consensus on this. As an operator and ++450 peers 
(and many transit providers) in my day job, I don't have a problem with 
publishing this information if it helps mitigate what I believe are threats.

I.e., I agree with you..

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 2 Nov 2011 22:29:24 -0400

On Nov 2, 2011, at 10:52 AM, Stephen Kent wrote:

> I interpret the task at hand as trying to secure BGP, not a new EGP. Since BGP semantics (and syntax) do not provide a basis for deciding when an advertisement constitutes a route leak, I think it reasonable that the BGPSEC threat model view this as out of scope. If BGP were modified to express semantics we're discussing, then it would be in scope, and I would expect BGPSEC to address it.

Duly noted, and my disagreement stands:

To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or
benign, that is not an authorized transit for a given prefix is out of scope 
because it is not a "semantics violation" does not mitigate what I perceive 
as  a very significant risk to my operations.  

Absent a companion set of mechanisms and controls under cover of "BGPSEC" 
to mitigate that risk, I'm opposed to the publication of this document under the 
auspices  of  "Threat Model for BGP Path Security".  I.e., it is not an acceptable 
residual risk.

> yes, one can use RPSL to express more info, but these are just assertions
> by the maintainers of RPSL objects.

But if these maintainers are the resource holders that are authorized via the
RPKI, then they are no more assertions than an RIR's RPKI testimony about 
their resource holdings is an assertion.
 
> For some of this data, there is no basis for validating it via external, authoritative
> sources. That makes such data a poor basis for security controls.

Ahh, and the crux - then perhaps this needs to be corrected, rather than 
accepting this residual risk?

> We disagree about the advisability of relying on some types of IRR data, e.g., an assertion that AS X will advertise (not originate) routes for prefix Z.

"Some types" is relative, and I understand and agree with that.  Tell me
how to get there?

> Sorry, I misunderstood your question. Now I know the data item to which you were referring. I checked with a network operator here at the RIPE meetings, to understand how/why it is used.  I now believe that the ORIGIN attribute is a poster boy for an attribute that is unsuitable for inter-AS protection. This attribute can be set to one of 3 values by an AS sending an Update. (One of these values cites EGP as the source of the data, so unless the Update has been terribly delayed, this is not a credible value :-).)  The other two values are IGP and INCOMPLETE (i.e., mystery). How would an AS that sees this value externally verify that the value is accurate? I am unable to imagine how this would work.

If it were cryptographically protected by the origin AS then it couldn't be
manipulated by intermediate ASes for the purpose of traffic attraction 
attacks - as it commonly is today.  As discussed above, ORIGIN code was 
simply an example of why the laser focus only on the AS_PATH Path 
Attributes may be problematic in practice.

> Let me try again. If we can't identify a suitable, authoritative source of data that could be used to verify an assertion about an attribute in an Update, that attribute is not a candidate for inter-AS security mechanisms.

If an origin AS for which a ROA is associated in the current system signs 
those transitive attributes then what more do you need?  

> How does BGP indicate (i.e., where are the bits that say) that the Update sent to E is not to be propagated to another ISP?  I've been told that the NO_EXPORT community does not have the right semantics, and that network operators do not pay attention to this anyway.

I agree NO_EXPORT is not the right answer, I never even considered it.  

I'm saying policy is a big part of the problem, at least as considerable as  
"integrity" of the AS_PATH, IMO, and if we don't take a systemic approach 
and consider the gaps that exist, then it's hard for me to justify the 
investment.

> "May" is not a suitable basis for a secruity protocol :-).

The possibly exists that it many cases it can be detected, therefore, "cannot" 
is false.

> I can add text to note that use of cached data enables some types of attacks resulting from use of stale data.

I think the text we need here, if you truly believe this is the right course, 
is to clearly state that expired digital certificate data is acceptable.  As a 
basis for a security architecture, this assumption seems a residual risk I 
would prefer to mitigate.

For example, do you consider it acceptable to use expired certs when 
you connect to a web site via SSL or VPN to some remote location?  I 
don't.

Furthermore, besides the obvious attacks you're accepting by recommending
use of expired certificates, aren't revoked certificates only supposed to remain 
in the CRL until their validity period has expired?  How in the heck can we justify 
use of expired certificates in the absence of current data, when some of those 
expired certificates may have even been revoked?

> In PKIs it is always the case that, in the absence of the current CRL, use the old one. This is because, with one ugly exception, once you are revoked, you are revoked, you stay revoked. So, expired and stale are meaningful differences to us PKI experts. But, I agree that more text can be added to note the vulnerabilities associated with using stale or expired PKI data.

And that is exactly my point, I don't know the difference between them
and therefore using them opens me up to attack and undermines the entire
system.

Also, if RPKI weren't so distributed, or if we could develop a model, perhaps some
OSCP-esque near realtime function would be of benefit here, in the general case, 
and perhaps even some notify function from publication points/CAs for RPs to identify 
revoked certificates, such that a RP, or even BGPSEC speakers, could be notified of
an incident with a particular resource, rather than periodically telling everyone 
everything via a periodic update/refresh mechanism? 

What are your thoughts on this?

-danny

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Nov 2011 07:09:14 -0400

At 10:29 PM -0400 11/2/11, Danny McPherson wrote:
>>I interpret the task at hand as trying to secure BGP, not a new 
>>EGP. Since BGP semantics (and syntax) do not provide a basis for 
>>deciding when an advertisement constitutes a route leak, I think it 
>>reasonable that the BGPSEC threat model view this as out of scope. 
>>If BGP were modified to express semantics we're discussing, then it 
>>would be in scope, and I would expect BGPSEC to address it.
>>
>

Having been motived to reread the SIDR charter by Brian's message, 
there is a simple answer to the in/out of scope question, but it's 
one you will not like :-). The charter for SIDR states that the 
secruity goals for the WG are to address two vulnerabilities: 
authorization for prefix origination and path validation.  Relative 
to the charter, route leaks are out of scope.  I will add text to the 
intro for the threat model to state that the scope of the model is 
defined by the charter, and include the relevant charter text. I hope 
you'll forgive me for taking the easy path here.

>their resource holdings is an assertion.

I'm not sure I understand the sentence above.  RPKI CAs issue certs 
based on authoritative databases about Internet resources.  The 
authorized holder of a resource can make lots of assertions, and the 
RPKI allows us to attribute these assertions to that entity. RPSL 
allows lots of assertions to be made, and many of them cannot be 
validated relative to the RPKI. Relying on such assertions, just 
because their sigs can be validated under the RPKI is a new sort of 
vulnerability that we ought not enable.

>accepting this residual risk?

see comment above. 

>"Some types" is relative, and I understand and agree with that.  Tell me

Get where?

>>that the ORIGIN attribute is a poster boy for an attribute that 
>>is unsuitable for inter-AS protection. This attribute can be set to 
>>one of 3 values by an AS sending an Update. (One of these values 
>>cites EGP as the source of the data, so unless the Update has been 
>>terribly delayed, this is not a credible value :-).)  The other two 
>>values are IGP and INCOMPLETE (i.e., mystery). How would an AS that 
>>sees this value externally verify that the value is accurate? I am 

I agree that the integrity that would result from including this 
attribute under the sig applied by the first AS would provide the 
secruity you cited. That may make it worthwhile to protect via the 
sig. However, the accuracy of the assertion being made by this 
attribute is unverifiable by any of the ASes along the path, and that 
was what worried me.  But, again, the charter makes this out of 
scope, i.e., it is not relevant to the origin authorization or path 
accuracy vulnerabilities cited there.

>those transitive attributes then what more do you need?

That sig provides integrity, which is valuable, but it does not 
provide a way to verify the accuracy of the assertion by the origin 
AS. Your concern is that an AS along the route can change the value 
of the attribute. One might also be concerned that the origin set the 
value incorrectly. Ultimately, I think this is a bad example for us 
to argue about, as it is a vestigial part of BGP, from EGP days, that 
is the penultimate basis for route decisions.

>>told that the NO_EXPORT community does not have the right 
>>semantics, and that network operators do not pay attention to this 
>>anyway.
>>
>

I'm not sure what you're trying to say about policy here. Can you elaborate.

>The possibly exists that it many cases it can be detected, therefore, "cannot"

OK, "cannot" was too strong. But, I still feel that "may" is a bad 
basis for a security protocol.

>>I can add text to note that use of cached data enables some types 
>>of attacks resulting from use of stale data.
>>
>

It is up to each RP to decide whether to rely on assertions made by 
an expired cert, or to act as though the cert does not exist. In the 
routing context, there appears to be some agreement that relying on 
expired certs is more desirable
than treating the resources as not certified. But, this is a per-RP decision.

>you connect to a web site via SSL or VPN to some remote location?  I

Many folks do. This is probably because an expired cert often indicates that
the cert holder was sloppy, and failed to renew the cert, i.e., pay 
the CA. Expiration is not as negative an indication as revocation.

>expired certificates may have even been revoked?

There is a subtly here, and thanks for pointing it out. The idea is 
that if an RP has a cert, and it was not revoked, then the RP can 
continue to rely on it, after the cert expires, if the RP is unable 
to acquire fresh data from the pub point for that cert. If the cert 
had been revoked, it should not be un-revoked because it expired.

>>CRL, use the old one. This is because, with one ugly exception, 
>>once you are revoked, you are revoked, you stay revoked. So, 
>>expired and stale are meaningful differences to us PKI experts. 
>>But, I agree that more text can be added to note the 
>>vulnerabilities associated with using stale or expired PKI data.
>>
>

I think the phrase "undermines the entire system" is melodramatic. 
How about "you actual assurance may vary?" :-)

>What are your thoughts on this?

I would prefer more centralization of RPKI data. My original model 
called for each RIR to aggregate the data for every member, and act 
as a mirror for the data for every other RIR. But other folks wanted 
greater distribution. One can argue that wider distribution may offer 
potentially greater resilience, so ...

OCSP is an optimization of the CRL mechanism, designed to efficiently 
answer a revocation status query for a single cert. Since every RP 
needs to know the revocation  status of every cert, OCSP (or an 
analogous mechanism) does not seem to be a good match.  For many 
years folks have thought that very fast dissemination of revocation 
status data was important for PKIs.  In reality, revocation is an 
administrative procedure for which the major delays will be
created by people deciding whether to revoke a cert, vs. the time it 
takes to disseminate the CRL.

There are two types of certs: CA certs and EE certs.

Because revoking a CA cert has major implications, so such a decision 
will not be taken lightly. Thus I expect relatively few revocations 
of CA certs and the principle delay will be procedural.

All of the EE certs defined so far (not counting router certs for 
BGPSEC, which have yet to be agreed upon) are embedded in RPKI 
objects: manifests, ROAs, and GB records.

A new manifest MUST be published whenever any file at a pub point 
changes. The CPS template recommends daily CRL issuance, and that 
seems to be what the RIRs are doing for the pub points that they 
maintain . Thus it is likely that a new manifest will be issued every 
day. So, I doubt that many manifest cert will be revoked.

The GB record is likely to be very stable, as it provides contact 
info for the pub point maintainer. I don't see freshness attacks on 
these records as a big deal.

A ROA expresses a binding between a prefix and an ASN. I would expect 
most of these to be fairly stable, and that operators would follow a 
make-before-break policy. That suggests that ROA cert revocation will 
be relatively infrequent, and will not require immediate 
dissemination.

So, I am not convinced that there is a need for a different approach 
to disseminating revocation status.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 03 Nov 2011 08:00:07 -0400

> as  a very significant risk to my operations.  

This is something of an aside --but I find the entire discussion about
"semantics violations" a bit of a red herring. If we are to secure every
possible "semantic violation," then we should also be securing
communities, next hops, and verifying the AS of the peering router is
actually the AS contained in the AS Path --in a way that operators
multiple hops away can check. These are all also "BGP semantics," not
just the AS Path.

> auspices  of  "Threat Model for BGP Path Security".  I.e., it is not an

The bottom line issue --as I see it-- is that we've never properly
defined the problem space.

To secure something requires that everyone understand the intent,
whether by implying it from inband signaling, or knowing it through out
of band signaling. SIDR --and hence this threats document-- has been
going down the path of "we want security without knowing intent." A
logical impossibility.

So, I agree with Danny --this document doesn't cover the threat space,
and shouldn't be published. Instead, we need a real analysis of the
entire threat space, without regard to the difficulty of actually
securing that space.

> and consider the gaps that exist, then it's hard for me to justify the 

To put this in different terms:

1. You can't know if something is "secure" without knowing the intent of
the "authorizer."
2. You can't know someone's intent unless they tell you --inferring
intent is dangerous and bad.
3. Hence, securing a system without advertising intent is impossible.
4. Intent == policy.
5. If you're going to include policy, then you need to consider all
policy, and not just a narrow range of policy "because this is what I
care about, and it's what also happens to be easy to secure."

Whether intent should be transmitted in band or out of band is a matter
of open discussion (though I think we must either resolve to change the
nature of BGP, or resolve to signal intent out of band).

:-)

Russ

---

From: Danny McPherson <[email-masked]>
Date: Thu, 3 Nov 2011 08:06:09 -0400

On Nov 3, 2011, at 7:09 AM, Stephen Kent wrote:

> Having been motived to reread the SIDR charter by Brian's message, there is a simple answer to the in/out of scope question, but it's one you will not like :-). The charter for SIDR states that the secruity goals for the WG are to address two vulnerabilities: authorization for prefix origination and path validation.  Relative to the charter, route leaks are out of scope.  I will add text to the intro for the threat model to state that the scope of the model is defined by the charter, and include the relevant charter text. I hope you'll forgive me for taking the easy path here.

I do not...

The charter is temporal and the product of the WG in the form of RFCs 
will be much more persistent, I'm concerned by a line of reasoning that 
says "Let's ignore and not even enumerate or concern ourselves with 
these obvious threats because the current charter [deliberately] says 
all we have to do is provide semantic validation of the AS_PATH" [and 
doing anything more would quite possibly NOT be conducive to 
expedited publication of BGPSEC].  

> I agree that the integrity that would result from including this attribute under the sig applied by the first AS would provide the secruity you cited. That may make it worthwhile to protect via the sig. However, the accuracy of the assertion being made by this attribute is unverifiable by any of the ASes along the path, and that was what worried me.  But, again, the charter makes this out of scope, i.e., it is not relevant to the origin authorization or path accuracy vulnerabilities cited there.

NIce, another threat that shouldn't be listed because it's not in the charter 
as written or addressed via BGPSEC as is.  If that's the case, then all the 
drafts should include the current revision of the charter and explicit text about 
ignoring all other threats under these auspices.

> That sig provides integrity, which is valuable, but it does not provide a way to verify the accuracy of the assertion by the origin AS. Your concern is that an AS along the route can change the value of the attribute. One might also be concerned that the origin set the value incorrectly. Ultimately, I think this is a bad example for us to argue about, as it is a vestigial part of BGP, from EGP days, that is the penultimate basis for route decisions.

No, it is used today and opens up traffic attraction attacks, please don't 
brush it aside because it's 'penultimate' in the decision process - it is 
there and it impacts traffic today.

> It is up to each RP to decide whether to rely on assertions made by an expired cert, or to act as though the cert does not exist. In the routing context, there appears to be some agreement that relying on expired certs is more desirable

There is only room for two states, right?  Valid and not valid.  Stale == not valid.

> the cert holder was sloppy, and failed to renew the cert, i.e., pay the CA. Expiration is not as negative an indication as revocation.

Or because a CA was compromised - we've seen this in the real world with
increased frequency, as you well know.

> There is a subtly here, and thanks for pointing it out. The idea is that if an RP has a cert, and it was not revoked, then the RP can continue to rely on it, after the cert expires, if the RP is unable to acquire fresh data from the pub point for that cert. If the cert had been revoked, it should not be un-revoked because it expired.

And therefore we MUST NOT rely on expired certificates, period.

> I think the phrase "undermines the entire system" is melodramatic. How about "you actual assurance may vary?" :-)

"house of cards", "village of cards"...

> I would prefer more centralization of RPKI data. My original model called for each RIR to aggregate the data for every member, and act as a mirror for the data for every other RIR. But other folks wanted greater distribution. One can argue that wider distribution may offer potentially greater resilience, so ...

Yeah, I get it -- until you get to the point where you have to use expired 
certificates in a PKI and they may have been revoked or may no longer 
be valid or intended for use but because you can't pick certificates up 
from some remote portion of the Internet then you relay on stale (i.e., 
NOT valid) data.  Even if "more distributed", I'm not sure that's added 
resilience, particularly when PKI is employed.

> OCSP is an optimization of the CRL mechanism, designed to efficiently answer a revocation status query for a single cert. Since every RP needs to know the revocation  status of everycert, OCSP (or an analogous mechanism) does not seem to be a good match.  For many years folks have thought that very fast dissemination of revocation status data was important for PKIs.  In reality, revocation is an administrative procedure for which the major delays will be
> created by people deciding whether to revoke a cert, vs. the time it takes to disseminate the CRL.

And I'm saying that if we're going to employ a PKI solution on a distributed 
loosely coherent resource certification infrastructure that's going to be employed 
by RPs in a non-determinsitc manner and result in "periodic updates" in the 
routing system in order to minimize exposure windows, then we ought to look 
at what architectural approaches can be considered or what new elements 
invented to minimize unneeded state and churn in the network and maximize 
resiliency without introducing the possibly for any array of new attacks.

We've already seen issues where such an approach has been problematic with 
DNSSEC in the wake of portions of the Internet being fragmented and causing 
issues and inability to update certificates in the system at root, TLD and SLD 
levels, and what you're proposing here is far far more troubling.

> Because revoking a CA cert has major implications, so such a decision will not be taken lightly. Thus I expect relatively few revocations of CA certs and the principle delay will be procedural.

Yes, just as with SSL certificates today - but when they do happen, the more
quickly you can become aware of that revocation the better off you;re going to 
be -- and it's all still inherently reactive from a controls perspective.

> All of the EE certs defined so far (not counting router certs for BGPSEC, which have yet to be agreed upon) are embedded in RPKI objects: manifests, ROAs, and GB records.
> 
> A new manifest MUST be published whenever any file at a pub point changes. The CPS template recommends daily CRL issuance, and that seems to be what the RIRs are doing for the pub points that they maintain . Thus it is likely that a new manifest will be issued every day. So, I doubt that many manifest cert will be revoked.

But when they are, you better get'm fast...

If you're intended to play the "charter says .." card then we're wasting our time.
At least I've got my concerns on record for broader reference..  This is unfortunate.

-danny

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Nov 2011 11:43:12 -0400

Danny,

I'm reducing my reply to minimize what has become a tedious process.

...

>expedited publication of BGPSEC].

While I appreciate your concerns, comments from one WG member do not 
warrant changing the scope of a document to extend beyond the WG 
charter. When the charter changes, or upon direction of the WG chairs 
I will revise the doc.

>resiliency without introducing the possibly for any array of new attacks.

Feel free to propose such mechanisms.

>levels, and what you're proposing here is far far more troubling.

Can you point me to reports on those incidents. I have not heard about them.

...

>If you're intended to play the "charter says .." card then we're 

Yes, we are both wasting our time at this stage.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 Nov 2011 09:19:52 -0700

> Yes, we are both wasting our time at this stage.

Maybe not. The charter does not say "every other topic cannot even be mentioned": instead, the charter limits the topics that are meant to be fully covered by the protocols.

Personally, I would prefer to see the threat model document say in the introduction "the following topics are considered to be BGP security threats but are not dealt with in this document:" followed by a list that includes route leakage (with a concise definition of what is meant by it in this context). A similar statement in the Security Considerations section would also be useful for the people who tend to skip introductions but still need to know the limitations of the document.

--Paul Hoffman

---

From: "George, Wes" <[email-masked]>
Date: Thu, 3 Nov 2011 13:33:01 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman

> the charter limits the topics that are meant to be
> fully covered by the protocols.
>
> Personally, I would prefer to see the threat model document say in the
> introduction "the following topics are considered to be BGP security
> threats but are not dealt with in this document:" followed by a list

[WEG]
+1, or even have the document deal with them at least briefly, but be clear that the current scope (or other limitations) makes it difficult to solve them.

Not to put words in Danny's mouth, but I think that there are two general concerns being raised about this document and the -reqs document.
The first, which is far easier to deal with, is that a document(s) that should be relatively solution-agnostic is being tailored to preselect/justify an existing (though still nascent) solution based on the current charter scope. It should be a full discussion of the problem space that leads to selection and prioritization of the important problems to solve, acceptable risks, etc. This then serves as a method to (design and) evaluate a solution, whether there's only one, or whether there are multiples.
I too find it a bit strange that we're doing things in the reverse order (or in parallel), as usually these sorts of docs are written because the solution doesn't exist yet, and this helps to clearly articulate the problem space, rather than retroactively defining it. Am I missing something regarding the intent of these documents?

The second is more a question of charter, and scope for the solution, which is definitely limited by charter. However, having a more comprehensive document on threats and design requirements may indeed drive a review of the scope and charter, either because it brings to light additional considerations, or because those who actually need to implement the solution on their networks have provided feedback that leads to a different conclusion.
I'm not recommending that we analyze the problem forever, because a partial solution that is deployable may indeed be better than a theoretical one that solves more problems, but never materializes (or at the very least takes longer). But there is a balance point between those, and I'm not totally certain we're at that equilibrium yet, regardless of the current charter. There have now been multiple folks expressing concerns over the costs (be they operational, capital, expense, etc) to implement vs the benefit based on what risks are mitigated by the solution vs which are not and the exposure that represents to one's chosen line of business, so there's some value in having an eyes-wide-open discussion about it.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Shane Amante <[email-masked]>
Date: Thu, 3 Nov 2011 11:38:15 -0600

> +1, or even have the document deal with them at least briefly, but be clear that the current scope (or other limitations) makes it difficult to solve them.

Another +1.

> I too find it a bit strange that we're doing things in the reverse order (or in parallel), as usually these sorts of docs are written because the solution doesn't exist yet, and this helps to clearly articulate the problem space, rather than retroactively defining it.

+1

> Am I missing something regarding the intent of these documents?
> 

+1

-shane

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 03 Nov 2011 18:49:11 +0100

hint: the reqs draft was based first on draft-ietf-rpsec-bgpsecrec-10.

randy

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 3 Nov 2011 13:49:34 -0400

On Nov 3, 2011, at 11:43 AM, Stephen Kent wrote:

> While I appreciate your concerns, comments from one WG member do not warrant changing the scope of a document to extend beyond the WG charter. When the charter changes, or upon direction of the WG chairs I will revise the doc.

So, I have been watching this thread and reading the interplay.  Likely many of us (but at the very least, I) have been waiting with baited breath for answers to these issues, or at least a beginning to discussions of follow-on work to address them.

However, since there appears to be need for more than one person on record: I also share these concerns.  Fair?

<snip>

> Yes, we are both wasting our time at this stage.

Disagree.  These are important issues, and it seems that some design work needs to be done to address them.  afaict, there are issues in the design that may be exposing attack vectors.  I can't see how claiming, "we are both wasting our time at this stage," is an acceptable response.  These are real security threats that may exist if specifications are minted as is.  imho, they _must_ be addressed, not ignored.

Eric

---

From: "George, Wes" <[email-masked]>
Date: Thu, 3 Nov 2011 14:13:02 -0400

> From: Randy Bush [mailto:[email-masked]]
>
[WEG]
A useful thing to have noted in the document itself for us young whippersnappers, perhaps in the acknowledgements.
I also note that there is good additional discussion in 4.1, 4.5, while the reqs draft only includes the bulleted items. Cf. my email about including more explicit performance envelope requirements.

Wes George

---

From: Danny McPherson <[email-masked]>
Date: Thu, 3 Nov 2011 17:07:44 -0400

> Can you point me to reports on those incidents. I have not heard about them.

I could cite others, but this should serve the purpose:

<http://www.nytimes.com/2011/01/29/technology/internet/29cutoff.html>

Consider this and assume operators had infrastructure (e.g., root & TLD 
servers) that was serving signed zones that couldn't be updated and expired
while partitioned from the rest of the Internet.  The result is that validating 
recursive name servers within that catchment couldn't validate the received
responses, and they were therefore not valid and not able to resolve 
resources.

Designing a system so reliant on heavy cryptography machinery, but then 
saying "just use expired certificates if you can't update your caches", that's 
crazy talk that would likely violate most of our day job security policies for 
even SSL or VPN access policies -- and here we want to apply it to a newly 
enhanced routing protocol  and resource certification infrastructure --- I 
challenge that assumption.  

And on further reflection, I think recommending that expired certificates 
be used (even in algorithm rollovers, presumably for the purpose of fixing
cryptographic vulnerabilities) may well NOT be aligned with our two primary 
charter objectives:

I intend to ask the security ADs for a statement on suitably of use for 
expired certificates, and would appreciate such an explanation from the
SIDR technical advisor as well as the chairs at the upcoming meeting.

-danny

---

From: Jen Linkova <[email-masked]>
Date: Fri, 4 Nov 2011 12:57:06 +1100

Hi,

> Personally, I would prefer to see the threat model document say in the introduction "the following topics are considered to be BGP security threats but are not dealt with in this document:" followe…

First of all, sorry to butt in. Just a few comments if you don't mind.

0) There are some security issues with BGP. (Sorry for making such
commonplace remark); then:

1) BGPSEC offers countermeasures for some BGP-specific threats
mentioned above (! not all of them indeed) but:

2) it also introduces some additional new threads (specific to BGPSEC);

3) after reading this thread (please excuse me if I missed smth) I got
an impression that there is a kind of confusion about if the document
in question shall describe #1, #2, #3 or all of them. Probably it
should be clarified.

4) I might be horribly wrong but route leaks is a security thread as
it affects an availability of a target system (providing we define
information security as confidentiality, integrity and availability of
information).

5) I totally agree that route leaks don't violate BGP as a protocol
and are related to policies. But it doesn't mean route leaks are not
security threats. Receiving spam/viruses via email is a threat
although it doesn't violate any SMTP standards.

6) route leaking is related to a BGP threat model and isn't specific
to BGPSEC, and BGPSEC doesn't provide any protection from that threat.
So I'd like to second the idea of clarifying that in the document.

-- 
SY, Jen Linkova aka Furry

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Nov 2011 00:49:47 -0400

(coming in late to the party, weee!)

>> communities, and even the next hop.

err, so... you receive a route update from AS1 at AS2, it looks roughly like:
   1.2.3.0/24 nh = 192.168.1.1
  this is signed (all of the above data)

When you pass this route off to AS3 you do so as:
   1.2.3.0/24 nh = 10.1.1.1
  the nh changed, the sig originally is for 192.168.1.1

Did you really mean to sign the next-hop? it seems infeasible...

Also, LocalPref is a locally used/determined/created (non-transitive)
item, adding that set of bits into the signature seems blatantly
wrong, since the data won't exist when you pass the route outside your
ASN the verification is going to fail, for every route you send (which
had a localpref != default), That CERTAINLY seems like something you
would want to avoid, right?

-chris

---

From: Brian Dickson <[email-masked]>
Date: Fri, 4 Nov 2011 01:32:20 -0400

> would want to avoid, right?

Er, on non-transitive items like LocalPref, there is a use case for signing
them iff the iBGP elements are decided as being in-scope.
(I agree with Danny on this being worth considering.)

What we are discussing is the threat model, and how threats could be
countered.

This in turn is used to inform the design of the protocol, not vice versa.

So, when I say "signed", what I was thinking of was something along the lines
of a sequence of  blocks that might look something like:
LocalBGPPerHopData
signature(LocalBGPPerHopData|previousSignature)
and after all those blocks,
originatorSignature(FirstHopData|RPKI-validatable-data)

The stack gives a history of transitive and non-transitive values,
some of which won't be used for local policy decisions per se, and some of which
can quite reasonably have been changes at each hop. The signatures protect
that data.

How the protected data itself is used is local policy, for selecting best path.
This is more information than vanilla BGP has, of course, but arguably allows
for better path selection by virtue of more data being available locally.

Note that nothing is present than is generally known through various
data sources,
including local BGP tables, looking glasses, routeviews/Renesys, traceroutes,
whois, RADB/IRR, RIRs, reverse DNS etc.

Adding this "stack" allows for other aspects of local policy to be
marked into the path,
including markers suitable for preventing route leaks.

It also means that non-transitive values can magically become pseudo-transitive,
presuming the cruft that permits constructing local policy can be made
to understand
the association between AS-path hops and the captured policy at those hops.
(This is a feature, not a bug.)

The signatures make it possible to reject changes to this stack of
path-historical data.
The data makes it possible to choose to use the originated values, the
latest values,
or anything in between, however one chooses.
The requirements to continue adding to this stack ensures the next AS
to which the
prefix is sent, has the same opportunity to apply local policy.
Add a dollop of 'transit/non-transit' at each hop (mandatory but
arbitrary), and simple
leak-blocking (nearly fool-proof, in fact) is possible to support.

Brian

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Nov 2011 09:09:20 +0100

> Er, on non-transitive items like LocalPref, there is a use case for
> signing them iff the iBGP elements are decided as being in-scope.  (I
> agree with Danny on this being worth considering.)

send draft

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Nov 2011 09:11:11 +0100

> So I'd like to second the idea of clarifying that in the document.

could someone post a clear technical explanation of WHAT a route leak
is, HOW one would definitively detect all cases of them, and WHAT one
would do about it?

you are correct, BGPsec tries to secure the BGP protocol against abuse,
not protect the internet.  the latter is a very worthy goal but a bit
nebulous.  of course an internet draft or two might clarify that.

randy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 4 Nov 2011 09:02:08 -0400

>(I agree with Danny on this being worth considering.)

The design team discussions had dwelt with this issue some.
The thinking at the time is captured in:  
 http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-2.4 
You may also like to glace at the section where iBGP and confeds are discussed:
 http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-7.3 

>So, when I say "signed", what I was thinking of was something along 
>the lines of a sequence of  blocks that might look something like:
>LocalBGPPerHopData

As I see it, there are three questions to ask here:
1. How much utility or relevance does the content of 
LocalBGPPerHopData have two or three hops way?
2. What exactly are the security needs of the content of 
LocalBGPPerHopData, and can they be met adequately with 
hop-by-hop transport layer protection?
3. It appears that ISPs are currently NOT used to having local info 
(such as LocalBGPPerHopData) carried across the Internet to ASs 
that are more than a hop away.
So would they like all this (which may well give away business policy
info) being carried in eBGP updates across the net?

As an example, in the origin or path validation context, AS-A may 
pass on its BGP update validation results to AS-B (both ASs managed 
by the same ISP) in eBGP encoded in a Community attribute but 
does not want it to be propagated beyond AS-B. If AS-A is required to 
sign over that attribute (along with the NLRI or previous AS's sig), 
then AS-B is not in a position to supress the attribute. 

May be it makes sense to discuss the possibility of a separate signature
for LocalBGPPerHopData that is applicable only over a single hop 
and then it must be dropped. That is, if relying on transport layer
protection for protecting LocalBGPPerHopData is considered inadequate.          

Sriram

---

From: Eric Osterweil <[email-masked]>
Date: Fri, 4 Nov 2011 15:05:13 -0400

Hey Randy,

> is, HOW one would definitively detect all cases of them, and WHAT one

This is a list of three questions.  Until there is discussion of the first, it is premature to address the second two.  Therefore, how about we just choose a specific case of the first: how would BGPSec protect against an instance of an event found here:
	http://puck.nether.net/bgp/leakinfo.cgi

> nebulous.  of course an internet draft or two might clarify that.

This seems like a very pedantic distinction.  Having an AS' traffic routed through an invalid path seems like a BGP protocol abuse to me.  So, in that language, it seems to me that this issue is in scope (i.e. if the path is to be protected, then subverting it is an abuse).

Eric

---

From: Brian Dickson <[email-masked]>
Date: Fri, 4 Nov 2011 16:52:00 -0400

On Fri, Nov 4, 2011 at 4:11 AM, Randy Bush <[email-masked]> wrote:
> is,

I'll bite.

It requires carefully a constructed definition, first:
"Customer" - A is a customer of B iff A has an arrangement with B
which explicitly allows B to announce A's routes to any third party,
and for B to announce B's entire routing table to A.

Customer is a technical arrangement, regardless of how or why that
arrangement was arrived at, e.g. paying money.

If A is a customer of B, A is allowed to announce A's own routes (and
by extension A's customer's routes) to B.
A _may_ (or may not, at A's discretion) signal to B that A wishes B to
forward all (or a subset) of A's (and A's customers) routes to third
parties.
A is not _required_ to do so, and A may further signal that B should
only send those prefixes to a subset of third parties with whom B
peers.

(Observe: B may always announce A's routes to B's other customers.)

A route leak occurs, when B announces non-customer routes to non-customers.

(Those would be routes for which B has not been given explicit
_blanket_ permission to announce to third parties.)

If A (a customer of B) signals to B to not announce a subset of routes
to B's non-customers, but B does so anyways, that would _not_
constitute a true route-leak as such.
(It would, however, be a contractual and technical issue that would
normally be resolved between A and B.)

If it helps, I've tried to illustrate the leak/no-leak distinction below...

Brian

Examples - in the following, I'll use "->" or "<-" to indicate
customer relationships, and "-" to indicate non-customer (peer)
relationships.
The route traverses the AS's left-to-right. A is the originating ASN,
and the highest letter is the receiving ASN.

The following are non-route-leak paths from announcer to receiver:
A - B (A peers with B)
A -> B (A is a customer of B)
A <- B (B is a customer of A)
A -> B <- C
A <- B <- C
A -> B -> C
A -> B -> C - D
A -> B - C <- D
A - B <- C <- D
A -> B -> C - D <- E <- F (and so on)

(There can be only one "-", and all the arrows must point towards the
"-" in the ASCII stick diagram.)

Any of these would be route leaks:
A - B - C
A <- B -> C
A - B -> C
A <- B - C
A -> B - C -> D
A <- B <- C -> D -> E (This is one of the most common sources of
route-leaks. It is one of the easiest mistakes for a network engineer
to do.)
A -> B -> C - D <- E <- F -> G -> H (This is how the previous example
usually is seen in the wild)
A -> B -> C - D <- E - F <- G (Here E is accidentally providing transit to F)

The special case of mutual customers (mutual transit) would be represented as:
A <-> B

Mutual transit/customer arrangements can legitimately do the following:
A -> B <-> C -> D
A <- B <-> C <- D
A - B <-> C <- D
A -> B <-> C - D

Basically, on any given prefix announcement, "<->" can be treated as
either "<-" or "->" in order to fit the "allowed" rules.
If neither of those substitutions fits an existing "allowed" rule,
then the result would be a route leak. Examples of mutual-transit
leaks:
A - B <-> C - D
A <- B <-> C -> D
A - B <-> C -> D

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Nov 2011 17:07:05 -0400

>        http://puck.nether.net/bgp/leakinfo.cgi

I'm not randy, but I was talking about this very thing in the office
today with a co-worker... I'm not clear on how anything can stop an
instance like:
src      time                                        prefix
puck	2011-11-04 16:15:49.157742	8.10.160.0/23	
   path
   2914 2828 12989 12189 3356 19181 19181 19181
  Contact   score  blame_asn
   2828	3	12989

As I read this, 12989 (highwind) is 'accidentally' announcing
reachability for 8.10.160.0/23 (CWIE? AS19181). Looking at one popular
source of routing data:
  <http://www.robtex.com/as/as19181.html>

it actually seems that the 2 people may be peers :( the route that we
see is merely an artifact of their connectivity and 'poor route
selection' inside their networks :(

Point being that in cases like this (or really all route leak cases)
the only thing that stops this is filtering routes between bgp peers.
(transits, customers, SFP peers) There isn't anything in the protocol
itself (which is Stephen's, Russ's, Randy's comment through out) that
tells you/me/them that 12989 should not be permitted to announce this
route. (looking at available data, it seems that they SHOULD, perhaps
not with this ASPath, but...)

How would you go about telling, from the data on the wire in bgp, that
a route is a hijack?
How would you propose changing the data on the wire in bgp today to do
this tomorrow?

Would having data you could mechanically verify about the routes and
origins and relationships (say connectivity only?) between bgp peers
help solve this problem?

In my view I don't see a change to the BGP wire format helping, I do
see existence of data to mechanically verify ownership (and perhaps
connectivity information?) helping.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Nov 2011 17:08:35 -0400

> This seems like a very pedantic distinction.  Having an AS' traffic routed through an invalid path seems like a BGP protocol abuse to me.  So, in that language, it seems to me that this issue is in…

oops, also, still not randy, but... there are lots of ways to bend
traffic in the wrong direction and still keep bgp data 'the same'. I'm
not sure fixing traffic paths is doable in BGP.

Do you see a way to do this in BGP?

-chris

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 4 Nov 2011 17:14:31 -0400

> Any of these would be route leaks:

Why is this a leak?

> A <- B -> C

To me, this (and anything that contains it) is the only leak.

-- 
Jakob Heitz.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Nov 2011 17:23:58 -0400

> arrangement was arrived at, e.g. paying money.

channeling russ: "where is this arrangement publicly documented?" (So
I can know it and put it into my algorithm)

> _blanket_ permission to announce to third parties.)

Where is this documented? (this permissions giving)
How is this enforced? (the permission)
what about cases of partial transit? (I sent a route to B, and
requested he NOT send it to the world at large)
  how is that sort of thing documented? (again, channeling russ)

> constitute a true route-leak as such.

depends on your perspective I suppose, no? Doesn't RPSL today have the
ability to signal: "Send partial routes to Foo and Full routes to Bar"
?

> If it helps, I've tried to illustrate the leak/no-leak distinction below...

it didn't really... re-explaining valley-free routing with mistakes
due to agreements not-available 2 as-hops away isn't helpful. Routes
leak, people should filter... not new knowledge.

-chris

---

From: Brian Dickson <[email-masked]>
Date: Fri, 4 Nov 2011 18:40:33 -0400

> puck    2011-11-04 16:15:49.157742      8.10.160.0/23

I suspect that it is a case of "accidental back-up transit via a peer".
(I have seen this personally, where it was "malicious" instead of "accidental".)

Generally, the problem with prefix-only filtering is it ignores the as-path.
If you build your upstream filter based on who your customers are (nominally)
instead of based on where that route was learned, this can happen.

> not with this ASPath, but...)

It's actually tricky to do in reality. You have to build prefix filters AND
as-path filters AND ensure that BOTH filters are applied to everything.
And that doesn't necessarily always work either. Communities are a big
help...

> How would you propose changing the data on the wire in bgp today to do

I would propose adding a mandatory "bit" signaling "customer" or "non-customer".

In the BGPSEC context, the bit would need to be signed and kept AS-hop-by-hop,
added in a way that unambiguously shows exactly where in the AS-path
it is applied,
and where the bit requires both sides of the peering agree on it. No
unilateral bit-setting.

The status from the last AS-hop, however is all that is really needed.
Local announcements start with the bit set.
Going "upstream", the customer bit gets kept. Upstream is only allowed
if the bit is set.
Downstream is always allowed, and the bit is always cleared.
Sending to peers is only allowed if the bit is set, and in the process
the bit is cleared.

(Mutual transit means the bits are kept and all routes are sent.)

Once a route crosses a peer connection or goes "downhill", it can no
longer go "uphill"
or cross another peering link.

Uphill N times, one peering link (optional), downhill M times. No exceptions.

Of course, filtering or marking to restrict individual prefixes can be
added to this,
without violating the restrictions. (More restrictive, good. Less
restrictive, very bad.)

In fact, I'd add it to the negotiated capabilities (being
offered/requested) so it gets configured
on each "neighbor" statement: Transit-Offered; Transit-Accepted; or in
the oddball case, both.
Only if there is match between one side offering transit and the other
accepting it, is the status
set.

In a left-to-right representation of an AS path, there would be four
possibilities:
XXX <t> YYY (Y provides transit to X)
XXX <c> YYY (X provides transit to Y, i.e. Y is a customer of X)
XXX <p> YYY (X and Y are peers)
XXX <tc> YYY (X and Y are mutual transit buddies)

An example representation of AS-path-plus-bit might look like:

2914 <c> 2828 <c> 12989 <t> 12189 <t> 3356 <c> 19181 19181 19181

In the above case, the sequence "<c> .* <t>" shows where the problem was.
Having the protocol enforce the restrictions would have stopped the leak.

> origins and relationships (say connectivity only?) between bgp peers

Yes, and I believe the relationship info, even on the most recent AS-hop,
would be sufficient. While the protocol enforcing it would fix things, there
is the issue of trusting the implementation/implementors, so I think there
would still be a requirement to sign at each leg, and validate all signatures
and hops.

The sender signing her interpretation of the status, with the receiver
authenticating
and having the ability to reject if either the signature is bad, OR if
the signed
status of the relationship does not agree with the receiver's idea of
the status,
ensures local bad actors are caught right away. Non-local bad actors is what
further requires all signatures be built with the peering-type. Enforcing the
restriction on the peering-type-path stops the leaks.

> connectivity information?) helping.

Yep - and without requiring extrinsic information (i.e. does not
require the information
be in an IRR-type database, can be marked locally in the path, as long as the
peering type is mutually negotiated at each hop.)

Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Nov 2011 01:59:31 +0100

> not with this ASPath, but...)

we can not know intent.

to take it to one extreme, did the pakistani operator mean to 'leak'
youtube's prefix or not?

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Nov 2011 02:21:39 +0100

> I suspect that it is a case of "accidental back-up transit via a
> peer".  (I have seen this personally, where it was "malicious" instead
> of "accidental".)

and i have seen it intentional and pre-agreed.  life is not just simple
customer, peer, upstream.

randy

---

From: Eric Osterweil <[email-masked]>
Date: Fri, 4 Nov 2011 21:29:22 -0400

> to take it to one extreme, did the pakistani operator mean to 'leak'

So, in the spirit of not forking the thread too many more times than necessary, I'll try to speak to both of these comments here.  Sorry, if this misses some of context from the snipped text, lemme know if there was important context I missed and I'll backup to that).

I think the distinction between a leak and something more intentional s a matter of policy.  Knowing the policy associated with the adjacencies that an AS is leaking over would allow leaked announcements to be identified, right (or am I in the weeds on this)?  If so, then one could use policy to filter announcements that violate that.  If an intentional leak (i.e. path hijack) were launched, one could use the policy statements that authorized the leak as evidence of intent, or at least a hammer to hit someone over the head with.

As for Pakistan, iirc that was an origin hijack.  In this case, the origin authenticity was the issue, and that problem should be solved through resource certification.

Eric

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Nov 2011 02:34:48 +0100

> I think the distinction between a leak and something more intentional
> s a matter of policy.  Knowing the policy associated with the
> adjacencies that an AS is leaking over would allow leaked
> announcements to be identified

o We can not know intent, should Mary have announced the prefix to Bob

o But Joe can formally validate that Mary did announce the prefix to Bob

o Policy on the global Internet changes every 36ms, new customers, new
  peers, circuit moves, ...

o We already have a protocol to distribute policy or its effects, it is
  called BGP 

o BGPsec validates that the protocol has not been violated, and is not
  about intent or business policy

randy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Nov 2011 21:52:45 -0400

> to take it to one extreme, did the pakistani operator mean to 'leak'

right, the only save there is the filtering PCCW was not doing...
which was my point (I believe)

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Nov 2011 21:57:44 -0400

> As for Pakistan, iirc that was an origin hijack.  In this case, the origin authenticity was the issue, and that problem should be solved through resource certification.

or by simply applying a filter to your customer, in no world would it
have been proper to accept that set of routes from PKT to PCCW.

---

From: Danny McPherson <[email-masked]>
Date: Fri, 4 Nov 2011 22:30:43 -0400

>  about intent or business policy

o And therefore, BGPsec does not mitigate the leak problem, agreed

o Not mitigating the leak problem could be an unacceptable residual
risk to many looking to better secure BGP, particularly given that it's a 
natural evolution to attackers in a world of "BGPSEC/SBGP", and can 
happen as a simple matter of misconfiguration, as Jared's leak page
illustrates: http://puck.nether.net/bgp/leakinfo.cgi

o BGPSEC is awfully heavy to not address this fundamental "business 
policy" vulnerability

o As for "bits on the wire" solutions, I don't recall seeing that as a hard 
requirement, although I will admit that BGPSEC certainly goes a long 
way to turn RPKI into "bits on the wire", which has _many implications

o I'm pretty sure I can configure static routes every 36ms with far less 
overhead

o By your definition, I'd prefer to solve the "business policy" problem.

-danny

---

From: Shane Amante <[email-masked]>
Date: Fri, 4 Nov 2011 20:39:57 -0600

Hi Chris,

> puck	2011-11-04 16:15:49.157742	8.10.160.0/23	

The specific route leak noted above would _NOT_ appear if one or more of those AS'es was following what I thought was a "Best Current Practice"[1] of performing AS_PATH filtering for peer ASN's showing up on routes from their customers.  Please note that this is an extremely simple set of 3 lines of config to 'sanity check' inbound routes from customers, (similar to and probably in the same route-map/policy-statement that is, hopefully, rejecting RFC1918 prefixes from customers, as well).

If we can't seem to get the basics right, then how well do we expect a much more complicated set of machinery, which doesn't currently account for this particular scenario anyway, to perform?  Or, to be more sanguine :-), if these BCP's were used, then how much would that reduce the attack surface area, in the _real_ world, that is presently trying to be solved for?

-shane

[1] I wish I could point to an authoritative reference, but I don't recall one.  Perhaps someone with a better memory and/or search skills can find one.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Nov 2011 22:56:16 -0400

> Hi Chris,

chello!

> The specific route leak noted above would _NOT_ appear if one or more of those AS'es was following what I thought was a "Best Current Practice"[1] of performing AS_PATH filtering for peer ASN's sho…

agreed, some manner of prefix + as-path seems like it'd sure solve
this problem. :(

> If we can't seem to get the basics right, then how well do we expect a much more complicated set of machinery, which doesn't currently account for this particular scenario anyway, to perform?  Or,…

I agree with some of this sentiment... I think one of the hopes is
that making this simpler over all (knowing that the path you see is
correct & that the prefix-list/as-path filters can be made
automagically) we'll get more BCP deployment. [1][2]

-chris

[1]: ws.edu.isoc.org/data/2006/2134808751448228e3c2055/bgpbcp.ppt
[2]: csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf

---

From: Shane Amante <[email-masked]>
Date: Fri, 4 Nov 2011 21:12:29 -0600

Hi Chris,

> agreed, some manner of prefix + as-path seems like it'd sure solve

Please note that, for the specific case above, I did not mention "complicated" & "burdensome" prefix-list filtering … just AS_PATH sanity check filtering, i.e.: if you see AS (FOO|BAR|BAZ) in the path, drop (don't learn) the route.  Also, I would note that this type of configuration re-emphasizes what Russ White has said, specifically that (this) policy is local to each AS and is _not_ 'shared' with any other ASN.

> automagically) we'll get more BCP deployment. [1][2]

Thanks for the pointers … now I need to go read them.  :-p

-shane

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Nov 2011 23:22:54 -0400

> Please note that, for the specific case above, I did not mention "complicated" & "burdensome" prefix-list filtering … just AS_PATH sanity check filtering, i.e.: if you see AS (FOO|BAR|BAZ) in the p…

understood, don't disagree... and yes, Russ's point about the local
policy not being exposed publicly means ... we can't today figure this
out easily.

-chris

---

From: Geoff Huston <[email-masked]>
Date: Sat, 5 Nov 2011 15:09:47 +1100

> o We can not know intent, should Mary have announced the prefix to Bob

I disagree with this assertion of impossibility. The intention of the routing
policy databases in their various flavours and incarnations was to publish
intent and allow others to filter based on intent.

Yes, there is a viable form of filtering wayward prefix advertisements
that are of the form of adherence or otherwise to published intent, and if
everybody scrupulously entered the entirety of their routing policy into
some form of routing policy database then indeed there could be a viable
case to be made that you could create a routing security framework based
on such foundations.

So I'm not dismissive about the impossibility to know intent. One can
in theory know intent, and filter based on intent.

In many ways this is not so much different than what is going on with the
effort to secure the outcome operation of the protocol. In this case the routing
intent of the originator is not exposed, but it is possible to expose the relationship
between the originator and the prefix holder, and expose the authenticity of
inter-AS transactions that are described in the AS path. Again the same observation
is that this only really works if everyone plays along, otherwise the gaps
in the knowledge based of signed attestations cripple the general benefit of the outcome.

So these are two different sides of a validation coin, if you'll pardon the
analogy. One side says "I have no idea if BGP is being warped and twisted
or not, but if what I hear from my peer conforms to the set of published routing
policies, then I'll accept the update", while the other says "I have no
idea if this was intentional or not, but what I have received is not the
result of warping and twisting the operation of the BGP in unnatural ways
then I'll accept the update".

I suspect that most of this thread is these two points of view arguing past 
each other.

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 5 Nov 2011 00:21:34 -0400

> or cross another peering link.

Why can it not cross a peering link?

--
Jakob Heitz.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 5 Nov 2011 00:35:12 -0400

> Why can it not cross a peering link?

When two networks peer, they agree to exchange routes for their
respective customers.

If A announces a route to B, that route is A's customer and _not_ B's customer.
So, by the nature of the agreements, B cannot announce that route to
another peer, C.

Take the worst case - a tier-1 network. All their routes are either
customer routes, or peer routes.
If they were to send their peers' routes to their peers, they would be
sending all routes to everyone.
They would be providing transit, for free, to their peers. This would
not be good for many reasons.

Put another way - when network B sends routes to peer C, it is
providing transit to those routes.
It generally only wants to do that for customers, especially if that
happens to be its primary business.

Brian

---

From: Russ White <[email-masked]>
Date: Sat, 05 Nov 2011 08:34:09 -0400

> Did you really mean to sign the next-hop? it seems infeasible...

The constant answer to any challenges to the requirements documents is: 
"We are simply protecting BGP semantics with signatures."

1. Signing a semantic doesn't make it secure.
2. If you're going to claim you're all about protecting BGP semantics, 
then protect all of them, not just one.

> would want to avoid, right?

So what you are saying is that you don't want to protect attributes that 
aren't carried more than one hop through the internetwork --I.e., next 
hop is only carried between one set of (presumably) locally connected 
eBGP peers, so it shouldn't be protected. This leaves us with two problems.

==
1. Since many other attributes carried in this fashion actually impact 
the usability or trustworthiness of a route, what justification can you 
give for not protecting them? Because it's "too hard?"

2. You say:

AS1--AS2--AS3

AS1 shouldn't care about what goes on between AS2 and AS3. But wait... 
Then why should AS1 care about the AS Path interactions between AS2 and 
AS3, precisely? How can AS1 really trust that traffic it sends to AS2 
will actually be forwarded through AS3 if next-hop games are going on 
between AS2 and AS3? Or local pref games are going on within AS2? Or AS3 
is sending AS2 some community that AS2 is locally interpreting in some 
way that would impact AS1's decision about forwarding along that path?

The reality is that local decisions impact the global reliability of 
each piece of routing information.
==

I would posit all this confusion comes from simply not doing a good job 
of defining the problem in the first place. A solution was chosen first, 
and then a problem set found that this specific solution could "solve" 
(and no other!), regardless of the secondary problems and complexity the 
chosen solution might happen to bring to the table.

Which is why I oppose adoption of this draft as a WG document.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sat, 05 Nov 2011 08:48:52 -0400

>> o We can not know intent, should Mary have announced the prefix to Bob

Let me point out a fundamental issue here.

Security is, and always has been, about matching intent with reality. If 
I lock my doors, there is an implied intent that no-one go into my house 
(in band). If I give a neighbor a key, I will give them explicit 
instructions as to my intent --"only go in if the dog is barking, or to 
feed the dog, or..." (out of band)

You MUST know intent to provide security. Get over it. You can't match 
expectations to reality unless you know what the expectations are.

What is the entire security model of the RPKI and origin auth? To ensure 
the intent of the RIR in assigning address space is followed, and to 
ensure the intent of the owner of that address space is carried out.

You could argue that you're only trying to secure the "semantics of 
BGP," which means you're trying to enforce the intent of the BGP 
specifications (you can't get away from intent!), but that opens up 
another wormhole of problems.

"You can't prove intent" is a red herring.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sat, 05 Nov 2011 09:00:16 -0400

>> Please note that, for the specific case above, I did not mention "complicated"&  "burdensome" prefix-list filtering … just AS_PATH sanity check filtering, i.e.: if you see AS (FOO|BAR|BAZ) in the path, drop (don't learn) the route.  Also, I would note that this type of configuration re-emphasizes what Russ White has said, specifically that (this) policy is local to each AS and is _not_ 'shared' with any other ASN.
>

Unless you're willing to expose your policy publicly, or at least within 
the realm of partners you expect to help you enforce it. One of the 
problems with SIDR has been the constant insistence that "policy not be 
exposed publicly."

I'll say it again.

1. All security is about exposing and enforcing intent.

2. You can only secure intent you know and understand. You can't expect 
someone who doesn't know what you mean to do what you want, no matter 
how nicely you ask.

3a. We can decide that those who want to secure anything must publicly 
(or semi-publicly) declare what it is they want secured.

3b. We can decide that we "only want to secure the BGP spec," which 
opens another wormhole (though if that's the wormhole you'd like to go 
down, I'd be happy to transfer this work to IDR, where the experts on 
that spec live).

3c. We can continue down the path of, "we can't tell anyone what we want 
them to do, we just expect them to read our minds and do what we intended."

SIDR seems determined to do 3c, no matter how unwise or how unrealistic.

:-)

Russ

---

From: Brian Dickson <[email-masked]>
Date: Sat, 5 Nov 2011 14:34:22 -0400

> o We can not know intent, should Mary have announced the prefix to Bob

This is a semantic issue, and I think can best be viewed within the
realm of knowing/proving.

You can't prove a positive, but you can prove a negative.

If the semantics regarding intent are limited to negatives, I believe
it is possible to correctly infer one aspect of intent.

See below for an analogy...

>  peers, circuit moves, ...

So long as the policy expression point is eBGP peering sessions, and
that marking is mandatory and inherited by routes crossing those
sessions, the 36ms issue itself becomes moot.

BGP is stateful, and all of these things that involve the above
new/changed eBGP things (peering sessions, customers, peers) involve
stateful changes. Tying policy (and policy changes) to only eBGP
sessions, regardless of other things that influence route
announce/withdraw/attribute-change means routes marked when crossing
eBGP boundaries will always be statefully-correct. (The presumption is
that _policy changes_ on eBGP will automatically require
re-announcement of all prefixes across that session, either by forced
soft reconfig outbound enforced by the protocol, or an actual session
reset.)

Here is what I hope is a useful analogy to illustrate "negative intent".

Consider the realm of business communications of written material,
e.g. either paper or via signed (S/MIME) email.
Consider this realm where the only additional policy component is the
Non-Disclosure Agreement.
Presume NDA material is presumed here to always be marked, including
with who the NDA parties are. Also presume chain-of-custody style
marking history, if material is re-sent to other parties.
Presume NDAs permit material to be communicated to parent companies,
to subsidiaries, and even to joint-venture subsidiaries.
Presume NDAs permit material to be exchanged between the signatories,
and their subsidiaries, and vice versa.
Presume NDAs do not permit sharing with any other party.
Presume NDAs do not permit joint-venture subsidiaries who receive
material from one parent, to be sent to the other parent, even the
other parent is one of the two NDA signatories. (Think of this as
parents -> subsidiaries having additional/separate NDAs that also get
stamped on material shared to the subsidiary.)
Presume NDA material exchanged by their respective subsidiaries can
only be sent directly via the signatories themselves.

Now consider the scenario when someone who isn't a signatory with any
of the above NDAs between A and B, i.e. someone who is neither A, nor
B, nor a subsidiary or joint-venture subsidiary (direct or indirect)
of A or B.

The recipient has a chain-of-custody cover sheet showing who sent it to whom.
A responsible actor would do what with this document? (I propose the
answer, presuming every document is a duplicate, not an original, is
to destroy it.)

A bad actor might use it, and might forward it to someone else.
The party receiving from a bad actor is able to correctly infer from
the attached NDAs and chain of custody documents, that the immediate
sender is in fact a bad actor.

I would argue that regardless of why or how one receives such a
document, the _definition_ of bad actor can be derived from whether or
not he/she destroys the improperly communicated document. A bad actor
is _de_facto_ someone who accepts the document without destroying it.

Note also, in this arbitrary analogy, the following also apply:
- not every document has an NDA.
- not every extra-org arrangement will be NDA'd
- chain-of-custody is presumed to be based on crypto, and includes
chaining of signatures (a la BGPsec's current I-D doc)
- chain-of-custody is present whether there is an NDA or not
- multiple NDAs can be present, esp. when documents are sent to
subsidiary^n'th org)
- NDA was chosen because it generally is included in employment
agreements governing behavior of individual actors within an
organization
- Employment agreements may even have restrictions on
improperly-received non-public (NDA) material to which employer is not
an NDA signatory

And finally, here's how this analogously applies to a possible
addition to BGP/BGPSEC:
- adding a flag or flags to eBGP peering sessions, indicating:
  - whether or not the sender wants to _limit_ distribution of routes
that are sent (to just recipient's "customers" - should be default on,
turned off only when sender is transit customer of recipient);
  - whether or not the sender wants to _send_ (otherwise)
distribution-limited routes (e.g. those learned from peers - default
off, turned on only when sender is transit provider to recipient)
  - whether or not the recipient will _accept_ (otherwise)
distribution-limited routes (e.g. from a transit provider - default
off, turned on only when recipient is trasnti customer of sender)
- default values equate to "true peer" - I send my customers' routes
(and customer^n'th routes), and distribute your routes only to my
customers.
- Controls automatic blocking only; local policy cannot override this
blocking, but can do anything else it wants/need. If local policy is
being blocked, there are ways to change the peering flag-bits to
enable that policy (caveat emptor)
- Permits implementation of any neighbor-neighbor policies, including
mutual transit
- Blocks route leaks in all cases except (idiotic) multi-party mutual
transit (more than one consecutive hop with mutual transit), and even
then, route leakage is constrained to at most one AS-hop away from
such a contiguous mutual-transit "mess"
- Requires only signaling negative-intent - ''Don't send this in an
unconstrained fashion". It's the only (new) bit set on routes; the
rest of the bits on peering session control whether/when this bit gets
set, or when/how to block based on this bit. The intent is clear, even
when the route is seen many AS-hops away.

Some things just work better when done on a white board interactively
- sorry if this is not as clear as it was intended.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 7 Nov 2011 14:08:43 -0500

> customer, peer, upstream.

I think many of us have seen "special" arrangements, either first-hand,
or involving our customer(s) as one or more of the parties to such an
arrangement.

I think if we categorize neighbors as "customer, transit, peer,
special", that is still useful.

Here's why:
- as a general rule, "special" is negotiated between parties (two, or
more-than-two, doesn't matter)
- it is fine to have "customer" include "customer's customer et al",
and even "customer's special neighbor" iff the customer wants
- except when all the parties are part of a single "special"
arrangements, "special" is non-transitive.
- there can be many pools of "special", even with overlapping membership
- pretty much by definition, "special" pools are contiguous
- outside of that contiguous area, the boundary to that special area
can be treated as a normal AS (by non-participants)
- in fact, special pools could almost be treated like an AS Confederation

The last two points basically say, if we ignore the goings-on within
such a region, applying the simple rules (customer/transit/peer) are
sufficient to prevent leaks crossing any boundary other than between
region members.

Take as a whole, this is more than sufficient benefit to employ, so
long as it is possible for members of such regions to "remove the
safeties".

The exposure is strictly intra-region at that point, which is a lot
better than it is today.

Mechanisms for preventing route leaks don't have to necessarily be
perfect to be useful, IMHO.

Keeping the mechanics themselves simple, and the semantics clear, is
the second most important part. Sensible defaults is the most
important. Third is allowing network admins to disable them as needed.
Kind of analogous to the three laws of robotics, now that I think about it...

Brian

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Nov 2011 13:33:50 -0500

>intent and allow others to filter based on intent.

Geoff,

I have been told that the lack of widely available, reliable IRR data 
out side of the RIPE region is due, in part, to a reluctance by 
operators to publish all of these details.  If that is true, then it 
argues against assuming the existence of such data on a global basis.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 10 Nov 2011 06:56:12 +1100

> argues against assuming the existence of such data on a global basis.

I did not claim it existed - I merely disagreed with the claim of its 
impossibility of existence.

In the same way that the only way you can eliminate the "unknown" validation
outcome is to achieve universal adoption of the generation of credentials,
the general visibility of intent relies on universal adoption on the generation
of routing policy. It is not impossible per se, it just relies on universal adoption!

In the case of the efforts relating to RPSL, reality has not achieved such targets
of universal adoption, as you point out.

In the case of the efforts relating to the BGP security mechanisms you are working
on, it is an open issue as to how many folk would adopt it, but our experiences
of other technologies, including 4 byte ASN support indicate that universal
adoption is an extremely challenging objective.

Geoff

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Nov 2011 15:18:19 -0500

>impossibility of existence.

OK.

>of routing policy. It is not impossible per se, it just relies on 

agreed.

>of universal adoption, as you point out.

OK.

>adoption is an extremely challenging objective.

no argument.

Thanks for the thoughtful, detailed reply.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Wed, 9 Nov 2011 21:56:18 -0500

> adoption is an extremely challenging objective.

I completely agree with you here Geoff - and a resource certification 
infrastructure to bootstrap IRRs, coupled with a few lessons learned 
from the RIPE playbook and beyond, and their potential utility is orders 
of magnitude beyond where it currently is and addresses that residual 
risk (my primary concern) that current solutions fail to address.

-danny