Re: [sidr] Last Call: (BGPsec Operational Considerations) to Best Current Practice
hi job, > 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? that is why it is SHOULD. and note it does say "and trusts its upstream(s)." going down the rat-hole of trusting upstreams differently seems an exercise in adding words but not adding value. note that doing path validation would pretty much mean the end site buys new hardware. pointing out that one could avoid that was the purpose of the paragraph. if i made any change, it would be a rant about out-sourcing security. e.g. "Note that this is out-sourcing security, which is generally unwise. But the trade-off is likely out-sourcing security or buying bigger hardware." randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] Last Call: (BGPsec Operational Considerations) to Best Current Practice
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' >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 > i...@ietf.org mailing lists by 2016-12-21. Exceptionally, comments may be > sent to i...@ietf.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. > > ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
[sidr] Last Call: (BGPsec Operational Considerations) to Best Current Practice
The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'BGPsec Operational Considerations' 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 i...@ietf.org mailing lists by 2016-12-21. Exceptionally, comments may be sent to i...@ietf.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. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
