Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt

From: Matt Lepinski <[email-masked]>
Date: Tue, 01 Nov 2011 12:59:50 -0400

I have updated the BGPSEC protocol specification.

At the SIDR meeting in Quebec, there was significant discussion about 
how BGPSEC could provide security of the AS-PATH attribute while still 
accommodating the needs of route servers that participate in BGP, but do 
not wish to increase the length of the AS-PATH attribute. The -01 
version of the draft contains  a mechanism (a field called pCount) which 
attempts to address this issue by having route servers create BGPSEC 
signatures without increasing the effective length of the AS-PATH 
attribute. I would greatly appreciate comments on this mechanism and 
whether it adequately addresses the issues raised at the last SIDR 
meeting and subsequently discussed on the list.

There was has also been significant discussion on the SIDR list of the 
"Expire TIme" field in BGPSEC and the associated "Beacon-ing" (that is, 
periodic re-advertisement of a prefix with a new signature and a new 
Expire Time) as a mechanism to address replay attacks (as well as 
attacks where a malicious peer fails to propagate the withdrawal of a 
route). My understanding is that the consensus of  the working group was 
that the current Expire Time mechanism is reasonable as long as 
re-advertisement is only required at the origin AS (and not at 
intermediate ASes). The current -01 version of the draft attempts to 
reflect that consensus.

Finally, there are a number of small editorial changes that I believe 
will improve the clarity of the draft. Thanks again to everyone who has 
reviewed the document, feedback on how the text could be made more 
easily understandable is especially welcome.

- Matt Lepinski

On 10/31/2011 3:38 PM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.
>
> 	Title           : BGPSEC Protocol Specification
> 	Author(s)       : Matthew Lepinski
> 	Filename        : draft-ietf-sidr-bgpsec-protocol-01.txt
> 	Pages           : 28
> 	Date            : 2011-10-31
>
>     This document describes BGPSEC, an extension to the Border Gateway
>     Protocol (BGP) that provides security for the AS-PATH attribute in
>     BGP update messages.  BGPSEC is implemented via a new optional non-
>     transitive BGP path attribute that carries a digital signature
>     produced by each autonomous system on the AS-PATH.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "Danny McPherson" <[email-masked]>
Date: Tue, 1 Nov 2011 14:09:32 -0400 (EDT)

> meeting and subsequently discussed on the list.

If we do this we're disclosing routing topology information that is NOT
disclosed today (i.e., an otherwise transparent route server in the BGP
path).  IIRC, not disclosing new information was an explicit requirement?

> intermediate ASes). The current -01 version of the draft attempts to

Can you provide a pointer to where this was discussed AND consensus was
reached in the WG, I don't recall seeing any consensus and I'm still very
concerned about adding periodic updates and considerable churn to an
otherwise stateful system in order to minimize exposure windows to
multiple hours (or more).

Furthermore, given the systemic and architectural implications of such a
mechanism, I would like to see an explicit consensus call on this item
from the chairs.  I also think this is something that should be consulted
with the IDR WG, as periodic updates ("beacons") are a considerable step
away from the stateful BGP we know today -- and when coupled with single
NLRI-only UPDATES an order of magnitude or larger that require
cryptographic validation of many component elements, it makes me uneasy.

-danny

---

From: Brian Dickson <[email-masked]>
Date: Tue, 1 Nov 2011 14:34:04 -0400

I've read the draft, and find it to be very high quality and very clear.

The one comment I have regarding pCount, is in regards to processing
received pCount=0 announcements.

I believe the concerns regarding "AS-path cheating" to attract
traffic, by using pCount=0, could be addressed with some special
handling.

Basically, when receiving pCount=0 at the top of the stack (most
recent addition, by one's peer), checking the next-hop to ensure it
satisfies "three-routing" requirements, i.e. that the next hop be
something other than the neighbor's IP address, is sufficient.

The only other suggestion is related to the number of signature
blocks. I agree that support for two is needed at a minimum. I am not
entirely sure that restricting it to two is necessary, but haven't
thought through the scenarios here. Perhaps "one or more" rather than
"one or two"?

Has there been any thought to use of a cryptographically signed
"Expire Time" (which can be sent and updated as a
keep-alive/add-time-to-the-meter mechanism), and then having the
blocks refer to the Expire Time by reference (and have the reference
internally by pointer, originally matching a cryptographic hash on the
first received timer, whose pointed-to value gets updated)?

This reduces the "beacon" issue to updating a single value, and limits
the playback to the interval during which the original Expire Time
exists. Newer updates would refer to the latest cryptographic hash of
the last sent Expire Time (update). It becomes a chaining exercise in
a state-ful environment...

Brian

On Tue, Nov 1, 2011 at 12:59 PM, Matt Lepinski <[email-masked]> wrote:
> At the SIDR meeting in Quebec, there was significant discussion about how
> BGPSEC could provide security of the AS-PATH attribute while still
> accommodating the needs of route servers that participate in BGP, but do not
> wish to increase the length of the AS-PATH attribute. The -01 version of the
> draft contains  a mechanism (a field called pCount) which attempts to
> address this issue by having route servers create BGPSEC signatures without
> increasing the effective length of the AS-PATH attribute. I would greatly
> appreciate comments on this mechanism and whether it adequately addresses
> the issues raised at the last SIDR meeting and subsequently discussed on the
> list.
>
> periodic re-advertisement of a prefix with a new signature and a new Expire
> Time) as a mechanism to address replay attacks (as well as attacks where a
> malicious peer fails to propagate the withdrawal of a route). My
> understanding is that the consensus of  the working group was that the
> current Expire Time mechanism is reasonable as long as re-advertisement is
> only required at the origin AS (and not at intermediate ASes). The current
> -01 version of the draft attempts to reflect that consensus.
>
> Finally, there are a number of small editorial changes that I believe will
> improve the clarity of the draft. Thanks again to everyone who has reviewed
> the document, feedback on how the text could be made more easily
> understandable is especially welcome.
>
> - Matt Lepinski
>
>
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Secure Inter-Domain Routing
>> Working Group of the IETF.
>>

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Nov 2011 04:58:34 +0100

> traffic, by using pCount=0, could be addressed with some special

draft-ietf-sidr-bgpsec-ops-01 suggests a knob

   If it is known that a BGPsec neighbor is not a transparent route
   server, and the router provides a knob to disallow a received pCount
   (prepend count, zero for transparent route servers) of zero, that
   knob SHOULD be applied.

randy

---

From: "George, Wes" <[email-masked]>
Date: Fri, 11 Nov 2011 19:52:21 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Matt Lepinski

> The -01
> version of the draft contains a mechanism (a field called pCount)
> which attempts to address this issue by having route servers create
> BGPSEC signatures without increasing the effective length of the AS-
> PATH attribute.

[WEG] where you explain the pCount field in both section 3 and 4.1, you never explicitly state anything about the route-server use case. In those sections, you only discuss the case where this is used to eliminate the need for duplicate signatures in the case of AS-path prepending. I think that section 3's explanation of the field definitely needs a reference to 4.1 and 4.2, and since 4.2 contains a backward reference to 4.1 explaining pCount>1, 4.1 should probably have a corresponding reference to 4.2 for pCount=0. It may also be appropriate to explicitly state in 4.1 that when a node sets the pCount to a value greater than 1, that value MUST correspond to the number of instances of the AS-path being represented in BGP's standard AS/AS4_path attribute.

Some other general comments-
as I noted in my review of the requirements document, I think that it's appropriate to note in this document an explicit requirement for 4-byte ASN support, including any discussion of how to handle 4-byte ASNs, as well as recommend explicit handling for occurrences of AS23456 in the path (eg, because we should be acting on the 4-byte ASN, we should never see the transition ASN in the path, and therefore those updates should always be seen as invalid).

4.2 - AS_SETs are deprecated. You should update your discussion accordingly, with a reference to whatever RFC draft-ietf-idr-deprecate-as-sets-06 became (I'm writing this offline, so I don't have the ability to find the number).

5.1 - Is the algorithm intended to be processed strictly in the order listed? Specifically, both in terms of the items preceded with "first, second, third, finally..." and within the multi-step subsection covering determining if updates are properly formed, it is unclear whether this is simply an arbitrary grammatical list grouping for ease of reading, or if it is an explicitly defined order. I would prefer that it either explicitly states that it requires the order listed (with justification/rationale as appropriate) or to explicitly note that the order is left to the implementation so that optimizations can be made based on the specific implementation. It may also be worth noting the places where there is no dependency between validation steps so that they can be processed in parallel on separate threads (such as when optimizing for multi-core applications). Also, shouldn't there be a reference to the origin validation documents instead of an explanation of how to do origin validation?

Regarding confederations - what if one or more of the confeds is a private ASN? This is maybe a bit more straightforward if you're in the situation where AS1 learns the route originated from a private ASN in confederation, as it could simply originate/sign the route to its ebgp peers directly. It's more complicated (I think...) if the confed ASes are in the middle of the path (that is, the private ASN learns the route from a downstream ASN and then propagates it to the upstream confed peer) because there's not really a way to drop signatures from the middle of the path, yet the private ASNs are going to be stripped out of the BGP update messages as it leaves the confederation. Perhaps this is another case where the pCount should be 0? Is there any other special handling for confed? Alternatively, we may have to explicitly prohibit this setup similar to the way that we did with AS_Set.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Nov 2011 11:40:52 +0800

to two of your comments, in my unpublished edit buffers

draft-ietf-sidr-bgpsec-ops-02

   To prevent exposure of the internals of BGP Confederations [RFC5065],
   a BGPsec speaker which is a Member-AS of a Confederation MUST NOT not
   sign updates sent to another Member-AS of the same Confederation.

draft-ietf-sidr-pfx-validate-04

   An implementation MUST support 4 Octet AS Numbers, [RFC4893].

as our friendly blood-sucking vendors have said, the latter is thought
to be obvious.  but i figured to document it anyway, no harm.

cool?

randy

---

From: "George, Wes" <[email-masked]>
Date: Sat, 12 Nov 2011 00:41:10 -0500

> From: Randy Bush [mailto:[email-masked]]
> Sent: Friday, November 11, 2011 10:41 PM
> To: George, Wes
> Cc: sidr wg list
> Subject: various
>

[WEG] does that mean that routes using confeds as transit ASes cannot participate in BGPSec at all?
(eg if the update path goes:
Origin ASN -> confed AS ($private) -> confed AS ($public) -> eBGP peer)
If that's the case, would be useful to be more explicit about it.

Or do you mean that confed AS1 will not be in the signature chain/AS path and the public ASBR (the external side of the confed) will sign as if it learned the routes directly from the Origin ASN? If it's the latter, you probably need more clarifying text, and that may actually require some text in the protocol definition to cover the special-case handling.

Related: It may be that we have to simply say that Private ASNs can't be BGPSec participants, whether in confeds or otherwise, for many of the same reasons - AFAICT it'd be impossible to build a signature path and then update it downstream to reflect the external AS it gets replaced with.

> to be obvious.  but i figured to document it anyway, no harm.

[WEG] works for me!

Wes

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Nov 2011 14:49:54 +0800

>>    a BGPsec speaker which is a Member-AS of a Confederation MUST NOT

no.  and it does not in any way say that, does it?

> If that's the case, would be useful to be more explicit about it.

the statement attempts to very clearly apply ONLY to two members of the
confed speaking to each other, period.  if it is not clearly restricted
to that case, please say how it could be reworded to more clearly be so
restricted.

( i should be able to differentiate you and shane.  he sends text :)

> Or do you mean that confed AS1 will not be in the signature chain/AS
> path and the public ASBR (the external side of the confed) will sign
> as if it learned the routes directly from the Origin ASN?

if bt AS1 you mean what you call "AS ($private)" above, yes, that is
what is meant.

> If it's the latter, you probably need more clarifying text, and that
> may actually require some text in the protocol definition to cover the
> special-case handling.

why is it needed to cross over into the large space of what is to be
signed?  the point of the bullet is what is NOT to be signed.

> Related: It may be that we have to simply say that Private ASNs can't
> be BGPSec participants

tell that to someone trying to secure some multi-as private network
using rfc 1918 addresses and asns.

randy

---

From: "George, Wes" <[email-masked]>
Date: Sat, 12 Nov 2011 05:18:44 -0500

> ( i should be able to differentiate you and shane.  he sends text :)

[WEG] ouch. Cut a mental midget some slack as he attempts to understand well enough to know if he needs to propose new text. :-)
That's very clear by itself. What was (and is) less clear is how that interacts with the rest of the network. More on that below.
> if bt AS1 you mean what you call "AS ($private)" above, yes, that is
[WEG] ok, given that, I can suggest text to add to what you've already proposed -
"However, signed updates received from BGPSec speakers outside of the confederation (i.e. those transiting the confederation ASes) MUST be passed to the other Member-ASes BGPSec speakers intact. This will allow those speakers to sign updates to their eBGP peers using the confederation identifier ASN and give a complete chain of signatures as if the confederation were a single ASN."

> using rfc 1918 addresses and asns.
[WEG] you know I debated making a clarifying exception to the above case when I wrote this mail, but I figured it'd be clear from the above discussion that I was talking about the application where the routes need to be announced into the DFZ, not the case of using your own TA/private space to secure a completely private network with this machinery.
If you're using Private ASNs either as origin or as transit for something that has to be announced to the rest of the world, today you can do things like replace-AS, remove-private-as, or you can re-originate it from a public ASN (network statements, etc). In this context, Re-origination should work, but I'm thinking that replace-AS/remove-private will not, unless you also strip the signatures for everything behind the ASN you're replacing, and only sign from that point outward. In other words, you can break the chain of signatures and start a new one, but you can't "fix" the existing signatures. Perhaps that's obvious to everyone involved in the implementation, but it was not obvious to me until I thought through it.
Text might take the form of: "If a BGPSec speaker receives updates from another BGPSec speaker with a Private ASN in the path, and is configured to strip those private ASN(s) from updates to its eBGP peers, it MUST also strip any BGPSec signatures contained in that update before signing the update and announcing it to its eBGP peers, even if the eBGP peer is a BGPSec speaker. This is to prevent exposing internal ASNs outside of the network where they are being used."

Wes George

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Nov 2011 18:45:26 +0800

> "However, signed updates received from BGPSec speakers outside of the
> confederation (i.e. those transiting the confederation ASes) MUST be
> passed to the other Member-ASes BGPSec speakers intact.

nope.  you could decide to strip toward one or more confed peers which
are not bgpsec capable.  your routers, your decision, your policy.
don't go there.

the rule was very intentionally precise and simple, two members of the
same confderation must not add sigs toward each other.  

imiho, saying anything more is either adding unnecessary words at best
or opening up large complexity holes at worst.

> [WEG] you know I debated making a clarifying exception to the above

i try to minimize statements that require clarifying exceptions.  they
tend to open primrose paths with no proof of termination.

> I figured it'd be clear from the above discussion

and yet you want to me to go into unnecessary complications not directly
needed given my brutally specific statement?  :)

randy

---

From: "George, Wes" <[email-masked]>
Date: Sat, 12 Nov 2011 07:57:17 -0500

> Sent: Saturday, November 12, 2011 5:45 AM
> To: George, Wes
> Cc: sidr wg list
> Subject: Re: various
>

[WEG] there's no deciding. If the peers are not BGPSec capable, you're already required to strip towards that peer, no exception was made for confed peers. The only available policy decision is whether or not you want the info carried across the confed to other BGPSec capable peers, so maybe make it a SHOULD so that it's configurable, but I think it's incomplete as is.
> or opening up large complexity holes at worst.

[WEG] yes, there's a fine line, but as I've said before, an operational considerations document is where some of these details and their associated primrose paths have to be discussed, because you get into the shades of gray world of operationalizing this stuff. We're not always going to be able to consult you for a ruling on all of the things that you didn't say, and the IETF has no Supreme Court to interpret the "founders" intentions for those left behind.

> and yet you want to me to go into unnecessary complications not
> directly needed given my brutally specific statement?  :)
[WEG] Your brutally specific statement is so specific that it does not mention the second case at all, because it's not about confeds. :-)
Do you or do you not agree that on the transition between private ASN and public, if remove-private is configured, any signatures containing private ASN must be removed even if the eBGP peer is BGPSec capable?

Wes

---

From: Danny McPherson <[email-masked]>
Date: Sat, 12 Nov 2011 09:53:17 -0500

>   sign updates sent to another Member-AS of the same Confederation.

Shouldn't supporting BGPSEC between Member-ASes of confederations be 
a requirement -- not simply ignored and out of scope? 

Particularly because of the manner in which they're used in many networks 
today for regional and topological policy and administrative boundaries?  

also, s/MUST NOT not/MUST NOT/ if it lives...

-danny

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Nov 2011 22:57:56 +0800

> Do you or do you not agree that on the transition between private ASN
> and public, if remove-private is configured, any signatures containing
> private ASN must be removed even if the eBGP peer is BGPSec capable?

with the statement as is, if it is a private asn or a public asn, it is
not signing.

randy

---

From: Brian Dickson <[email-masked]>
Date: Sat, 12 Nov 2011 12:29:05 -0500

In the case of confederations, and presuming BGPSEC is used among the
confederation members,
it should be the case that upon entry to the confederation, the "TO"
ASN of the sender's signature
is the AS Confederation Identifier, i.e. the externally visible ASN as
which the confederation appears
to its eBGP neighbors.

The confederation will, in propagating an eBGP announcement, create an
AS_CONFED_SEQUENCE,
and corresponding signatures.

Removing the signatures and removing the AS_CONFED_SEQUENCE, I
believe, will preserve the
signature validity, since the confederation member sending to a
non-confederation member will add
the AS Confederation Identifier (ASN) to the AS_SEQUENCE, and add its
signature. The AS-path
and signatures over such, will be valid/consistent. I.e., I think it
"just works".

So, I propose the following alternative text:

  To prevent exposure of the internals of BGP Confederations [RFC5065],
  and to comply with the requirement that the AS_SEQUENCE be identical
  to the sequence of ASNs from the Signature-Block, a BGPsec speaker
  which is a Member-AS of a Confederation MUST remove every Signature-
  Segment which corresponds to a unique ASN in the AS_CONFED_SEQUENCE
  prior to the AS_CONFED_SEQUENCE being removed from the AS_PATH,
  and prior to adding its own Signature-Segment to the Signature-Block.

Or, wording to that effect.

Brian

---

From: "George, Wes" <[email-masked]>
Date: Sat, 12 Nov 2011 19:45:50 -0500

> Sent: Saturday, November 12, 2011 9:58 AM
> To: George, Wes
> Cc: sidr wg list
> Subject: Re: various
>

[WEG] sigh. Let me try one more time.
This question is not about confederations so "the statement" is not applicable.
Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one of whom is using a private ASN, announcing routes that must be carried to the DFZ. Make more sense now as to why I'm making the distinction between private and public ASN?

Wes

---

From: Randy Bush <[email-masked]>
Date: Sun, 13 Nov 2011 09:21:35 +0800

> Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one
> of whom is using a private ASN, announcing routes that must be carried
> to the DFZ. Make more sense now as to why I'm making the distinction
> between private and public ASN?

yep.  so we are on a completely separate, though a bit related, subject.
got it.

i need to think.  needs of large 1918 clouds mean you just don't want to
say 1918s don't sign.

randy

---

From: Brian Dickson <[email-masked]>
Date: Sat, 12 Nov 2011 20:29:49 -0500

> Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one of whom is using a private ASN, announcing routes that must be carried to the DFZ. Make more sense now as to why I'm making the…

Should we presume in your example, that the sequence is:

private -> public -> public

I.e. that there is no public ASN before the private ASN, and the route
is originated by the private AS?

I think the answer is something along the lines of, the private AS
announces with its private AS as the origin,
and the upstream public AS has its own trust anchor for assigning its
instances of private AS ROA records.

The public AS, to the outside world, appears to be the real
originator, so the original signature is stripped completely,
and a new signature block created using the public AS's "real" ROA
info and signed as if it really was originated.

Everything works beyond that.

There really cannot be a transitive 1918->non-1918 signature path,
because there cannot be 1918 ROAs with global significance, because of
the AS's non-uniqueness.

BGPsec from the announcer, transitively, can only be done with a
public ASN. 4-byte ASNs are available now, expect demand to increase
with BGPsec, IMHO.

Brian

---

From: Randy Bush <[email-masked]>
Date: Sun, 13 Nov 2011 09:40:43 +0800

> public ASN.

someone is gonna ask for a 1918 cloud and have their own trust anchor

if it connects to the public network, yes, something is gonna have to
get that private stuff off there.  in a separate message, i think it was
you who is proposing a protocol spec change/refinement.  this thread is
about the ops, not protocol, doc.  i am hoping protocol geeks will have
enough coffee soon that they can discuss.

randy

---

From: Brian Dickson <[email-masked]>
Date: Sun, 13 Nov 2011 15:42:38 -0500

On Sat, Nov 12, 2011 at 8:40 PM, Randy Bush <[email-masked]> wrote:
> in a separate message, i think it was

Yep - while it is correct to say, "protocol changes may impact the ops doc",
it isn't terribly useful without specifics. I was providing specifics. Hopefully
some of the folks discussing the ops doc(s) will convey the issues with
the protocol folks.

IMHO, some aspects of ops need to inform the protocol design, rather
than having the protocol docs simply memorialize someone's experimental
design.

Brian