Hi all,
This following paragraph looks somewhat awkward to me.
TEXT:
An edge site which does not provide transit and trusts its
upstream(s) SHOULD only originate a signed prefix announcement and
need not validate received announcements.
COMMENT:
If you are multihomed and receive full (or partial) tables, there is
benefit in validating the received routes, if not: why not? One
upstream might be poisoned while the other isn't? Mabye the text
should be amended to make it clear that this might apply if the stub
ASN only takes default-originates?
Kind regards,
Job
On Wed, Dec 07, 2016 at 07:27:28AM -0800, The IESG wrote:
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'BGPsec Operational Considerations'
<draft-ietf-sidr-bgpsec-ops-12.txt> as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2016-12-21. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
Deployment of the BGPsec architecture and protocols has many
operational considerations. This document attempts to collect and
present the most critical and universal. It is expected to evolve as
BGPsec is formalized and initially deployed.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ballot/
No IPR declarations have been submitted directly on this I-D.
The document contains these normative downward references.
See RFC 3967 for additional information:
rfc6811: BGP Prefix Origin Validation (Proposed Standard - IETF stream)
draft-ietf-sidr-bgpsec-protocol: BGPsec Protocol Specification (None -
IETF stream)
rfc6493: The Resource Public Key Infrastructure (RPKI) Ghostbusters
Record (Proposed Standard - IETF stream)
Note that some of these references may already be listed in the acceptable
Downref Registry.