Randy,
On Jan 30, 2011, at 20:40 MST, Randy Bush wrote:
>> 3.3 As cryptographic payloads and loading on routers are likely to
>> seriously increase, a BGPsec design may require use of new hardware.
>> It must be possible to build routers that do BGPsec with within
>> acceptable (to operators) bounds of cost and performance.
>>
>> This should be left out of any requirements document, and various
>> proposed system compared based on their costs and deployment
>> difficulty.
>
> i take your point. the intent was that compatibility with current
> hardware abilities is not a requirement that this document imposes on a
> solution. it is quite likely that provider routers will need crypto
> assist and more ram. though one hope that the stub customer edge will
> not.
Whoa there. I couldn't disagree more wrt the above.
First, let's start with the most fundamental question. Why is it that routers
MUST sign, pass around and verify _in-band_ in the control plane various
contents/PDU's _within_ BGP? Note my very careful use of the work _in-band_.
By that I mean inside the BGP session itself, not on a side-band channel like
RPKI and/or IRR is used today. While I have grave concerns over in-band
signing & verification, I am [much] less concerned about the latter for several
reasons. With respect to in-band:
1) I'm extremely concerned over dependencies of automatically "trusting"
signed data in-band within the control plane and not being able to reach
servers (RP's?) to verify the contents of the PDU's are legitimate. At least
with prefix-filters and/or AS_PATH filters, it's very easy for me to manually
disable some or all filtering for particular destinations in order to, say, get
reachability to servers (RP's) to verify the authenticity of data.
2) Related to point #1, we really should go back to first principles ask
ourselves if we're really intending to conflate the _transport_ method (BGP)
with the requirement to verify the data _inside_ of BGP. If so, what is the
reason? Is it solely for convenience, (because BGP transport is already
there), or other reasons?
3) I really, really don't like the idea of "will need crypto assist and more
ram" on my RE/RP's for several reasons, namely:
a) It's one more set of variables that my already over-worked Capacity
Planning and NOC groups need to keep track of and attempt to stay ahead of.
b) It's extremely costly to upgrade RE/RP's, because said RE/RP's are only
available from one source -- equipment vendors. And, the upgrade paths
typically don't buy you much in terms of more CPU, etc., because vendors are
obligated to source "established" components they know they'll be able to
acquire for several years into the future. And, worst of all, the cycle to get
those RE/RP's into the network is extremely long when you start to consider the
budgeting, testing of new code, physical installation, customer disruption
during maintenance windows, etc.
... at least with respect to (b), if I were able to use offboard CPU (i.e.:
Intel/AMD servers, like in the RPKI/IRR world), then I have a much larger
selection of HW to choose from and I can upgrade those in the network much,
much more quickly.
At least with respect to #1 and #2, I don't see any discussion of the above in
the current draft (although maybe I missed it?). But, IMHO, those are
_fundamental_ requirements that need to be discussed among the WG. Before
touching on any of the other points in Russ White's e-mails in this thread,
(which I agree with), I think it's important to get back to basics.
> and the operators with whom we discussed (note that i am an operator,
> not a vendor with a bad habit of speaking for operators) this thought
> that this needed to be said from both ends of the scale. we did not
> want the future security constrained by a 7200, nor did we want an
> explosion in costs. as dollars are the bottom line in our capitalist
> culture, constraining them seems quite reasonable.
It wasn't discussed with me. :-)
-shane
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
