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.
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" 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. The threats document already addresses this issue, in the
Residual Vulnerabilities section. 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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
