Hi Danny,
Thanks for the comments.
In general, I don't like the idea of using an extcomm community to
convey
a prefixes validation state, I think we should deal with this
problem natively
(e.g., as BGPSEC inter-domain) if we're going to address the
problem, in
particular if we're not going to address the AS Confederations
problem.
Can you describe specific concerns you have with using extended
community?
It does work with confederations.
Furthermore, I don't like the deployment considerations, in
particular because
of "privilege escalation attacks" which could easily occur through
misconfiguration
across multiple attribute mapping functions, or simply because the
extcomm was
received from an BGP peer that isn't "upgraded to support the
extensions
defined in this document":
"In deployment scenarios where not all the speakers in an autonomous
system are upgraded to support the extensions defined in this
document, it is necessary to define policies that match on the
origin
validation extended community and set another BGP attribute
[I-D.ietf-sidr-pfx-validate] that influences the best path selection
the same way as what would have been enabled by an implementation of
this extension."
Do you have alternatives in mind for incremental deployment case?
Finally, this should certainly a normative reference in the pfx-
validate draft.
Ack.
- Pradosh
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
