Subject: [sidr] bgpsec-reqs-00

From: Russ White <[email-masked]>
Date: Sat, 29 Jan 2011 12:55:58 -0500

First, I will state for the record that I do _not_ think the SIDR
working group should take this as a "baseline" draft for BGP AS Path
validation without serious rework. Specific points:

==
3.3 As cryptographic payloads and loading on routers are likely to
seriously increase, a BGPsec design may require use of new hardware.  It
must be possible to build routers that do BGPsec with within acceptable
(to operators) bounds of cost and performance.

This should be left out of any requirements document, and various
proposed system compared based on their costs and deployment difficulty.

==
3.7 If message signing increases message size, the 4096 byte limit on
BGP PDU size MAY be removed.

Has anyone done any analysis of the impact of increasing the MTU size on
all BGP speakers on the Internet at large? Before making such a blanket
statement, I would like to hear from vendors and operators about the
impact of such a change.

==
3.9 If a BGPsec design uses signed NLRIs, it need NOT handle multiple
NLRIs in a single UPDATE, given the impossibility of splitting a signed
message while preserving the signature.

I'm not certain why this would be in a requirements document. Can anyone
explain how this directly relates to the security of BGP? IE, what is
the direct relationship between stating that packing is no longer needed
in BGP, and improving the security of BGP itself?

This should be completely removed from the requirements list, and left
open as one point of consideration between competing proposed systems.

==
3.14 A BGPsec design MUST NOT require operators to reveal proprietary
data.  This includes peering, customer, and provider relationships, an
ISP's internal infrastructure, etc. Though it is understood that some
data are revealed to the savvy seeker by BGP, traceroute, etc. today.

What sense does it make to say the only system which may be deployed is
one that protects information already publicly available? This is a
non-requirement, and must not be included in the requirements list.

==
4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally
determine that the UPDATE has traversed the AS path indicated in the
UPADTE.  Note that this is more stringent than showing that the path is
merely not impossible.

I've always thought requirements documents proposed a set of
requirements, rather than a set of end goals. This entire "bullet" needs
to be replaced with a realistic set of requirements concerning what can,
and cannot, be proven about an AS Path in BGP, and then what we can
actually require.

What does "proving the AS Path the update has traversed," prove,
precisely? Does receiving an update through a specific path prove
traffic sent to that destination will traverse the path listed? Does
receiving an update prove that all destinations listed are reachable
along the path listed? Does receiving an update prove that every AS
along that path has agreed to forward traffic transmitted to the
destination indicated? It proves none of the above.

The document needs justification, not assertions.

==
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.

Again, this is an assumption which I completely and totally disagree
with. What is the window size allowed in terms of time? Is it minutes,
hours, days, weeks, months, or years?

==
In short, this document does NOT accurately reflect the needs or
requirements of BGP security, and should NOT be adopted as a WG document.

Russ

---

From: Randy Bush <[email-masked]>
Date: Mon, 31 Jan 2011 12:40:27 +0900

hi russ,

> seriously increase, a BGPsec design may require use of new hardware.
> It must be possible to build routers that do BGPsec with within
> acceptable (to operators) bounds of cost and performance.
> 

i take your point.  the intent was that compatibility with current
hardware abilities is not a requirement that this document imposes on a
solution.  it is quite likely that provider routers will need crypto
assist and more ram.  though one hope that the stub customer edge will
not.

and the operators with whom we discussed (note that i am an operator,
not a vendor with a bad habit of speaking for operators) this thought
that this needed to be said from both ends of the scale.  we did not
want the future security constrained by a 7200, nor did we want an
explosion in costs.  as dollars are the bottom line in our capitalist
culture, constraining them seems quite reasonable.

and we will try to phrase better in the next version, we promise :)

> Has anyone done any analysis of the impact of increasing the MTU size
> on all BGP speakers on the Internet at large? Before making such a
> blanket statement, I would like to hear from vendors and operators
> about the impact of such a change.

i am trying really hard to sort out what you are trying to say and have
failed.  bgp is not carried over udp, but rather tcp.  this is not a
change in the mtu, it is a change in the bgp pdu carried over tcp.  as
bgp is next hop only, no transitive change in mtu would be needed
anyway.

> NLRIs in a single UPDATE, given the impossibility of splitting a
> signed message while preserving the signature.
>
> I'm not certain why this would be in a requirements document. Can
> anyone explain how this directly relates to the security of BGP? IE,
> what is the direct relationship between stating that packing is no
> longer needed in BGP, and improving the security of BGP itself?

note the 'need not.'  it does not say 'must not'.  the point is that, if
there is a signature over the bundled nlri, that signature can not
survive the next bgp peer, who will unpack the nlris due to their
routing policy not sending the whole bundle to their next peer.
i.e. imagine R0 sends a bundle to its customer R1, and R1 selects some,
but not all, routes from R0 and others from elsewhere to send to its
customer, R2.

and, btw, actual experimantal measurement has shown that unpacking nlri
does not increase things unacceptably, even on small routers.

> What sense does it make to say the only system which may be deployed
> is one that protects information already publicly available? This is a

this is an absolute from many operators.

there is information and there is information.  basic security info
hiding theory says that you can not absolutely protect anything, you can
just raise the cost of getting it.

this is one of the reasons for the failure of the IRR, many operators,
especially some of the largest, just don't want to publish their
customer lists because of sales poaching.  it is not theory, but has
happened.

i have had the sales department come to me and ask me to do the bgp and
traceroute research to tell them customer lists of competitors because
the ones they were after were not in the IRR (uu, sprint, ...).  i told
them to foad, and the ceo backed me.

[ and note that backup paths are not very visible in bgp or traceroute ]

> UPADTE.  Note that this is more stringent than showing that the path
> is merely not impossible.
>
> requirements, rather than a set of end goals. This entire "bullet"
> needs to be replaced with a realistic set of requirements concerning
> what can, and cannot, be proven about an AS Path in BGP, and then what
> we can actually require.

the difference between requirements and goals is sufficiently subtle
that you will have to write it up formally to get through to at least
me.

bottom line: when i recieve an update for prefix P with path D C B A, i
want firm assurance that A passed P to B, B to C, C to D, and D to me.
firm, verifiable, assurance.

that some database says that *some* prefixes are allowed from A to B to
C to D to me does not mean *all* are.  there are vast differences in how
different prefixes are handled by each hop on the route.  think peer,
provider, customer relationships.

> traffic sent to that destination will traverse the path listed?

no, see security section.  locking down the data plane is the next high
mountain.  one at a time.

of course if you have a solution which locks down both the control plane
and the data plane, i *extremely eagerly* await your i-d.

> Does receiving an update prove that all destinations listed are
> reachable along the path listed? Does receiving an update prove that
> every AS along that path has agreed to forward traffic transmitted to
> the destination indicated?

yes, agreed to.  of course, we can not yet guarantee that they do not
have an accidental packet-based acl en route, see security section on
data plane vs control plane.  [ i had this bug this last week, a packet
acl in path.  nasty.  eagerly seeking prevention.  send i-d. ]

> 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

tunable, i hope.  i am not much worried about my research prefixes being
replayed.  root name servers may be.

> requirements of BGP security, and should NOT be adopted as a WG

opinions may differ.  you and steve kent had your time in a wg which
went nowhere for years.  let's try not to repeat old arguments and let's
move forward.  thanks.

i will be in your area 8-12 feb.  glad to chat face to face.

randy