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

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

On 10/14/15, 7:20 PM, "Sriram, Kotikalapudi"
<[e-mail]> wrote:

>>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.
>
>"unacceptable to sign updates that it can't verify" -- I don't read that
>in Section 6.4.

WG] I interpreted it that way based on 6.4.2. More about that below.
>
>>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.
>
>The AS that you named Randy could be a bad actor,
>and may have changed the AS path segment before it
>(dropped some ASes, reduced AS prepends, etc.).
>Imagine Rob receives another update for the same NLRI that is completely
>unsigned,
>and it has a path via Wes, Chris, and Jeff.
>Let us say both updates pass origin validation.
>Should Rob trust the partially-singed update via Randy, Sandy, Chris, and
> Matt,
>or should he trust the completely unsigned latter update?
>If Rob gives priority to partially-signed path over completely unsigned
>path,
>there is potential for trouble (as in the example above).
>Then what is the use of partially signed updates?

WG] I understand that. I think you're missing the distinction I'm making
between the signed and unsigned parts of the update. In this partial-sign
mode, the way I expect it would work to be at all useful is that any
policy based on the trust of signed updates would only apply to the
portion that is signed, not the entire path. I can't see a blanket trust
of a partially signed route as a binary thing such that you could
automatically prefer partial sign over unsigned, and so your attack vector
is overly simplistic. The partial signing only matters if you care about
the actual data that is being protected inside the signed part. I might
not care that I can't explicitly verify that the AS path started at your
house, then went through Joe's Bait Shop and WISP before connecting to
Randy. But I might care that I can explicitly verify that it went from
Randy to Sandy to Chris to Matt without any unplanned excursions through
Alice or Bob.
As I said, the logic starts getting difficult from a route policy
perspective, but I was trying to point out that the existing text seems to
say that a partially signed update (one that originates unsigned and is
later signed from mid-path to end) is somehow implying a level of trust on
the unsigned portion that doesn't exist. I think the reality is that
partially signed updates would require some additional changes in the
protocol to make that useful, and a significant amount of additional logic
to make it work in policy-land, which may not be worth the effort, but
saying that we don't want to protect the BGPSec-capable part of the path
because we can't protect the preceding part of the path that isn't BGPSec
capable seems circular logic to me.

Wes


________________________________

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.