Subject: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

From: Chris Morrow <[email-masked]>
Date: Fri, 10 Jan 2014 20:38:52 -0500

Working Group Folken,
Today starts a WGLC for the subject draft:
  <http://trac.tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs>

Abstract:
   This document describes requirements for a BGP security protocol
   design to provide cryptographic assurance that the origin AS had the
   right to announce the prefix and to provide assurance of the AS Path
   of the announcement.

Please have a read-through and send comments at the authors +
[email-masked] mailing list.

This WGLC completes in 1,209,600 seconds, or 20,160 minutes.

Thanks!

-chris
co-chair

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 14 Jan 2014 23:38:20 +0000

I support publication of this document as an RFC.
I have some comments listed below that are meant to help improve clarity.

3.2 (current) A BGPsec design must allow the receiver of a BGP announcement  to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of eBGP exchanges that propagated the prefix from the origin AS to the receiver, particularly if an AS has added or deleted any AS number other than its own in the path attribute.  This includes  modification to the number of AS prepends.

3.2 (suggested rewording) A BGPsec design must allow the receiver of a BGP announcement  to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of eBGP exchanges that propagated the prefix from the origin AS to the receiver. Specifically, if an AS has deleted any ASN from the AS PATH it received or added an ASN other than its own then the verification of the update (if propagated) MUST fail at its neighboring  BGPsec routers.  This includes modification to the number of AS prepends, i.e. an AS in the path MUST NOT be able to modify the AS prepends (if any) of preceding ASs in the AS PATH.

3.4 (current) A BGPsec design MUST be amenable to incremental deployment. This implies that incompatible protocol capabilities MUST be negotiated.  

"Negotiating incompatible protocol" -- the phrase doesn't sound right to me.

3.4 (suggested rewording) A BGPsec design MUST be amenable to incremental deployment. This implies that a BGPsec capable router MUST be backward compatible and MUST negotiate BGP-4 protocol with a BGP-4 only neighbor,  and MUST interoperate with the BGP-4 only neighbor.
  
3.4 and 3.13 are related (overlapping). You may consider combining them.

In 3.14, this statement "Such mechanisms  SHOULD conform with [I-D.ietf-sidr-ltamgmt]" seems a bit abrupt. You should state what in [I-D.ietf-sidr-ltamgmt] is relevant here to "best path and other routing decisions."  Note: You do speak about [I-D.ietf-sidr-ltamgmt] more specifically again in 3.17.

Sriram

---

From: Warren Kumari <[email-masked]>
Date: Sun, 19 Jan 2014 13:49:00 -0500

> I support publication of this document as an RFC.

As do I.
W

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

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 21 Jan 2014 17:57:39 +0000

I support publication of this document as RFC.

Regards,
Keyur

---

From: Demian Rosenkranz <[email-masked]>
Date: Thu, 23 Jan 2014 13:46:18 +0100

Hi,

I'm thinking about another potential DoS attack. An entity which owns a 
CA certificate has the possibility to generate a huge hierarchy of 
further CA certificates without any limitation (as far as I know).

In contrast to the generation of a huge amount of ROAs, this attack 
isn't limited regarding the number of objects/certificates.

I.e. a compromised/bad entity owns a /16 prefix and generates 10000 CA 
certificates and hand down this prefix until the lowest CA certificate 
and generates 2^8 ROAs, a relying party software would be forced to 
check this hierarchy 2^8 times.
Of course, this is kind of a blunt attack but without making any 
provisions, this "local cache flooding" could lead to a disturbance of 
all (worst case) local caches for a certain time. Some smaller RP could 
be slower in remedying this.

Are there any restriction to this attack I've missed? Any feedback is 
very welcome!

Kind regards

Demian

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 23 Jan 2014 14:38:19 +0100

Hi Demian,

On Jan 23, 2014, at 1:46 PM, Demian Rosenkranz <[email-masked]> wrote:

> Hi,
> 
> I'm thinking about another potential DoS attack. An entity which owns a CA certificate has the possibility to generate a huge hierarchy of further CA certificates without any limitation (as far as I know).
> 

As far as I remember there are no formal restrictions regarding either the number of child CA certificates issued by a CA, or the length of the chain.  

> In contrast to the generation of a huge amount of ROAs, this attack isn't limited regarding the number of objects/certificates.
> 
> I.e. a compromised/bad entity owns a /16 prefix and generates 10000 CA certificates and hand down this prefix until the lowest CA certificate and generates 2^8 ROAs, a relying party software would be forced to check this hierarchy 2^8 times.

Some say that the same resource 'should' not appear on multiple child CA certificates, however in practice this can happen in case of a child key roll, and a make-before-break resource transfer. There is no notification about the reason, so RPs have a hard time guessing. In short: our RP doesn't care about resources appearing on multiple child CA certs. If the certificates are valid, the duplicate resource is valid for both branches.. if the parent disagrees, they should revoke / re-issue as needed.

That said, if one wants avoid duplicating resources in an attack like this there is always IPv6.. And then it's of course possible that it wasn't intended as an attack at all, but some over zealous CA goes granular way beyond present day BGP --- eg. giving ghostbusters to all their v6 end users ;)

> Of course, this is kind of a blunt attack but without making any provisions, this "local cache flooding" could lead to a disturbance of all (worst case) local caches for a certain time. Some smaller RP could be slower in remedying this.

While I don't think we have formal restrictions, I can imagine certain mitigations if this would become a serious threat:
= Parent of the offending CA could revoke the certificate (if abuse is defined in terms of use, talking doesn't help, etc.., reactive by nature though)

= RPs could limit the maximum length of the cert chain, or even number of CA certs issued by CA certs they are willing to accept
      - e.g. pro-actively quarantine 'spam-CAs' like this, and allow the end-user to override
      - or re-actively.. proceed, but warn and allow user to disregard
      - or a mix of both of course with some thresholds, prob. allowing the RIRs to issue a bit more 
= RPs should probably employ strategies to ensure that a lot of work in one part of the tree does not block validation of the remaining tree (if resources don't overlap).

> Are there any restriction to this attack I've missed? Any feedback is very welcome!

I would say that been though it's entirely possible to attack the rpki by producing many objects, it's not feasible to do this *covertly*. This will get get you noticed, quickly.

So while I see the value of thinking about these scenarios and possible ways to mitigate them - thank you :) - I am not convinced that we should go overboard in terms of best practices for RPs, or general restrictions for CAs, at this time. I would consider possible *covert* attack vectors on the rpki infrastructure to be much more serious though.

Cheers
Tim

---

From: Jared Mauch <[email-masked]>
Date: Thu, 23 Jan 2014 08:38:58 -0500

> Are there any restriction to this attack I've missed? Any feedback is very welcome!

We certainly see this scale of prefix registration within the IRR dataset.  (Folks registering each variant of the entire covering prefix of a /16 for example).

I imagine the same would be done with the same rationale by someone well intentioned.

- Jared

---

From: "George, Wes" <[email-masked]>
Date: Fri, 24 Jan 2014 09:56:44 -0500

I’ve reviewed, it’s mostly ready, minor comments:

I’m not happy with this text in the intro: “issues of business
   relationship conformance, of which routing 'leaks' are a subset,
   while quite important to operators (as are many other things), are
   not security issues per se, and are outside the scope of this
   document.”

Let me be clear up front, my issue is *not* that these are declared out of
scope, since my comments on the threats document seemed to be interpreted
otherwise.

My issue with this text is the reason it provides as to why they’re
considered out of scope. I don’t think that it’s entirely accurate to
assert that route leaks are not security issues. While not all route leaks
are security issues, some are. It would be more accurate to reflect the
discussion that led us to the conclusion that we can’t secure them because
we don’t know what “them” is yet, and are awaiting GROW to define them in
such a way so that we can evaluate if it’s even possible to secure them in
this framework. That may be a longer discussion that doesn’t belong in the
intro, I don’t know.

Also I think the parenthetical “as are many other things" is unnecessary
and clunky.

Thanks,

Wes

>This WGLC completes in 1,209,600 seconds, or 20,160 minutes.

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: Warren Kumari <[email-masked]>
Date: Fri, 24 Jan 2014 10:04:29 -0500

>    not security issues per se, and are outside the scope of this

Would simply:
"issues of business relationship conformance (of which routing 'leaks'
are a subset), while important to operators, are outside the scope of
this document.”

cover things well enough?

> this framework. That may be a longer discussion that doesn’t belong in the

I suspect it is. It somewhat seems like a non-terminating discussion....

W

---

From: "George, Wes" <[email-masked]>
Date: Fri, 24 Jan 2014 11:15:41 -0500

>cover things well enough?

It would at least address the concern about declaring them not to be
security concerns, and is enough for the intro, IMO

>I suspect it is. It somewhat seems like a non-terminating discussion....

I think it might be appropriate to add a new req in the form of req 3.3 to
explain why this is out of scope, or bolster 3.22 to expand on intent as
it relates to this, perhaps with some reference to the fact that route
leaks are currently not well-enough defined to consistently (and more
importantly, systematically) identify them and secure the right BGP
attributes to help prevent them

Thanks
Wes

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Jan 2014 17:33:34 +0900

> are security issues, some are.

hence the "per se," meaining in and of itself.  some cases of pouring
cement into a router (see london tube) are security issues, some are
not.

how would you make that more clear?

> It would be more accurate to reflect the discussion that led us to the
> conclusion that we can’t secure them because we don’t know what “them”
> is yet

i don't think that is entirely true.  they are announcements of P by A
to B which are not agreed by all parties concerned (including A, B,
neighbors of A and B, the originator of P, ...).  the problem lies in
detecting them, especially from a distance.

> and are awaiting GROW to define them in such a way so that we can
> evaluate if it’s even possible to secure them in this framework.  That
> may be a longer discussion that doesn’t belong in the intro, I don’t
> know.

i agree.  and i doubt we want "waiting for grow" in a document which is
not ephemeral.

> Also I think the parenthetical “as are many other things" is
> unnecessary and clunky.

easily nuked.

randy

---

From: "George, Wes" <[email-masked]>
Date: Mon, 27 Jan 2014 10:47:57 -0500

>how would you make that more clear?
I think Warren’s suggestion of simply eliminating the assertion about
whether it’s a security issue, per se or otherwise, and just saying that
it’s out of scope is enough for the intro.

> they are announcements of P by A
So I think that goes back to my suggestion that since you already discuss
intent in 3.22, that might be a place to add something about leaks, either
as a part of that req or a follow-on, because that’s really what you’re
saying here - we understand theoretically what they are, but not how to
detect them such that we could do anything to prevent the undesired ones.

Wes

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 Jan 2014 01:06:36 +0900

> whether it’s a security issue, per se or otherwise, and just saying
> that it’s out of scope is enough for the intro.

i disagree.  would be interested in hearing other opinions.

>> they are announcements of P by A to B which are not agreed by all
>> parties concerned (including A, B, neighbors of A and B, the
>> originator of P, ...).  the problem lies in detecting them,
>> especially from a distance.
> So I think that goes back to my suggestion that since you already
> discuss intent in 3.22, that might be a place to add something about
> leaks, either as a part of that req or a follow-on, because that’s
> really what you’re saying here - we understand theoretically what they
> are, but not how to detect them such that we could do anything to
> prevent the undesired ones.

leave that to grow/idr.  this is routing security.

randy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Jan 2014 11:24:00 -0500

Randy,
> i disagree.  would be interested in hearing other opinions.
If just saying that it's out of scope allows  us to move forward with 
this doc,
that works for me.

Steve