Subject: [RPSEC] A plea for progress

From: Tony Li <[email-masked]>
Date: Tue, 27 Sep 2005 01:26:54 -0700

Folks,

I've been lurking on this list, watching the back and forth and am  
moved to comment about a few requirements that I don't think are  
truly recognized.

A strong requirement in my mind is that we be computationally,  
theoretically,   operationally, temporally, and procedurally  
pragmatic.  We have been discussing this subject for more than a  
decade now and have yet to come to any consensus about a solution,  
much less get to running code.  We have proposals on the table, yet  
while we debate them back and forth, the security of the BGP mesh is  
basically wide open.  Multiple faults that could and would have been  
caught by *any* proposal have impacted millions of users.  This is  
not good.  We need to make forward progress towards closure.

We know that we cannot do a perfect job: as has been noted, the  
forwarding plane is not secured by any of the requirements that are  
currently put forth and I think that there is broad consensus that  
this is not within scope.  Given that we are conceding this threat,  
where is the logic behind spending our time, effort and resources  
securing the routing information in great detail?  We can bolt,  
shutter and reinforce the front door, but what's the point if the  
back door is unlocked?  Similarly, as Steve Kent notes that BGP is  
ill-suited to protections against replay attacks.   Are we going to  
try to fix that, and basically redesign BGP dynamics?  As is common  
in any security problem, the costs of security must not outweigh the  
threat.

I realize that there are many opinions out there and that the  
contention is not going to evaporate overnight.  However, I would  
like to see us make progress in the short term as well as continue  
the ongoing debate.  Towards that end, I'd like to propose that we  
change course slightly and instead focus the efforts of the WG  
towards coming up with a set of interim requirements and an interim  
solution that can be deployed in an expedient manner.  I'd propose  
that we set a deadline of the end of this coming IETF.  Any  
requirements that we have clear consensus on would be adopted as part  
of the interim requirements and we would then proceed directly with  
an interim solution for those interim requirements.

Again, the goal of this would be to deliver enhanced security to the  
field in a timely manner to forestall the obvious attacks.  This is  
not to preclude any ongoing work into the more challenging areas.

Regards,
Tony

Note bene: Please note that I'm no longer a router vendor and am now  
on the 'operations' side of the world.

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Sep 2005 10:32:30 -0400

Tony,

I agree with many of the points you made in your message.

The ADs could choose to redirect the WG to make this document target 
interim requirements, but remember that this WG is not chartered to 
work on solutions.

Often one talks in terms of interim solutions that make progress 
toward long term, agreed upon requirements. So, I'm not too 
enthusiastic about changing the requirements document to focus only 
on the near term. I'd rather let the solutions WG make those 
tradeoffs.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 27 Sep 2005 11:42:50 -0400

> contention is not going to evaporate overnight.  However, I would  like 
> to see us make progress in the short term as well as continue  the 
> ongoing debate.  Towards that end, I'd like to propose that we  change 
> course slightly and instead focus the efforts of the WG  towards coming 
> up with a set of interim requirements and an interim  solution that can 
> be deployed in an expedient manner.  I'd propose  that we set a deadline 
> of the end of this coming IETF.  Any  requirements that we have clear 
> consensus on would be adopted as part  of the interim requirements and 
> we would then proceed directly with  an interim solution for those 
> interim requirements.

Thank you, Tony, for bringing us back on topic. IMHO, the draft, as it 
sits, provides a good basis for building a security system that would 
meet what you've outlined above. There are differences of opinion, and 
there are things that need to be worked out in the implementation/design 
phases, but we can't solve all the problems here.

In fact, in this spirit, the current draft might even have some places 
where the wording could actually be "loosened," where things that are 
MUSTs or SHOULDs could be reduced, or something of that nature.

I really would like to get this draft last called, and move forward.

:-)

Russ

---

From: Blaine Christian <[email-masked]>
Date: Tue, 27 Sep 2005 11:47:17 -0400

>
> In fact, in this spirit, the current draft might even have some  
> places where the wording could actually be "loosened," where things  
> that are MUSTs or SHOULDs could be reduced, or something of that  
> nature.
>

1. Agree totally...
2. Let's try not to do too much "defanging".  With no teeth it will  
come off sounding trite and will be useless to drive change.

---

From: Russ White <[email-masked]>
Date: Tue, 27 Sep 2005 12:00:07 -0400

>> that are MUSTs or SHOULDs could be reduced, or something of that  nature.
>>

Yes.... I offer this as a lead in to anyplace Tony might think the draft 
is actually "too tight." I would actually prefer to look back over the 
original set of issues raised after the last call, and simply accept 
those things to which there has been a concensus on the list, nad not 
the ones where we've have substantial disagreement.

I think we're always going to stick on the same points--the document 
balances them well, IMHO, so let's move past them, and work on other 
things (like OSPF and MANET security, for instance!).

:-)

Russ