On Oct 28, 2011, at 2:40 PM, Christopher Morrow wrote:
> Seems that the authors, at least, expect this doc to be prepared for
> WGLC, could we do that concluding 11/11/11 please?
I've got a couple of comments.
Some high-level bits captured with specific comments below
include:
1) this appears to largely be a backwards-engineered requirements
set for the BGPSEC drafts submitted. If that's the intention then
it should says it's for BGPSEC and not constrain other solutions.
2) from a mechanics and processing perspective, this appears to
largely focus only on external BGP. It would be useful if the
requirements considered what behaviors and recommendations are
applicable to internal BGP speakers as well.
2) This document seems to allude to a solution that only protects
NLRI and AS_PATH, and ignores ORIGIN and other attributes. This
concerns me a great deal given that most (all?) path selection
today is largely based on policy derived from and applied based
upon all those other attributes.
3) as a WG we need to agree on what constitutes a reasonable
solution for minimizing an exposure window. If we're going
to build such a heavy solution I find it hard to justify new
hardware and tons of complexity if we can't get the window to
seconds or minutes, rather than 8+ hours or more best case with
what we've seen proposed to date, and that's with periodic
updates (ala beacons) that have the scaling properties of RIP.
Some specific comments inline below.
-----
3.1 A BGPsec design must allow the receiver of a BGP announcement
to determine, to a strong level of certainty, that the received
PATH attribute accurately represents the sequence of eBGP
exchanges that propagated the prefix from the origin AS to the
receiver.
By "eBGP exchanges" do you mean some identifier (e.g., BGP Identifiers)
associated with the set of eBGP speakers that exchanged a given prefix, or
simply the ordered sequence of AS adjacencies the prefix traversed?
Would "to the receiver" exclude the local AS, given that it's not added
to the AS_PATH until advertised to an eBGP peer?
What does the "received PATH attribute" mean here? Do you mean the set
of "Path Attributes" contained in an UDPATE message (plural and covering
all path attributes, not just the AS_PATH), or did you only mean the
AS_PATH attribute made up of the sequence of AS path segments?
Irrespective of your answer to the previous question, given that the
ORIGIN attribute is distinct from AS_PATH, do you foresee BGPsec adding
a strong level of certainty to it as well?
It would be useful to clarify what constitutes "announcement" in the draft.
E.g., an UPDATE message that carries only withdrawn routes would be
announced, but doesn't have any path attributes. If only referring to
AS_APTH above, why it not a requirement of BGPSEC to enable some strong
level of certainty to this?
-----
3.2 A BGPsec design must allow the receiver of an announcement to
detect if an AS has added or deleted any AS number other than
its own in the path attribute. This includes modification to
the number of AS prepends.
Is the point of "other than its own" here to reflect the fact that the
local AS isn't added to the path until advertised to eBGP peer?
If it's own is there, should it be able to identify that it was added
and validates before pruning, or should it be ignored and pruned without
validation first?
-----
3.3 A BGPsec design MUST be amenable to incremental deployment.
Any incompatible protocol capabilities MUST be negotiated.
3.4 A BGPsec design MUST provide analysis of the operational
considerations for deployment and particularly of incremental
deployment, e.g, contiguous islands, non-contiguous islands,
universal deployment, etc..
3.5 As cryptographic payloads and memory requirements on routers
are likely to increase, a BGPsec design MAY require use of new
hardware. I.e. compatibility with current hardware abilities
is not a requirement that this document imposes on a solution.
As BGPsec will likely not be rolled out for some years, this
should not be a major problem.
While I understand the "spirit" of this, it seems to be largely in
conflict with requirement 3.3 above. e.g., I wouldn't consider required
use of new hardware fully "amenable to incremental deployment" unless you
have the capability to selectively apply BGPsec on a per prefix basis.
Given that new hardware MAY be required, do you anticipate that "hardware
abilities" to be conveyed to a peer, or do you believe this will be a
system level setting? E.g., with current hardware if I can only handle
processing of n BGPsec prefixes without an upgrade and I want that to be
for the 13 root servers, and m TLD prefixes, and google, can I do that,
and then plan old BGP for everything else -- or is this all or nothing?
If we're decoupling all the transport and most path attributes, why
can't I do this on a per-prefix basis?
-----
3.6 A BGPsec design need not prevent attacks on data plane traffic.
It need not provide assurance that the data plane even follows
the control plane.
3.7 A BGPsec design MUST resist attacks by an enemy who has access
to the link layer, per Section 3.1.1.2 of [RFC4593]. In
particular, such a design must provide mechanisms for
authentication of all data, including protecting against
message insertion, deletion, modification, or replay.
Mechanisms that suffice include TCP sessions authenticated with
IPsec [RFC4301] or TLS [RFC5246].
Given the current text, BGPsec itself isn't resisting these vectors, it's
simply utilizing lower layer mechanisms that do - perhaps we should say
that instead? Else perhaps we expand beyond "link layer" such that
broader attacks for which TLS and IPsec provide protections are also
covered?
-----
3.8 A BGPsec design MAY make use of a security infrastructure
(e.g., a PKI) to distribute authenticated data used as input to
routing decisions. Such data include information about
holdings of address space and ASNs, and assertions about
binding of address space to ASNs.
3.9 If message signing increases message size, the 4096 byte limit
on BGP PDU size MAY be removed.
"message signing" is ambiguous? I think you mean "attribute signing"?
And while I understand the objective here and the necessity given the
BGPSEC protocol that's been put forth, if we're writing general
requirements here shouldn't this impose some upper bound, or are we
simply using a requirements document to remove previous requirements
defined elsewhere and prescribe solutions?
-----
3.10 It is entirely OPTIONAL to secure AS SETs and prefix
aggregation. The long range solution to this is the
deprecation of AS-SETs, see [I-D.ietf-idr-deprecate-as-sets].
What does "and prefix aggregation" mean here? I assume it simply means
prefix aggregation via AS_SETs?
-----
3.11 If a BGPsec design uses signed prefixes, given the difficulty
of splitting a signed message while preserving the signature,
it need NOT handle multiple prefixes in a single UPDATE PDU.
Can you clarify what "signed prefix" means? Also, what about withdrawn
routes in the same UDPATE message?
Also, I don't see "need NOT" in RFC 2119 keywords, and would hate to
think such a general requirement would keep folks from including multiple
NLRI in a single update, if they had the capability.
-----
3.12 A BGPsec design MUST enable each BGPsec speaker to configure
use of the security mechanism on a per-peer basis.
How about a per-prefix basis?
-----
3.13 A BGPsec design MUST provide backward compatibility in the
message formatting, transmission, and processing of routing
information carried through a mixed security environment.
Message formatting in a fully secured environment MAY be
handled in a non-backward compatible manner.
Can you define "mixed security environment" and "fully secured
environment"?
-----
3.14 While the trust level of an NLRI should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other decisions. Such mechanisms
MUST conform with [I-D.ietf-sidr-ltamgmt].
I don't understand this. sidr-ltamgmt talks about accommodating
other "trusted channels" but only in the context of "TA material".
Can you explain your intention here, as neither accommodate local or
other functions that may well intentionally override RPKI or Local
TA material.
Also, what about other attributes that impact BGP best path and
other decisions, are they to be protected via BGPsec?
-----
3.15 A BGPsec design MUST support 'transparent' route servers,
meaning that the AS of the route server is not counted in
downstream BGP AS-path-length tie-breaking decisions.
This requirement is essentially rewriting what a transparent
route server is.
Is this a requirement that is intended to be supported globally in
incremental deployment and non-contiguous islands mode (e.g., we
introduce new BGPsec attributes that influence path selection and
subsequent packet forwarding, but non-BGPsec speakers don't know
about or factor them)?
And what if I want to factor them, seems reasonable to me?
------
3.16 If a BGPsec design makes use of a security infrastructure, that
infrastructure SHOULD enable each network operator to select
the entities it will trust when authenticating data in the
security infrastructure. See, for example,
[I-D.ietf-sidr-ltamgmt].
3.17 A BGPsec design MUST NOT require operators to reveal more than
is currently revealed in the operational inter-domain routing
environment, other than the inclusion of necessary security
credentials to allow others to ascertain for themselves the
necessary degree of assurance regarding the validity of NLRI
received via BGPsec. This includes peering, customer, and
provider relationships, an ISP's internal infrastructure, etc.
It is understood that some data are revealed to the savvy
seeker by BGP, traceroute, etc. today.
Hrmm, isn't this in direct conflict with 3.5 above? I.e., transparent
route servers are transparent outside the local adjacencies.
Without defining what constitutes "necessary security credentials" I
can't understand this requirement as is. For example, I might consider
it necessary to know that ISP b is NOT a transit for Enterprise E. If
BGPsec in this case is anything beyond the operational messaging system
then this requirement seems misplaced to me.
-----
3.18 A BGPsec design SHOULD flag security exceptions which are
significant enough to be logged. The specific data to be
logged are an implementation matter.
"... unless otherwise indicated in the relevant protocol specifications."?
Surely we're going to indicate in the specs some things that MUST be
logged?
-----
3.19 Any routing information database MAY be re-authenticated
periodically or in an event-driven manner, especially in
response to events such as, for example, PKI updates.
Are we simply justifying periodic updates (i.e., beaconing) with this?
Shouldn't the general requirement be to minimize the exposure window,
rather than prescribing a solution?
And if we're going to state that we must provide the capability to
minimize the exposure window, then having a discussion on what a
reasonable exposure window is would seem to be in order, as this has
significant implications on the architecture chosen.
-----
3.20 Should a BGPsec design use hashes or signatures, it should
provide mechanisms for algorithm agility.
"should", "SHOULD", or "MUST"? I would think the latter of these.
-----
3.21 A BGPsec design SHOULD NOT presume to know the intent of the
originator of a NLRI, nor that of any AS on the AS Path.
Isn't the intent to convey destination reachability? I honestly
don't know what this requirement is aiming to accommodate, can you
explain?
-----
3.22 A BGP listener SHOULD NOT trust non-BGPsec markings, such as
communities, across trust boundaries.
This is a requirements document, why are we presupposing what
constitutes a BGPsec "marking" here? If we must, then we need to
detail what *attributes* are and are not in scope -- or is that
what you're trying to do in the next section?
-----
4. BGP UPDATE Security Requirements
The following requirements MUST be met in the processing of BGP
UPDATE messages:
4.1 A BGPsec design MUST enable each recipient of an UPDATE to
formally validate that the origin AS in the message is
authorized to originate a route to the prefix(es) in the
message.
Including an iBGP speaker within the origin AS, where there is no
origin AS as of yet?
I don't see any text in these requirements on internal BGPisms,
is this deemed out of scope?
-----
4.2 A BGPsec design MUST enable the recipient of an UPDATE to
formally determine that the NLRI has traversed the AS path
indicated in the UPDATE. Note that this is more stringent than
showing that the path is merely not impossible.
In this case, are you referring to the normal AS_PATH attribute, or
the path that might be conveyed in a BGPSEC protocol (e.g., to accommodate
"transparent route servers"?
-----
4.3 Replay of BGP UPDATE messages need not be completely prevented,
but a BGPsec design MUST provide a mechanism to control the
window of exposure to replay attacks.
To control them to within what size window? I'd certainly think
something in the low "minutes" period needs to be accommodated if
we're going to add a huge amount of machinery to mitigate accidents
and attacks? Some express guidance on what constitutes a
reasonably scoped window needs to be provided here.
-----
4.4 A BGPsec design SHOULD provide some level of assurance that the
origin of a prefix is still 'alive', i.e. that a monkey in the
middle has not withheld a WITHDRAW message or the effects
thereof.
"origin" meaning origin AS, or something else? Also, to accomplish
this I assume you envision the design accommodating some strong level
of certainty that the ORIGIN attribute is accurately represented?
Also, I assume you mean "WITHDRAWN ROUTES" field in an UPDATE message?
-----
4.5 NLRI of the UPDATE message SHOULD be able to be authenticated in
real-time as the message is processed.
Shouldn't this also apply to WITHDRAWN ROUTES? And AS_PATH and other
attributes as well, for that matter?
-----
4.6 Normal sanity checks of received announcements MUST be done,
e.g. verification that the first element of the AS_PATH list
corresponds to the locally configured AS of the peer from which
the UPDATE was received.
This assumes external BGP only?
-----
4.7 The output of a router applying BGPsec to a received signed
UPDATE MUST be either Valid or Unverified. There should be no
shades of grey.
Are we prescribing here that UPDATE messaging will be signed, and not
specific attributes within those messages? :-)
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
