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

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Nov 2011 11:04:53 -0400

At 10:03 PM -0400 10/28/11, Danny McPherson wrote:
>On Oct 28, 2011, at 2:40 PM, Christopher Morrow wrote:
>
>>  Seems that the authors, at least, expect this doc to be prepared for
>>  WGLC, could we do that concluding 11/11/11 please?
>
>
>I've got a couple of comments.
>
>Some high-level bits captured with specific comments below
>include:

This isn't my doc, but I will reply to a few of your points, since 
I've been replying to your comments on the threat model :-).

>2) from a mechanics and processing perspective, this appears to
>largely focus only on external BGP.  It would be useful if the
>requirements considered what behaviors and recommendations are
>applicable to internal BGP speakers as well.

The focus of BGPSEC is eBGP, because the concern is verifying the
authenticity of routes arriving from other ASes. The hard problems arise
for eBGP because these routes are delivered via BGP speakers in different
"trust domains."  iBGP integrity and authenticity can be achieved via 
internal security procedures and thus is not a focus of BGPSEC.

>2) This document seems to allude to a solution that only protects
>NLRI and AS_PATH, and ignores ORIGIN and other attributes.  This
>concerns me a great deal given that most (all?) path selection
>today is largely based on policy derived from and applied based
>upon all those other attributes.

I replied to the ORIGIN attribute question in my other message.

NLRI and AS_PATH are the attributes being protected both because they 
represent the fundamental routing data elements, and because they are 
attested to in the RPKI. Using the RPKI we can determine whether the 
origin AS is authorized to originate a route for the NLRI. We can 
verify whether a BGP speaker representing each AS in the AS_PATH is 
the entity that signed the data carried as part of an Update. We 
don't have analogous, authoritative data about MPLS, for example, so 
we can't provide the same sort of security guarantees. If the 
community identifies data carried in Updates that it believes should 
be protected, and
we can agree on security semantics that are enforceable relative to 
the BGPSEC architecture, then we could expand protection, perhaps in 
a v2 of the protocol.

>3) as a WG we need to agree on what constitutes a reasonable
>solution for minimizing an exposure window.  If we're going
>to build such a heavy solution I find it hard to justify new
>hardware and tons of complexity if we can't get the window to
>seconds or minutes, rather than 8+ hours or more best case with
>what we've seen proposed to date, and that's with periodic
>updates (ala beacons) that have the scaling properties of RIP.

Beacon frequency affects how responsive BGPSEC is relative to one set 
of attacks. A more accurate statement is that the beacon parameters 
that the BGPSEC design is likely to use will induce significant 
latency detecting those attacks. Reducing the latency  would require 
more frequent beaconing, and that is viewed as an unacceptable 
tradeoff, at lest for now. The residual vulnerability due to beacon 
latency relates to the ability of an AS that was authorized to 
advertise a route, to replay the advertisement, even when it is not 
currently authorized to do so. This vulnerability should be viewed in 
the context of the inability of a BGP speaker to know whether a 
neighbor has failed to withdraw a route, when it has no paths for the 
prefix in question. An AS cannot, in general, know whether the only 
route for a given prefix has been withdrawn at some point upstream. 
This the BGP design and operational model embodies this vulnerability.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Wed, 2 Nov 2011 21:32:36 -0400

On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote:
> "trust domains."  iBGP integrity and authenticity can be achieved via internal security procedures and thus is not a focus of BGPSEC.

But given that these attributes and the threat model include internal BGP 
speakers and the largest scale issues (e.g., route reflectors with 5 millions 
paths _today), we can't simply expect that it's out of scope.

> NLRI and AS_PATH are the attributes being protected both because they represent the fundamental routing data elements, and because they are attested to in the RPKI. Using the RPKI we can determine whether the origin AS is authorized to originate a route for the NLRI. We can verify whether a BGP speaker representing each AS in the AS_PATH is the entity that signed the data carried as part of an Update. We don't have analogous, authoritative data about MPLS, for example, so we can't provide the same sort of security guarantees. If the community identifies data carried in Updates that it believes should be protected, and
> we can agree on security semantics that are enforceable relative to the BGPSEC architecture, then we could expand protection, perhaps in a v2 of the protocol.

But if we add considerable overhead (orders of magnitude from where we
are today) to deploy BGPSEC and only focus on a subset of the Path 
Attribute (i.e., AS_PATH  only) integrity functions then the ORIGIN code 
Path Attribute (and also many others) can still be manipulated to change 
BGP decision algorithms and induce traffic attraction attacks, then perhaps
we need to challenge the assumptions that led to scoping a solution to 
AS_PATH and NLRI in the first place, as I really haven't seen a consensus 
call on this in the WG either?

I think I constitute a participant in "the community" here -- or are we all 
expected to accept this large set of documents and assumptions as gospel  
and use the SIDR WG as a publication house for work done outside of the 
IETF?  I'd be less uncomfortable if the aim was to publish this set of 
documents as Experimental until they generate some critical deployment 
mass, and the broader community refines based upon operational experience 
until then, which is something that I'm becoming more amenable to, but to 
dictate as "the solution" for secure routing with some many outstanding issues
concerns me.

> Beacon frequency affects how responsive BGPSEC is relative to one set of attacks. A more accurate statement is that the beacon parameters that the BGPSEC design is likely to use will induce significant latency detecting those attacks. Reducing the latency  would require more frequent beaconing, and that is viewed as an unacceptable tradeoff, at lest for now. The residual vulnerability due to beacon latency relates to the ability of an AS that was authorized to advertise a route, to replay the advertisement, even when it is not currently authorized to do so. This vulnerability should be viewed in the context of the inability of a BGP speaker to know whether a neighbor has failed to withdraw a route, when it has no paths for the prefix in question. An AS cannot, in general, know whether the only route for a given prefix has been withdrawn at some point upstream. This the BGP design and operational model embodies this vulnerability.

And to challenges assumptions, why is beaconing or the current mechanisms 
proposed in BGPSEC the right approach -- surely it's something more than "because
we bolted a PKI on to a distributed protocol and this is how it's got to work?    If that's
the case, this becomes a prime example of precisely why we don't want to bolt 
security on after the fact, particularly in the case of distributed systems and protocols, 
and if we're working on 8-10 year out solutions, I'd like to think we can do better than 
this.

More specifically, if I have perform a cost/benefit analysis it's not at all clear to me 
that tightening exposure windows to the frequency (hours/days) you're suggesting 
is worth the investment and fundamental shift from the stateful BGP model we know 
today, particularly given the drive-by and targeted nature we see in all other aspects 
of security today (e.g., APT, phishing, etc..).  

-danny

---

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

At 9:32 PM -0400 11/2/11, Danny McPherson wrote:
>>  "trust domains."  iBGP integrity and authenticity can be achieved 
>>via internal security procedures and thus is not a focus of BGPSEC.
>

I think we can, because of the SIDR charter. The focus is on 
authenticity for inter-AS paths, not intra-AS paths. Any attacks 
against iBGP would appear, externally, to be equivalent to internal 
config errors or other forms of internal attacks. But, if you wish, I 
can add a sentence or two to state that explicitly.

>>  NLRI and AS_PATH are the attributes being protected both because 
>>they represent the fundamental routing data elements, and because 
>>they are attested to in the RPKI. Using the RPKI we can determine 
>>whether the origin AS is authorized to originate a route for the 
>>NLRI. We can verify whether a BGP speaker representing each AS in 
>>the AS_PATH is the entity that signed the data carried as part of 
>>an Update. We don't have analogous, authoritative data about MPLS, 
>>for example, so we can't provide the same sort of security 
>>guarantees. If the community identifies data carried in Updates 
>>that it believes should be protected, and
>>  we can agree on security semantics that are enforceable relative 
>>to the BGPSEC architecture, then we could expand protection, 
>>perhaps in a v2 of the protocol.
>

The WG charter established this scope.

>dictate as "the solution" for secure routing with some many outstanding issues

see comment above.

>  > Beacon frequency affects how responsive BGPSEC is relative to one 
>set of attacks. A more accurate statement is that the beacon 
>parameters that the BGPSEC design is likely to use will induce 
>significant latency detecting those attacks. Reducing the latency 
>would require more frequent beaconing, and that is viewed as an 
>unacceptable tradeoff, at lest for now. The residual vulnerability 
>due to beacon latency relates to the ability of an AS that was 
>authorized to advertise a route, to replay the advertisement, even 
>when it is not currently authorized to do so. This vulnerability 
>should be viewed in the context of the inability of a BGP speaker to 
>know whether a neighbor has failed to withdraw a route, when it has 
>no paths for the prefix in question. An AS cannot, in general, know 
>whether the only route for a given prefix has been withdrawn at some 
>point upstream. This the BGP design and operational model embodies 
>this vulnerability.
>

I agree that adding security after the fact is never the preferred 
approach. But we often are forced to do that in the IETF because we 
have very widely deployed protocols. The IESG chartered this WG with 
a specific scope. We are adding onto BGP, not starting from scratch. 
You're certainly welcome to propose how to do this better, consistent 
with the SIDR charter.

>of security today (e.g., APT, phishing, etc..).

I presume that your statement "fundamental shift from the stateful 
BGP model..." refers to beaconing. Beaconing does create a new basis 
for propagating a route, but an AS could cause the same impact on the 
routing system by changing other route parameters at the same 
frequency, consistent with the BGP spec. I'd prefer a better 
solution, but I don't have one to offer at this time.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Fri, 4 Nov 2011 11:57:02 -0400

>> On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote:

<snip>

> I presume that your statement "fundamental shift from the stateful BGP model..." refers to beaconing. Beaconing does create a new basis for propagating a route, but an AS could cause the same impact on the routing system by changing other route parameters at the same frequency, consistent with the BGP spec. I'd prefer a better solution, but I don't have one to offer at this time.

ooc, in regards to the above: is there any detailed analysis of how much extra overhead we can expect from these beacons if BGPSec were deployed universally today?  Specifically, the comment above, "an AS could cause the same impact on the routing system by changing other route parameters at the same frequency" seems to miss the point I think I see in the objection: what if _every_ AS must do this all the time (not just a rogue, or select few).  How much extra overhead would ensue if (say) someone took the current set of all ASes and prefixes and simulated the extra update traffic needed in (say) a day?  Maybe if we saw some numbers that told us how many additional updates and how much additional bandwidth this approach would require in a routing system like today's we could understand another aspect of much of a shift we are talking about?

Eric

---

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

> ooc, in regards to the above: is there any detailed analysis of how much extra overhead we can expect from these beacons if BGPSec were deployed universally today?  Specifically, the comment above,…

my recollection is we ran some of these numbers (based, I think, on
routeviews dump/mrt data), perhaps randy or stephen has this sort of
number available?

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 8 Nov 2011 07:59:19 -0500

> ooc, in regards to the above: is there any detailed analysis of how much extra overhead we can expect from these beacons if BGPSec were deployed universally today?  Specifically, the comment above,…

Eric,

According to 
http://bgpupdates.potaroo.net/instability/bgpupd.html 
the current global BGP system produces
Average Prefixes per BGP Update: 	2.24
Average BGP Update Messages per second: 	1.13 	
Average Prefix Updates per second: 	2.53
>From this we can compute:
Average Prefix Updates per day = 	218696

Now if we consider a BGPSEC island of 100,000 participating prefixes
(multiple ISPs form a BGPSEC island and there is BGPSEC between
them and also in each ISP's entire customer cone):
With 24 hour beaconing interval, we would have:
Prefix Updates per Day = 100,000 (seen at each BGPSEC router)
BGPSEC Update Size = 420B (for ECDSA-256)
Average Bandwidth Required = 3.89 kbps (averaged over a day) 

Does this answer what you were asking for?

Sriram 

_______________________________________________

---

From: Russ White <[email-masked]>
Date: Tue, 08 Nov 2011 09:27:27 -0500

> Prefix Updates per Day = 100,000 (seen at each BGPSEC router)

It's one additional update per table entry per day, assuming a 24 hour 
beacon. If the table is 300,000 routes, it's 300,000 additional updates 
a day --on top of normal churn.

The 24 hour "beacon rate," is a bad assumption anyway --once operators 
catch on to this being the actual amount of time you're willing to allow 
others to hijack your routes, the rate will shorten up considerably. 
There's no "downward limit" on the time, and there's no real economic 
incentive for the originator to choose longer times.

At some point you're going to be forced to put in timers per AS Path hop 
--since the signature in the packet represents the policy and 
connectivity between every pairwise set in the AS Path, every pairwise 
set also needs a timer.

Added together, we are talking at least a doubling of the rate at which 
updates are received (and probably more like a tripling or quadrupling 
over time), at least a quadrupling of the total traffic in terms of 
bits/second (assuming the lowest possible update rates)--and all of this 
counts the cost of actually handling the crypto inbound and outbound as 
zero.

Russ

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Nov 2011 15:42:39 +0100

> beacon. If the table is 300,000 routes, it's 300,000 additional
> updates a day --on top of normal churn.

note that this is not churn, in the sense of fib update, which is 90% of
the cost of an update.

> At some point you're going to be forced to put in timers per AS Path

nope.  gains absolute zero replay protection.  see my preso from VdeQ.

but i am not really interested in the noise about beaconing.  as i said
in VdeQ, the feature is nice but not all that important.

randy

---

From: Russ White <[email-masked]>
Date: Tue, 08 Nov 2011 09:57:39 -0500

> nope.  gains absolute zero replay protection.  see my preso from VdeQ.

I fail to see how this is possible. Please send a pointer.

> in VdeQ, the feature is nice but not all that important.

You're saying replay protection isn't important?

Russ

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Nov 2011 16:13:23 +0100

> I fail to see how this is possible. Please send a pointer.

from slide 10

A originates the announcement
If everyone beacons, assume the beacon TTL applies only to that hop  
B gets it from A, C gets it from B, D gets it from C
D can keep sending the announcement, even though C’s TTL expired.  Oops!

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Nov 2011 16:14:51 +0100

and, slide 11

So try believing minimum TTL in chain
But are all redundant to the first, since if that one expires none of the others should even be sent
An intermediate might want a lower one, in case its downstream link goes down, but why?
The downstream neighbor will announce a different path, but to those further still downstream that is indistinguishable from many other causes of seeing a different path from your upstream
And there's no real reason for an intermediate node to want to beacon because it has no skin in the game

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 8 Nov 2011 12:08:58 -0500

Proposal was 24 hour beacon timeout and 3 beacons per timeout. That makes 3 beacons per day.

--
Jakob Heitz.

On Nov 8, 2011, at 5:00 AM, "Sriram, Kotikalapudi" <[email-masked]> wrote:

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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 8 Nov 2011 12:19:15 -0500

Now the ops doc has much longer beaconing interval recommendations
for what you may consider a normal prefix.

http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7

	Normal Prefix:  Most prefixes SHOULD announce with a signature
	validity of a week and beacon every three days.

Sriram

-----Original Message-----
From: Jakob Heitz [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2011 12:09 PM
To: Sriram, Kotikalapudi
Cc: Christopher Morrow; Eric Osterweil; sidr wg list
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

--
Jakob Heitz.

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 9 Nov 2011 15:37:01 -0500

Hey Sriram, Russ, and Jakob,

Thanks for the #s.  I think I get the general notion that adding n updates per day per prefix equals (n * #prefixes)/1. :)  I guess my question was kinda vague, sorry.  Upon reexamination, I see that I said "overhead" without being specific.  Since we can use the updates that are generated today to measure how much (for example) bandwidth is already needed, can we calculate how much extra bandwidth universal deployment would mean?  Also, perhaps this would be most informative in the form of a ratio (i.e. a factor of $x$ increase).  That way, when people look at events like the one that the "General Internet Instability" thread that just happened on NANOG refer to, they can gauge the update amplification that was seen against what _would_ be seen given bgpsec.  I think this actually kind of came up on nanog, so it seems like maybe it would be a relevant thing to look at here?

Anyway, I guess I was mostly just curious about what kinds of evaluations have been done, thanks. :)

Eric

---

From: Danny McPherson <[email-masked]>
Date: Wed, 9 Nov 2011 22:24:00 -0500

> http://bgpupdates.potaroo.net/instability/bgpupd.html 

Sriram, 
To quote from the page you reference:

"The data has been gathered using a single eBGP peering with AS 131072."

We've got over 450 peers with multiple interconnects in 70+ locations, with 
many prefixes asserting reachability from multiple eBGP paths, and *millions* 
of eBGP-learned paths on many routers today -- and we're not even an ISP.

Unless I'm missing something, I think this has some material impact on your 
numbers...

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 9 Nov 2011 22:25:28 -0500

> 	validity of a week and beacon every three days.

Seriously?  After all this effort exposure window of 72 hours or more now
- I can do far better than this manually in meatspace.

Where are these numbers coming from?

It's interesting the onus is on the sender to set the periodic update rates, 
yet the load is on every other participant in the system.  We've seen how
well this works in practice.

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 10 Nov 2011 13:41:34 -0500

> Thanks for the #s.  I think I get the general notion that adding n updates per day per prefix equals (n * #prefixes)/1. :)  I guess my question was kinda vague, sorry.  Upon reexamination, I see th…

is the 'bandwidth' of the bgp protocol in the wire an actual concern?
(at some point the discussion point came up ~1yr or more ago, but was
discarded as not relevant given circuit sizes and bandwidth from link
-> RP/RE/etc, so I'm genuinely curious about this)

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 10 Nov 2011 13:46:26 -0500

> -> RP/RE/etc, so I'm genuinely curious about this)

I think it is just a concrete way to relate the amount of data being consumed today, to what may be needed tomorrow.  It isn't so much that 1 byte = good and 10 bytes = bad.  More that in trying to quantitative compare two behaviors, finding a common reference point seems like a good start, imho.  I think a meaningful ratio is more useful, but it just needs something to compare.

Eric

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 10 Nov 2011 13:54:23 -0500

Don't forget, BGPSEC sends one prefix per update.
Current traffic is 2 to 3 prefixes per update.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eric Osterweil
> Sent: Thursday, November 10, 2011 10:46 AM
> To: Christopher Morrow
> Cc: Sriram, Kotikalapudi; sidr wg list
> >> Thanks for the #s.  I think I get the general notion that adding
> n updates per day per prefix equals (n * #prefixes)/1. :)  I guess
> my question was kinda vague, sorry.  Upon reexamination, I see that
> I said "overhead" without being specific.  Since we can use the
> updates that are generated today to measure how much (for example)
> bandwidth is already needed, can we calculate how much extra
> bandwidth universal deployment would mean?  Also, perhaps this would
> be most informative in the form of a ratio (i.e. a factor of $x$
> increase).  That way, when people look at events like the one that
> the "General Internet Instability" thread that just happened on
> NANOG refer to, they can gauge the update amplification that was
> seen against what _would_ be seen given bgpsec.  I think this
> actually kind of came up on nanog, so it seems like maybe it would
> be a relevant thing to look at here?
> >
> I think it is just a concrete way to relate the amount of data being
> consumed today, to what may be needed tomorrow.  It isn't so much
> that 1 byte = good and 10 bytes = bad.  More that in trying to
> quantitative compare two behaviors, finding a common reference point
> seems like a good start, imho.  I think a meaningful ratio is more
> useful, but it just needs something to compare.
> 
> Eric
>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 10 Nov 2011 14:47:02 -0500

Hi, Sriram,

Could you supply similar kinds of numbers, but with "peak" instead of
"average", esp. 50%ile, 75%ile,  and 95%-ile levels for "peak"?

Average is much less important than peak, in my experience.
Steady-state is easy.

Also, in noisy/spiky data, mean != median typically. BGP is noisy/spiky.

(Also when doing percentiles, it is essential to say, "95%ile on
5-minute samples, over a period of 1 week" for instance - and those
would be the customary sample windows to use.)

Thanks,
Brian

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Nov 2011 08:19:40 -0500

> Current traffic is 2 to 3 prefixes per update.

There's actually some research on this, I recall the number 'globally'
as 1.2 avg packing... but internally, that may be different, of
course.

-chris

---

From: Danny McPherson <[email-masked]>
Date: Fri, 11 Nov 2011 08:49:41 -0500

> as 1.2 avg packing... but internally, that may be different, of

I'd be interested in a pointer to that Chris, if you could pass it along.

The only quantitative analysis I've seen of this is here:

<http://www.tcb.net/stuff/danny-ucla-pack.pdf>

It's 3 months of data from 6 monitors.  The basic observation is that 
around 30% to 40% updates are packed, and these packed updates 
carry up to 80% of prefixes -- a density that seems to be fairly consistent 
across both iBGP and eBGP monitors.

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Nov 2011 11:45:42 -0500

> I'd be interested in a pointer to that Chris, if you could pass it along.

I had thought randy referenced the thing I am remembering, I'll ask
once I get to the meeting venue.
I think he's also pointed to some study work on the effect of
ingesting 1x prefix vs packed prefixes...

> across both iBGP and eBGP monitors.

neat.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 11 Nov 2011 12:07:04 -0500

You may have missed noticing it...
I had provided the reference and the numbers in my eralier email --
http://www.ietf.org/mail-archive/web/sidr/current/msg03586.html

According to 
__ Average Prefixes per BGP Update:  2.24 __

So yes, I did consider the _prefix _ updates as is the case in BGPSEC (not updates with packing in it).

Sriram

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christopher Morrow [[email-masked]]
Sent: Friday, November 11, 2011 11:45 AM
To: Danny McPherson
Cc: Jakob Heitz; Sriram, Kotikalapudi; sidr wg list
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

neat.

---

From: Danny McPherson <[email-masked]>
Date: Sat, 12 Nov 2011 09:12:43 -0500

> So yes, I did consider the _prefix _ updates as is the case in BGPSEC (not updates with packing in it).

Sriram, 
Yes, I saw this, and it is a useful datapoint.  

I was looking for something more quantitative and closer to core 
ISPs v. a single BGP feed at the "edge", as previously noted.

Thanks, 

-danny

---

From: Eric Osterweil <[email-masked]>
Date: Mon, 14 Nov 2011 14:08:03 +0800

Hey everyone,

So, based on both a long flight, and the comments already made about this draft, I re-read it and wanted to make the following additional comments.  I don't think these are redundant with the comments other have made, but if any of them are, sorry for the noise.

First, I think the notion and general tone of this document are great.  The software engineer in me is very excited to see a good requirements doc at the early stages of a system design.  I hope the remainder of my comments can be read with this high-order bit set. :)

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

Thanks,

Eric

---

From: Brian Dickson <[email-masked]>
Date: Mon, 14 Nov 2011 10:05:36 -0500

> WGLC, could we do that concluding 11/11/11 please?

Sorry, didn't notice the date in the request.

I do have some brief comments about a few bullet points.

3.17 says "no requiring revealing new inter-domain policy info".
3.21 says "don't infer anything regarding intent".
3.22 says "don't trust non-BGPsec markings across trust boundaries".
e.g. communities.

However (whether this has been acknowledged in the "threat" doc or
not), one of the concerns is the ability of BGP speakers, and
presumably this will include BGPsec speakers, to manipulate route
attributes to attract traffic. Another concern is "route leaks" (which
we may not all yet agree on either a definition of, or the scope of
what is/isn't a "route leak").

It'd be a long proof to show this, but I believe it is the case that:
- route path manipulation (outside of the "expected" paths) can only
occur if "route-leak" capabilities exist, i.e. that "route-leaks" are
not prevented via some BGPsec mechanisms. Suggestion: A BGPsec design
MAY include elements designed to mitigate "route leaks".
- (refuting 3.21) This may require marking intent. Suggested text: A
BGPsec design MAY require explicit signaling of intent between
neighbor ASes, and to "mark" in some limited form, that intent inside
a (presumably mandatory) element of a BGPsec design (e.g. via a BGPsec
path element).
- (leads to negation of 3.17) It MAY be necessary to reveal some
aspect of inter-domain policy which can already be accurately inferred
via third-party data and tools -- specifically, and limited only, to
customer/transit/peer.

Additionally:
- BGPsec design(s) SHOULD mark attributes used in path selection which
are transitive, and MAY mark attributes used in path selection which
are non-transitive. (This is necessary for 3.22 to apply and still
avoid path manipulation occurring.)

Brian