Subject: [sidr] draft-sriram-bgpsec-design-choices-00

From: Russ White <[email-masked]>
Date: Tue, 05 Jul 2011 10:36:06 -0400

The list in section 1 does not appear to capture all the requirements as
they've been given in discussions on the list. Specifically, what is not
covered is:

1. Proving intent to advertise. Showing that the AS advertising a route
to a peering AS intended to avertise the reachability information
contained in the BGP update.

2. Proving the path of the update. It is not enough to merely show that
a path exists; any security system must also show the actual path
routing information has taken through the routing system.

3. Providing transitive trust. A network operator must not need to rely
on the filters or policies of neighboring autonomous systems to show the
path an update takes through the system, nor to prove the intent of
prior autonomous systems to advertise reachability through their networks.

These have all been clearly discussed on the list as motivations for the
scheme adopted.

There's a lot of 'we' in this doc, as well --I'm not certain that's good
form for a draft? Finally, there doesn't seem to be a lot of
justification around the length of the timer in an update (what's the
impact on performance system wide, in terms of stability and route
update intervals? Are these justifiable?), nor on why intervening AS'
should not be allowed to include expiration times (why is a change in
the AS path at an intervening AS treated differently than a change in
the AS path at the originating AS?).

Russ

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 5 Jul 2011 22:29:19 -0400

Hi Russ,

Thanks for your comments/observations.
Please see my comments inline.

Sriram

>they've been given in discussions on the list. 

This is a design rationale document.
It merely describes some of the details behind the design decisions.
As you know, requirements are documented in draft-ietf-sidr-bgpsec-reqs. 

>Specifically, what is not covered is:

These are requirements related questions which pertain to
draft-ietf-sidr-bgpsec-reqs. I think Randy may like to respond to these.

>form for a draft? 

I could use the passive form like “It was decided that …” etc. 
everywhere in the doc. I’m not sure that is necessarily better.
But I will take your suggestion into consideration.

>Finally, there doesn't seem to be a lot of
>update intervals? Are these justifiable?), 

This is an ongoing discussion. 
But please see Section 3.2.2 (2nd, 3rd, 4th paragraphs). 
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#page-10  
Also see Section 3.4.
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-3.4 
Sharon Goldberg and I have begun doing detailed modeling
of the BGPSEC route-processor workload to quantify the performance metrics
you have mentioned. We hope to report results in the near future.   

>nor on why intervening AS'
>should not be allowed to include expiration times

It is simply not needed to reduce the replay attack window.
It is sufficient that the origin AS inserts the Expire Time,
and all other ASes in the AS path sign that info as they forward the route.
Please see Section 3.2.2, 1st paragraph.
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#page-10
 
> (why is a change in

In what way do you think they are treated differently?  If the origin AS
announces to a different neighbor, that is just the same as if an AS three
hops down makes a different choice.
Again the discussion in Section 3.2.2 (1st para) can be helpful here.

Sriram

---

From: Russ White <[email-masked]>
Date: Wed, 06 Jul 2011 07:10:53 -0400

> As you know, requirements are documented in draft-ietf-sidr-bgpsec-reqs. 

I would expect it, however, to detail the primary reasons for making
such decisions. The ones I've outlined are, based on the list
discussions, the primary reasons.

> It is simply not needed to reduce the replay attack window.

I don't see how this is true. For instance:

   +--3--+
1--2     5
   +--4--+

Where 1 is originating a route towards 2, and 2 towards 3 and 4. If the
link between 2 and 3 fails, or 2 changes its policy, it must wait the
duration of 1's timer before being assured 3 cannot continue to
advertise the route. From 2's perspective, it has no ability to control
the speed at which it can effectively implement policy or prevent replay
attacks.

This is unacceptable. The timer must be per hop.

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Jul 2011 20:22:36 +0900

> advertise the route.

that is why beaconing is said to provide only a certain measurable and
controllable freshness guarantee.  no surprise there.

> From 2's perspective, it has no ability to control the speed at which
> it can effectively implement policy or prevent replay attacks.
> 

would you explain why this would reduce the window?

e.g., if 2 signs with a time and 3 signs with a time, 3 can still replay
within 2's window, which one presumes is about as wide as 1's window.
no gain, non-trivial pain.

randy

---

From: Russ White <[email-masked]>
Date: Wed, 06 Jul 2011 07:27:00 -0400

> no gain, non-trivial pain.

Because 2 would know its local conditions, and may set the timer
shorter. 1 cannot know 2's local conditions or policies, and yet you are
allowing 1 to control the length of time the connection is acceptable
between 2 and 3.

There is real gain in allowing a per hop timer. It would accurately
reflect the state of the network.

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Jul 2011 20:29:45 +0900

> shorter.

except 2 had already disconnected from 3.  way too much noise for too
little gain.

randy

---

From: Russ White <[email-masked]>
Date: Wed, 06 Jul 2011 07:40:11 -0400

> except 2 had already disconnected from 3.  way too much noise for too

No --if 2 knows the situation with 3 is problematic, it can reduce the
timer on that path.

What you're saying is that the originator should control the rate at
which connectivity and policy should be allowed to change farther down
the graph, because, well, it's too much trouble to do otherwise. What
I'm saying is this is an unacceptable tradeoff --if the point is to
provide security, then provide security at every hop.

Russ

---

From: "Chris Hall" <[email-masked]>
Date: Wed, 6 Jul 2011 18:23:48 +0100

Russ White wrote (on Wed 06-Jul-2011 at 12:11 +0100):
....
> Where 1 is originating a route towards 2, and 2 towards 3 and 4. If
> the link between 2 and 3 fails, or 2 changes its policy, it must
> wait the duration of 1's timer before being assured 3 cannot
> continue to advertise the route. From 2's perspective, it has no
> ability to control the speed at which it can effectively implement
> policy or prevent replay attacks.
> 

How short would the timers have to be to cope with link failures ?

In any case, it seems to me that problems only arise if 3 turns out to
be a Bad Person.  In which case, no matter what any validity timers
say, the objective should be to allow routes to be rapidly withdrawn ?
Each AS announcing routes to 3 gets to make up their own minds about
3's bona fides which will have its own latency, but having made a
decision, having to wait for some timer to expire before being able to
act will seem like a failure ?

If 2 changes which IPs it has allocated to customers, then the RPKI
implements that by creating new and revoking old EE(s).

If 2 changes which ASes it announces routes to, presumably it revokes
the EE(s) associated with the path signatures it now repudiates.  And
the back-channel through the RPKI will update all interested routers,
and any stale routes will be swept away ?  Of course, 2 must first
re-announce everything that currently uses the to-be-updated-keys to
every other peer, and wait for those announcements to be propagated.
Can this be right ?

Mind you, what if:

   +--3--+
1--2  |  5
   +--4--+

In which case, if 4 does not agree with 2's assessment of 3's
character, then 2 is estuffe if 4 announces its routes to 3, and 5
thinks that 3's price for transit is just wonderful, and 3 is a
customer of 4 (which might affect its judgement, of course).

On the other hand, if all parties suddenly realise that 3 is Wicked,
then there will be a sudden rush of new EEs and every route including
3 will be withdrawn, *and* every related route *not* including 3 will
have to be re-announced and have propagated across the BGP mesh,
*before* EEs are updated ?

Or, of course, everybody could do it the old fashioned way, and filter
out routes with AS 3 in the path :-)

Chris

---

From: Russ White <[email-masked]>
Date: Wed, 06 Jul 2011 13:38:51 -0400

> How short would the timers have to be to cope with link failures ?

My argument isn't over the length of the timer, just that the timer
needs to exist per hop, not just for the originator.

> implements that by creating new and revoking old EE(s).

So you would argue that each time you change connections, you should
issue a new EE? Then why have the timer at all?

> out routes with AS 3 in the path :-)

Then what's the point of the signatures in the first place?

Russ

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 7 Jul 2011 13:18:29 -0400

> No --if 2 knows the situation with 3 is problematic, it can reduce the

The problem I see with this is as follows. If 2 knows the situation with 3 is 
problematic, then why would it still send updates to 3? Why would it not 
disconnect with 3 rather than reduce the timer? Also, it does not make 
sense for 2 to set a lower timer value (than that of 1) prior to any hunch 
or knowledge that 3 is bad. Presumably, 2 had already sent some updates 
to 3 prior to knowing that 3 has gone bad (or is suspicious). There is 
nothing 2 can do about those previous updates even if it has the ability 
to adjust its own timer value on subsequent updates. Once that hunch sets in, 
then why not just disconnect with 3? AS-1 anyway was prepared to live 
with replay possibility for the period of its timer when it sent an update 
in the first place. So why should 2 try to be extra helpful with manipulation 
of timers when it really can't. I think all 2 should do to help is to 
forward updates only to 4 (and disconnect from 3) from the moment 
it knows 3 has gone bad or suspicious. We can presume that 1 chose 
its timer value with some prudence, and knows to accept the consequences of it. 

Sriram

---

From: Russ White <[email-masked]>
Date: Thu, 07 Jul 2011 16:53:35 -0400

> disconnect with 3 rather than reduce the timer? 

How does 2 prevent 3 from replaying the update? It doesn't matter when 2
disconnects from 3, it cannot prevent 3 from replaying it's
advertisement until the timer, which is set by 1, times out.

Bottom line question: Why should AS 1 control the length of time AS2 is
vulnerable to replay attacks by AS' further downstream? It seems like a
simple question to me. _Every_ AS along the path has an interest in
making certain it's peers can't replay updates they have sent, not just
the originator. Hence, the timer only makes sense if it is available at
every hop.

Russ

---

From: Rob Austein <[email-masked]>
Date: Thu, 07 Jul 2011 18:02:14 -0400

At Thu, 07 Jul 2011 16:53:35 -0400, Russ White wrote:
> 
> Bottom line question: Why should AS 1 control the length of time AS2
> is vulnerable to replay attacks by AS' further downstream?

Because it's AS 1's prefix.

---

From: Russ White <[email-masked]>
Date: Thu, 07 Jul 2011 21:01:19 -0400

> Because it's AS 1's prefix.

It's AS2's policy. What you're saying is that a downstream AS shouldn't
be allowed to have protection against replay attacks for traffic they no
longer want to handle because --well, just because.

Sorry, I don't agree.

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 07 Jul 2011 21:23:18 -0400

I hate to say this, because mostly I think Russ is starting at shadows,
but I think your answer does not seem to bear on the question that was 
asked.

The fact that AS1 originates an advertisement means that its origination 
information is subject to its lifetime control.
Which is covered by the existing work.
It is also true that the originators path lifetime limitaiton has to 
serve as an upper bound on the lifetime of the advertisement.
But other than those two statements, ti does not seem that the 
originator has any more rights to specify a lifetime than any other 
advertiser adding path information.  Nor does he have any more precise 
information about what a good lifetime is for the path advertisement 
than anyone else has.

This suggests that there is something odd with the lifetime / refresh 
mechanism we have chosen.

Yours,
Joel

On 7/7/2011 6:02 PM, Rob Austein wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>