Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-02.txt

From: [email-masked]
Date: Fri, 09 Mar 2012 23:11:40 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

	Title           : Security Requirements for BGP Path Validation
	Author(s)       : Steven M. Bellovin
                          Randy Bush
                          David Ward
	Filename        : draft-ietf-sidr-bgpsec-reqs-02.txt
	Pages           : 9
	Date            : 2012-03-09

   This document describes requirements for a future 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-02.txt

---

From: Eric Osterweil <[email-masked]>
Date: Sat, 10 Mar 2012 14:37:04 -0500

I just noticed that none of the comments I made in 11/11:
	http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html
seem to be addressed in this revision.

Eric

On Mar 10, 2012, at 2:11 AM, [email-masked] wrote:

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

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Mar 2012 07:33:58 +0900

> seem to be addressed in this revision.

mea culpa.  but that's why i published early.  lemme review now.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Mar 2012 08:07:09 +0900

> seem to be addressed in this revision.

great review.  and again my apologies for having missed it.  i now have
an internal ticket system so i hope to lose less.

i have hacked as per following, and will push -03 to repository.  this
will leave two days for further discussion and another version before
the dreadline.

> - 3.5 is not a testable requirement.  One cannot be expected to enumerate the space of all things that are _not_ requirements, so why put any in?
> - 3.6 ibid

because these two serve as warnings, to which people might even object.

though 3.6, can not fix data-plane, seems obvious to me, to others it
might not be.

> - 3.7 is too vague.  Need to specify where an adversary needs to have access to link-layer.  I have access to the link layer at home, but that doesn't help me insert traffic between any BGP peers. Can I suggest modifying the existing text as follows:
>   ``... an enemy who has access to the inter-router link layer...''  the term ``inter-router link'' is borrowed from the cited RFC.

thanks

> - 3.8 The word ``MAY'' is a very rough fit for the general notion of ``requirements.''  I would suggest it is reworded:
>   ``A BGPsec design MUST be able to understand and make use of a security infrastructure (e.g., a PKI) to distribute authenticated data used as input to
>          routing decisions when such a resource is available and operators wish to configure it for use.  Such data includes information about
>          holdings of address space and ASNs, and assertions about binding of address space to ASNs.''

hmm, you are suggesting

OLD:
   3.8   A BGPsec design MAY make use of a security infrastructure
         (e.g., a PKI) to distribute authenticated data used as input to
         routing decisions.  Such data include information about
         holdings of address space and ASNs, and assertions about
         binding of address space to ASNs.

NEW:
   3.8   A BGPsec design MUST be able to understand and make use of a
         security infrastructure (e.g., a PKI) to distribute
         authenticated data used as input to routing decisions when such
         a resource is available and operators wish to configure it for
         use.  Such data includes information about holdings of address
         space and ASNs, and assertions about binding of address space
         to ASNs.

i think you are just moving the point of equivocation.  our wording was
meant to leave open the idea that there might be other means than a PKI.
yours seems to leave open the operator's ability to enable or not.  for
me, the operator's freedom to decide was assumed.

otoh, the OLD wording could indeed be improved.  how about

   3.8   It is assumed that a BGPsec design will require information
         about holdings of address space and ASNs, and assertions about
         binding of address space to ASNs.  A BGPsec design MAY make use
         of a security infrastructure (e.g., a PKI) to distribute such
         authenticated data.

i think that catches our intent.  i am less sure it catches yours.

> - 3.9 is also not worded as a requirement.  Does the solution require that a 4k packet even be discussed?  It seems to me that this is not the right document to discuss this.

fair point.  i'll leave a marker in the next version so as not to change
numbering so folk can follow the discussion.

> - 3.10 also does not seem to be a requirement.  It is ``requiring'' an optional exclusion?  I suggest it get yanked.

making explicit that the design need not cover an existing feature fo
BGP, AS-SET, seems important

> - 3.11 This also does not seem to be a requirement.  Discussing a design's status in a requirements document is backwards.  I suggest this get yanked.

making explicit that a design need not maintain the update packing
feature of current bgp would seem important.

> - 3.19 Seems like it would be hard to test as a requirement.  The problem may be the word ``MAY.''  How could this be made into a testable requirement?

i am not sure testability is the issue.  if one can look inside the
router, that the database is kept current would seem to be testable.
if the router is a black box, not.

if you are suggesting that the MAY should be a MUST, i agree and will
make that change.

> - 3.20 This requirement, again, references a baked design.  This should be restated in a general way.  Suggest,
>   ``Any inter-AS use of cryptographic hashes or signatures, should (must?) provide mechanisms for algorithm agility that take the form of...''

how about

   3.20  Any inter-AS use of cryptographic hashes or signatures, MUST
         provide mechanisms for algorithm agility.

> - 4.5 The term ``real-time'' seems to carry too many implicit/overloaded meanings.  Could we try to disambiguate with different text.  Maybe we can just drop that term ``real-time'' and leave the rest?

sure

> - 4.7 This requirement seems to preach a little bit of a design instead of being agnostic.  Could it be rephrased to be something like:
>   ``The output of a router applying BGPsec to a received signed UPDATE MUST be either unequivocal and conform to a fully specified state in the design.''

sure.

deep thanks for the thoughtful review, and apologies for having lost it.

randy

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 20 Mar 2012 13:26:24 -0400

Hey Randy,

Sorry for the delay.  I know we're passed the deadline (totally my bad, sorry), but here are my comments:

> though 3.6, can not fix data-plane, seems obvious to me, to others it

I totally understand the sentiment behind these items, but in a pedantic sense, they aren't requirements.  Could there be another section for something like ``considerations?''  If I build a toaster, I fulfill the above ``reqs,'' right? 

> i think that catches our intent.  i am less sure it catches yours.

While I may be being pedantic again (it's the software engineer in me, sorry), I think a requirement should prescribe something that is necessary for a system in order for its design to be judged as being correct.  The optional nature of ``MAY'' seems counter to this.  If we start from the question, ``why does a BGPsec design need 3.8'' we should be able to construct the necessary requirement.  Maybe something like:

	3.8 A BGPsec design must be able to ``verify'' the correctness of the holdings of address space, the holdings of ASNs, and the binding between address space and ASNs.

Then, the notion of how verification can be done can be externalized to this document in the afore mentioned ``considerations'' section.  Maybe something like:
	``Verification'' can be defined in many ways, including [cite rpki]...

THis is very hand wavy, and I know it's pedantic, but requirements analysis is the foundation of a system's design, so I've always been kind of hung up on it. :)

> BGP, AS-SET, seems important

Is that fundamental to securing BGP, or more of a system design issue?  If the latter, I would suggest it get addressed there.  I had thought that ensuring the proper semantics of origin validation and path validation didn't inherently care about AS-SETs?  I do understand that many want to address this, I just felt it ought to be elsewhere to maintain the focus on requirements analysis.  A design doc can always make the same statements that carry just as much weight...

> feature of current bgp would seem important.

But requirements come before a design, so it's like putting the cart before the horse.  Requirements, to really properly do their job, need to be design-agnostic.

> if you are suggesting that the MAY should be a MUST, i agree and will

I have to say, it makes much more sense (to me) w/ that change. :)

>         provide mechanisms for algorithm agility.

I like this much better, but can we just think about adding something that explains (very quickly) what the point is?  Maybe something like:
	s/algorithm agility./algorithm agility, so that specific hashes or sigs can be changed without degrading the global system's security protections./

Or something?

> deep thanks for the thoughtful review, and apologies for having lost it.

My pleasure, and no worries (we all get busy). :)

Eric