Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03

From: [email-masked]
Date: Thu, 19 Jan 2006 11:07:24 -0500 (EST)

>Just because something isn't easy to define doesn't mean it's not a 
>requirement, IMHO. :-)

There are lots of requirements we all vaguely understand ("run a
secure operation", "secure the protocols", "be happy", ...)
but writing a specification of a requirement should be much more
crisply stated.

Otherwise, future solution designs compared against the requirements
will lead to an endless round of "Yes, it is -- No, it isn't -- Is, too
-- No way" with no way to resolve the dispute.

--Sandy

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Jan 2006 18:58:50 +0200 (EET)

> -- No way" with no way to resolve the dispute.

Frankly, that situation smells a lot like one where the group would 
not have anywhere near rough consensus on the solution it wants to 
design.  In that case, no matter the wording of requirements, I doubt 
consensus would emerge before the group would be overtaken by events.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 13:32:22 -0500

> -- No way" with no way to resolve the dispute.

And, if you don't state what performance impacts are acceptable, then 
you wind up with a perfect, but perfectly undeployable, solution. 
Performance impacts, while always difficult to measure and consider, 
still need to be taken into consideration.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 14:11:06 -0500

At 1:32 PM -0500 1/19/06, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

Russ,

I think this WG cannot state what performance impacts are acceptable. 
You attended the same DHS routing security workshops that I did. You 
saw the tremendous range of views on what constitutes acceptable 
performance impacts even for an existing security mechanism, i.e., 
the TCP MD5 option.  The best we can do is to note that performance 
impacts are a concern because they probably will influence deployment 
decisions, and that SIDR should keep this in mind when evaluating 
solution options.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 15:25:53 -0500

> You attended the same DHS routing security workshops that I did. You saw 
> the tremendous range of views on what constitutes acceptable performance 
> impacts even for an existing security mechanism, i.e., the TCP MD5 
> option.  The best we can do is to note that performance impacts are a 
> concern because they probably will influence deployment decisions, and 
> that SIDR should keep this in mind when evaluating solution options.

Was the performance of encryption not taken into account when designing 
such solutions as IPsec?

Let me put it another way: I don't believe it's the right thing just to 
rule out discussing performance impacts, which the users of any proposed 
system are obviously concerned about, just because they cannot be 
"specified cripsly." If we only specified things we could "specify 
crisply," then half of what we work on could never be specified.

I do believe it's useful to have a discussion about how to contain the 
performance requirements within some text that implementors and 
designers will understand. I don't beleive it's useful to simply remove 
such text because it's "hard to specify."

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 17:10:59 -0500

>Was the performance of encryption not taken into account when designing

For the most part no, it was not a major issue. IPsec originally 
required support for DES, but other algorithms, some faster, some 
nominally stronger, were allowed.  We then moved to 3DES, was was 
stronger by 2X, but was also 3X slower! We added support for combined 
mode algorithms in 4301, because crypto technology had evolved to a 
point where we could encrypt a lot faster than we could do integrity 
checking, and combined mode algorithms allow one to do both 
operations in a very fast manner.

We did pay attention to the order in which integrity and encryption 
operations were performed, to minimize the impact of DoS attacks that 
are made possible because of using IPsec. That's a good thing for 
RPSEC to note as well.

If we turned back the clock to the later half of the 90's, one could 
argue that some applications running on commonly available hardware 
might not be able to use IPsec because of performance concerns. That 
did not prevent IPsec form being defined in a fashion that allowed 
for its use with these apps as performance improved.

In fairness, though, IPsec can be used, or not used, on a pairwise 
basis between consenting end points. BGP security measures need 
widespread adoption by ISPs to be effective, so the two situations 
are not quite the same.

>such text because it's "hard to specify."

I don't suggest we remove all references to performance. But I 
provided an example of the sort of text I would suggest we adopt, at 
least as a starting point. The suggestion is to acknowledge that 
performance is a concern that must be considered, while also 
acknowledging that we cannot create requirements for performance 
because of the complexity of specifying objective criteria.

Steve