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

From: "Bora Akyol" <[email-masked]>
Date: Tue, 3 Jan 2006 17:32:30 -0800

Pekka, Tony

I remember specifically discussing X (no heavy processing) and X+1 (no
heavy configuration) during the early stages of this draft.

Without defining what "heavy processing" is, I find that this particular
requirement is not implementable. Is it heavy processing on an AGS+, or
is it heavy processing on a high end router of today? What about latest
gen. embedded processors with built-in crypto capability?

I would reword this as a requirement based on the incoming number of
UPDATES/WITHDRAWS per second, and the number of information units that
are actually processed.

For example something like this:

--
X. Processing Requirements for Securing BGP on Network Elements

All security solutions for securing BGP, MUST be able to process at
least 90% of the offered message rate for the incoming UPDATE/WITHDRAW
etc. BGP messages; and the solutions MUST be able degrade gracefully
when the backlog of unprocessed messages exceeds the storage
capabilities of the network elements. Degrading gracefully may be
construed as dropping earlier messages from the same peer in favor of
the later messages, or stop reading packets from the incoming TCP
sockets, etc.
--

Clearly, "degrading gracefully" part needs more work in definition ;-)

Bora

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Jan 2006 12:20:58 +0200 (EET)

> gen. embedded processors with built-in crypto capability?

We probably can't assume the presence of latest gen. embedded 
processors w/ built-in crypto, if we want to get significant 
deployment in the next 5-7 years from now..

> UPDATES/WITHDRAWS per second, and the number of information units that

Do we know what the metrics are?  Certainly, there may be some 
absolute requirements ("full routing table sync must not take more 
than xxx seconds"), but I'd expect the folks considering secure BGP 
solutions would also be evaluating the performance against the current 
BGP.  While at some point (e.g., if full table sync took less than 5 
seconds) it might not matter if the convergence speed doubled, I'm not 
sure what kind of confort thresholds the operators would have.

Given that we don't really have good metrics on what are 
the exact requirements, it might be best to leave the text 
a bit more generic.

(btw, I spotted a typo in the text I proposed, in section 3.6 
s/especially if/especially if it/

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