draft-ietf-sidr-bgpsec-ops-11.txt   draft-ietf-sidr-bgpsec-ops-12.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: Best Current Practice December 2, 2016 Intended status: Best Current Practice December 6, 2016
Expires: June 5, 2017 Expires: June 9, 2017
BGPsec Operational Considerations BGPsec Operational Considerations
draft-ietf-sidr-bgpsec-ops-11 draft-ietf-sidr-bgpsec-ops-12
Abstract Abstract
Deployment of the BGPsec architecture and protocols has many Deployment of the BGPsec architecture and protocols has many
operational considerations. This document attempts to collect and operational considerations. This document attempts to collect and
present the most critical and universal. It is expected to evolve as present the most critical and universal. It is expected to evolve as
BGPsec is formalized and initially deployed. BGPsec is formalized and initially deployed.
Requirements Language Requirements Language
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2017. This Internet-Draft will expire on June 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 26 skipping to change at page 6, line 26
uses pCount of zero to not increase the effective AS hop count, uses pCount of zero to not increase the effective AS hop count,
thereby retaining the intent of 'transparency'. thereby retaining the intent of 'transparency'.
If it is known that a BGPsec neighbor is not a transparent route If it is known that a BGPsec neighbor is not a transparent route
server, or is otherwise validly using pCount=0 (e,g, see server, or is otherwise validly using pCount=0 (e,g, see
[I-D.ietf-sidr-as-migration]), and the router provides a knob to [I-D.ietf-sidr-as-migration]), and the router provides a knob to
disallow a received pCount (of zero, that knob SHOULD be applied. disallow a received pCount (of zero, that knob SHOULD be applied.
Routers should disallow pCount 0 by default. Routers should disallow pCount 0 by default.
To prevent exposure of the internals of BGP Confederations [RFC5065], To prevent exposure of the internals of BGP Confederations [RFC5065],
a BGPsec speaker which is a Member-AS of a Confederation MUST NOT a BGPsec speaker exporting to a non-member removes all intra-
sign updates sent to another Member-AS of the same Confederation. confederation Secure_Path segments. Therefore signing within the
confederation will not cause external confusion even if non-unique
private ASs are used.
8. Notes 8. Notes
For protection from attacks replaying BGP data on the order of a day For protection from attacks replaying BGP data on the order of a day
or longer old, re-keying routers with new keys (previously) or longer old, re-keying routers with new keys (previously)
provisioned in the RPKI is sufficient. For one approach, see provisioned in the RPKI is sufficient. For one approach, see
[I-D.ietf-sidr-bgpsec-rollover] [I-D.ietf-sidr-bgpsec-rollover]
Like the DNS, the global RPKI presents only a loosely consistent Like the DNS, the global RPKI presents only a loosely consistent
view, depending on timing, updating, fetching, etc. Thus, one cache view, depending on timing, updating, fetching, etc. Thus, one cache
 End of changes. 4 change blocks. 
6 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/