Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

["George, Wes" <[e-mail]>]

Gave this a review, and stumbled across an issue that may not necessarily
be gating to this draft, but should probably be addressed in some other
drafts.

Regarding this text in 4.2:
"Additionally, BGPsec requires that all BGPsec speakers will support
   4-byte AS Numbers [RFC6793]. This is because the co-existence
   strategy for 4-byte AS numbers and legacy 2-byte AS speakers that
   gives special meaning to AS 23456 is incompatible with the security
   the security properties that BGPsec seeks to provide."

Nit: "the security" appears to be duplicated.

Substantive: I had to think through this for a bit to make sure I
understood why this is true beyond the obvious problem of AS23456 not
being unique. I think we need some additional words explaining why, though
I am not sure if it belongs here, in the protocol draft, or in sriram's
design-choices doc (7.6 is very thin on explanation). I think that this is
a specific corner case for the more generic case of incremental
deployment, where a given path has some routers/ASNs that support BGPSec
and some that do not, and as far as I can tell, incremental deployment
isn't really discussed as a concept beyond the [non]negotiation of support
between peers.

When a BGPSec-capable router sends updates to a non-capable peer, it
strips the BGPSEC_Path attribute from any BGPSec-protected routes it is
propagating and announces a regular AS_PATH, and therefore any protection
beyond that point is lost.
Section 4.2 of the protocol doc says that if a BGPSec-capable router
receives updates from a non-BGPSec peer, it will not sign those updates
when propagating them to other BGPSec-capable peers. As a result, that
route's path will not be protected at all. However, I couldn't find that
particular set of interactions discussed in any of the documents in the
context of incremental deployment, and what it can and cannot do to
protect different route announcements.

In other words, BGPSec supports securing the path when:
- All routers end to end support BGPSec, which results in the entire path
being protected.
- The originating router and one or more contiguous routers (ASNs) in the
downstream path support BGPSec, but one or more routers before the route's
final destination do not support it. This results in the BGPSec signatures
being stripped and falling back to insecure mode beyond the last
contiguous BGPSec-capable router, but still provides partial protection
through the portion of the path that is BGPSec-capable. This is true even
when a gap of one or more BGPSec-incapable routers exists in the middle,
followed by additional BGPSec-capable routers, as only the first part will
be secured.

BGPSec does *not* support securing the path even partially when:
- The originating router and one or more routers in the downstream path do
not support BGPSec, but send the update to router(s) that do support
BGPSec.
I.e. There is no model in BGPSec for updates that have [unsigned AS_PATH
of one or more ASNs] + [Signed BGPSec_Path] of one or more additional ASNs
to at least secure the part of the path where BGPSec is supported.
So you can grow BGPSec's chain of protection from origin to "middle" and
gain some incremental benefit across the part of the path that supports
BGPSec, but you cannot grow BGPSec's chain of protection from "middle" to
end and gain the same incremental benefit, even in the case where only the
originating router doesn't support BGPSec but the rest of the path does. I
think I understand the reasons why we chose not to allow this case, but I
don't know that this is discussed anywhere in these terms. There is a
discussion in 6.4 of Sriram's design-choices doc, but I think it's
incomplete since it only discusses it in terms of it being unacceptable to
sign updates that it can't verify. IMO there's a difference between
signing an unsigned update and carrying unsigned updates alongside signed
ones so that it is clear which part of the path is rigorously protected vs
not. Put differently: "I have no idea whether the people before Randy were
telling the truth, but I can assert that Randy, Sandy, Chris, Matt, and
Rob all verifiably told the truth about their part of the path when they
sent the route to me." I think maybe that has some value in an incremental
model, but if it doesn't (or is sufficiently difficult to implement as to
negate the potential benefit), we should explain why.

Thanks,

Wes



On 10/7/15, 11:32 AM, "sidr on behalf of Chris Morrow"
<[e-mail] on behalf of [e-mail]> wrote:

>
>Howdy WG folks,
>Please consider this your warning/notice that the WGLC has been started
>for:
>
>  draft-ietf-sidr-bgpsec-overview
>
>Abstract:
>  "This document provides an overview of a security extension to the
>   Border Gateway Protocol (BGP) referred to as BGPsec.  BGPsec improves
>   security for BGP routing."
>
>Please give this a read, send comments if there are any, and let us
>know if this is prepared for publication request.
>
>Thanks!
>
>-chris
>co-chair
>
>_______________________________________________
>sidr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sidr


________________________________

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.