Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

From: Sandra Murphy <[email-masked]>
Date: Tue, 6 Oct 2015 21:31:40 -0400

This conversation seems to have come to a close.

The wg chairs see wg consensus as follows:

The problem is real enough to merit a protocol change.

The change is to cover more raw info in the signatures, rather than signature chaining only, along the lines of
http://www.ietf.org/mail-archive/web/sidr/current/msg07258.html
(see also the new archiving tool https://mailarchive.ietf.org/arch/msg/sidr/sXUj7lgieri0Wrv5PK5u7PfLtxc).

In addition, maintaining ordering was also noted as important to some
http://www.ietf.org/mail-archive/web/sidr/current/msg07261.html
http://www.ietf.org/mail-archive/web/sidr/current/msg07270.html
http://www.ietf.org/mail-archive/web/sidr/current/msg07271.html

The authors of draft-ietf-sidr-bgpsec-protocol-13 are requested to submit a revised version of the draft.

The changes are significant enough that the revised draft will go through a wglc, focussed on the changes for this issue, so shorter than normal.

—Sandy, speaking as one of the wg co-chairs

---

From: Matthew Lepinski <[email-masked]>
Date: Wed, 7 Oct 2015 11:06:40 -0400

Thanks to David for identifying this problem initially and to everyone else
who contributed to this discussion.

I am happy to update the document to reflect the working group consensus.
My goal is to get a revised version of the document to the working group
sometime late next week (e.g. Oct 17).

- Matt Lepinski

On Tue, Oct 6, 2015 at 9:31 PM, Sandra Murphy <[email-masked]> wrote:

> The change is to cover more raw info in the signatures, rather than
> signature chaining only, along the lines of
> (see also the new archiving tool
> https://mailarchive.ietf.org/arch/msg/sidr/sXUj7lgieri0Wrv5PK5u7PfLtxc).
>
> The changes are significant enough that the revised draft will go through
> a wglc, focussed on the changes for this issue, so shorter than normal.
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 16 Oct 2015 16:09:00 +0000

Hi Matt,

A few notes below (one editorial and one substantive).
There is a typo in this sentence (page 11):
In particular, the BGPsec
   attribute SHOULD NOT be removed even in the case where the BGPsec
   update message *has not* been that *has not* successfully validated.
Repeat of 'has not' above. May be the sentence was meant to read as follows?
In particular, the BGPsec
   attribute SHOULD NOT be removed even in the case where the BGPsec
   update message has not been validated (not attempted) or has not been successfully validated.
Substantive comment ....
Looking at this on page 23,
"BGPsec update messages do not contain an AS_PATH attribute.
   Therefore, a BGPsec speaker MUST utilize the AS path information in
   the BGPsec_Path attribute in all cases where it would otherwise use
   the AS path information in the AS_PATH attribute.  The only exception
   to this rule is when AS path information must be updated in order to
   propagate a route to a peer (in which case the BGPsec speaker follows
   the instructions in Section 4<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-13#section-4>)."
What is being said in the second sentence above is not clear.
No exception applies if the peer is BGPsec capable and negotiated BGPsec.
So is the exception for the case when the peer is non-BGPsec?
May the fix is to replace this (current):
"The only exception
   to this rule is when AS path information must be updated in order to
   propagate a route to a peer (in which case the BGPsec speaker follows
   the instructions in Section 4<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-13#section-4>)."
with the following (proposed):
The only exception
   to this rule is when AS path information must be re-formatted to AS_PATH in order to
   propagate a route to a non-BGPsec peer (in which case the BGPsec speaker follows
   the instructions in Section 4.4).
Sriram

---

From: Sandra Murphy <[email-masked]>
Date: Sat, 17 Oct 2015 11:30:59 -0400

speaking as a regular ol’ member

On Oct 16, 2015, at 12:09 PM, Sriram, Kotikalapudi <[email-masked]> wrote:

>    the instructions in Section 4)."
> 
>    the instructions in Section 4)."
> 

I read that sentence differently.

When BGP is propagating a route to a neighbor, it ordinarily appends its AS to the AS_PATH.

The “in all cases” would imply the same would happen in BPGsec, whether the neighbor is bpgsec capable or not.

The exception is that, in the propagating case, BGPsec will instead follow section 4 - which covers bgpsec capable neighbors (embed AS in BGPsec_Path) and bgpsec incapable neighbors (reconstruct AS_PATH).

I think your statement is correct, but I don’t think it is what is meant here.

—Sandy, speaking as a regular ol’ member

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 18 Oct 2015 03:09:47 +0000

Ah, I see. I agree your interpretation is the correct one. So no change is necessary. 
Thank you.

Sriram

________________________________________
From: Sandra Murphy <[email-masked]>
Sent: Saturday, October 17, 2015 11:30 AM
To: Sriram, Kotikalapudi
Cc: Sandra Murphy; Matthew Lepinski; sidr wg list
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-13.txt