Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

["George, Wes" <[e-mail]>]

> From: Christopher Morrow
>
> Seems that the authors, at least, expect this doc to be prepared for
> WGLC
> -Chris
> <wg-co-chair-haircut == completed>

[WEG]] So should we expect you to have "SIDR" or "WGCHAIR" shaved into your hair when we see you in Taipei? ;-)

More seriously, some comments...

Editorial nit: This document uses RFC2119 language inconsistently (at least as far as capitalization is concerned)

I think that we need some clearer documentation about prepends and support for them. Specifically, right now the way that 3.2 is worded, it almost sounds like the aim is to detect and prevent *all* prepends, rather than acknowledging that this is a common TE practice that will need to be supported by BGPSec implementations. It may be that I'm simply misinterpreting the language in 3.2 and that was the intent to start with, but it may be useful to clarify legitimate prepends (prepending ones own ASN) vs those generally viewed as unacceptable (prepending someone else's ASN).
And while we're on the subject of prepends, I also would like to see this document explicitly require a few of the more obvious optimizations... something like, "a BGPSEC design SHOULD NOT require [signature] data to be linearly duplicated when an AS-path contains multiple valid instances of the same ASN."

Regarding 3.5 - I think that this is inadequate as currently written. First, this is a static document, especially once it becomes an RFC, therefore over the life of the document, the concept of "current hardware abilities" changes pretty drastically. Adding a modifier akin to "at the time of this document's writing" would clarify. I would also avoid the editorializing "...should not be a major problem" within the requirement, and leave that to the discussion within the solution drafts of how they meet this requirement.
However, even when this requirement is combined with 4.5 it represents a really low bar when it comes to performance requirements.
I'd be far more comfortable if this document set a design target as to what percentage of increase in convergence times or update processing times is viewed as generally adequate. i.e. "A BGPSec design MUST provide sufficient optimization (through a combination of hardware capabilities and algorithm) such that BGP convergence (or possibly update processing?) times are within NN% of those in a similar system without the BGPSec design in place." It might also make sense for similar targets to be set for things like memory utilization for table storage, update frequency (due to the possibility of beaconing), etc. I realize that some of these things are going to be implementation specific, but providing those requirements to implementers up-front would ensure that the thing which they implement will actually be usable and will help them to characterize what the hardware requirements actually should be. It has to be a design consideration, because we don't want implementers to work on their implementation only to have it be rejected because it represents too much of a performance tax.
I think that fundamentally, this is one of the larger tradeoffs that we need to be acknowledging, in terms of what you give up in order to gain better route security. If it doesn't work with acceptable performance, the bar (cost) for deployment is much higher, and this design becomes an example of the old joke about how the only secure server is the one that's not connected to the network. I'm not suggesting "something for nothing" as much as I am suggesting that we be very clear about the interconnection between performance expectations, hardware requirements, and the security benefits represented by this enhancement.
It may also be a good idea to explicitly note "performance impacts" as a part of 3.4.

Section 4 (somewhere), 3.13 - Is it a requirement that all boxes participating in the BGPSec design support 4-byte ASNs natively, or is this expected to "validate" instances of AS23456 in the ASpath to maintain backward compatibility with non 4-byte ASN speakers?
What about any considerations around the choice of using ASPlain vs ASDOT notation? I think it's probably sufficient to simply require that any solution supports both forms without a change being required in the update data (i.e. in the current design, there shouldn't be a different signature required for a 4-byte ASN represented in ASPLAIN notation vs ASDOT).

4.7 - what about invalid? I view unverified as unknown, which is different. Is this supposed to align with the states defined in origin validation?

Thanks,
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.