Danny,
On 2013-03-11 13:31, Stephen Kent wrote:
Danny,
We have been told by several operators that the values stated in
Section 4.3 of RFC 4271 are not what is used today. We also have been
told that, contrary to the "SHOULD NOT" in Section 5.1.1 of this RFC,
it is not uncommon for ASes to change this value, en route. Given
these two observations, I don't see how one can argue that protecting
this attribute via a PATHSEC mechanism makes sense.
84% of ASes are stubs, apparently. Many of our own ASes are stubs and
we buy transit services in some places from some of the ISPs that like
to muck with the ORIGIN code to exploit traffic attraction attacks.
I'd like a secure routing protocol to be derived from requirements
that accommodate issues that both ISPs and stub ASes are concerned
with. That's what I'd like as an operator. If this is yet another
thing that you believe is beyond the scope of SIDR because the current
BGPSEC spec doesn't accommodate it then why don't we stop pretending
to be writing threats and requirements documents and you just publish
your BGPSEC spec?
I am writing a threats doc consistent with the SIDR WG charter. WGs have
charters to help scope the
set of problems that they address. If the WG recharters to extend the
scope of what security concerns are to be addressed, then this doc will
be revised accordingly.
Separately, there is the issue of whether it makes sense to address
the security of the ORIGIN attribute in the threats document. The SIDR
charter states that the path security goal is "Is the AS-Path
represented in the route the same as the path through 
which the NLRI
traveled"
Careful, I'm not sure the current BGPSEC spec does that at all for the
"AS_PATH", and it actually diverges in some places. If you're going
to use the charter again to nix this requirement as an acceptable
residual vulnerability in the threats draft then it's crystal clear to
me that you and the BGPSEC design team simply want to publish the
BGPSEC draft as you've already envisioned and you don't want to
accommodate my operational requirements. If that's the case then
let's just kill the threats and requirements documents and save
everyone's time.
I'm sorry that you seem to be uncomfortable working within the WG charter.
There are a variety of other attributes that do not directly
support this goal, and which are not being addressed as part of the
PATHSEC model.
Right, and I think they should be, as they all impact BGP path
selection in various ways.
The threats document already addresses this issue, in
the Residual Vulnerabilities section.
Out of curiosity, does anyone intend to ever address the growing list
of "residual vulnerabilities" or is this merely a place to catalog
requirements that would rather not be addressed?
The previous bullet in this section deals with route leaks, and says:
If, at a latertime, the SIDR charter is amended to include route
leaks, and an
appropriate definition exists, this document should be revised.
I'm happy to add an analogous sentence to this bullet as well.
I suggest the following updated
text for that section, to better explain the criteria for inclusion
and exclusion in that document:
PATHSEC is not planned to protect all attributes associated with an
AS_PATH, even though some of these attributes may be employed as
inputs to routing decisions. Thus attacks that modify (or strip) these
other attributes are not prevented/detected by PATHSEC. The SIDR
charter calls for protecting only the info needed to verify that a
received route traversed the ASes enumerated in the AS_PATH, and that
the NLRI in the route is what was advertised. (The AS_PATH data also
may have traversed ASes within a confederation that are not
represented. However, these ASes are not externally visible, and thus
do not influence route selection, so their omission in this context is
not a security concern.) Thus, protection of other attributes is
outside the scope of the charter, at the time this document was
prepared.
Again, I'd like some clarity on how long we're going to hide behind an
explicitly worded charter, or if we're actually going to address any
of these issues?
As far as I'm concerned, we're going to follow IETF procedures.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
