Subject: [sidr] [fixed] Confirming that the last interim reflects working group consensus

From: Matthew Lepinski <[email-masked]>
Date: Tue, 9 Oct 2012 23:36:05 -0400

Note: My apologies for the previous, incomplete, email. I accidently hit
"Send" before the message was complete.

At the interim meeting in Amsterdam, we had a discussion on open issues in
draft-ietf-sidr-bgpsec-protocol-05.
Here is a link to the slides that I presented at that meeting. (
http://www.ietf.org/proceedings/interim/2012/09/29/sidr/slides/slides-interim-2012-sidr-6-1.pdf
)

I would like to confirm on the list that the discussions at the last
interim reflect the consensus of the working group.
In this message, I list for each open issue, my understanding of the sense
of the room in Amsterdam. If you believe that for any of these issues that
I may be misunderstanding the consensus of the working group, please start
a discussion on the list as soon as possible. I am currently working on the
-06 version of the protocol draft, therefore, if you have an objection to
anything in this message, please raise it promptly.

--------------------------------

1.1. In referring to the data that is typically carried in the AS_PATH
attribute, I will a phrase similar to "The sequence of ASes through which
an update passes".

1.2. With regards to transport security, the document will specify "SHOULD"
use transport security to protect BGP sessions. However, the document will
NOT specify (as either a MUST or a SHOULD) and specific transport security
mechanism.

1.3. There is no information in the current Editor's Notes that is worth
retaining in future versions of the document

2.1. The document will recommend that if there is a failure to negotiate
BGPSEC in a session with a peer, the BGP-speaker should fall back to BGP-4
without BGPSEC (instead of closing the session).

2.2. Unless someone comes to the list with a use-case for including SAFI in
the BGPSEC capability advertisement, I will remove SAFI from the BGPSEC
capability advertisement.

2.3. BGPSEC support and 4-byte ASN support are negotiated separately.
However, the document will explicitly state that if 4-byte ASN support is
not negotiated, then implementations shall consider BGPSEC to have not been
negotiated.

2.4. The document should specify two separate BGP considerations: one for
receiving BGPSEC, and one for sending of BGPSEC.

3.1. I will shorten the name of the BGPSEC_PATH_SIGNATURES attribute to
BGPSEC_PATH attribute.

3.2. BGPSEC will not put Router_ID on the wire as part of the BGPSEC_PATH
attribute.

3.3. My impression of the sense of the room in Amsterdam was that a
majority of people were leaning towards removing the Additional_Info field
form the BGPSEC_PATH attribute. However, several individuals spoke in favor
of improving Additional_Info to be a more general extension mechanism. In
the absence of discussion on the list, I will remove Additional_Info.
However, I can see both sides of this issues and so I would be happy to see
productive discussion of this on the list.

3.4. After discussion at the interim,  I believe there is no issue here. I
may add another pointer to the ops document if I can find a useful place to
do so.

3.5. I will make sure the document is consistent throughout on the the
issue of length fields. All length fields will include octets used to
express the length itself.

4.1. When originating an update message within an AS. Whenever BGPSEC is
negotiated on the i-BGP session, updates sent in this will be sent with a
null BGPSEC_PATH attribute instead of a AS_PATH

5.1. I will change the names of the validation states to be "Valid" and
"Not Valid". For now I am going to stay with two validation states. If you
have a good use-case for three validation states, please bring it to the
list.

5.2. There was no resolution to the issue of error handling at the interim.
The options seem to be: (1) Normative reference to 4271; (2) Normative
reference to the IDR error-handling draft; or (3) We pick a particular
mechanism for error handling such as "treat as withdrawal", "drop session",
or "drop update".
Note: This is an area where guidance from the chairs would be very useful
to the document editor!

5.3. The issue of deferred validation seemed to be a rat hole we want to
avoid. The next version of the document will have less text on deferred
validation. (In particular phrases like "as soon as possible" seem not to
be helpful). The working group chairs will help the document authors get
some implementer eyes on the -06 version of the document. If we get
feedback that there is additional guidance on deferment that would be
useful, we can always add something after Atlanta.

5.4.  I will shrink the text on edge validation by combining the 2nd and
3rd sentence shown on the slide. In particular, I will avoid the phrase
"MAY be conveyed via iBGP" and will instead go with something like "MAY be
conveyed via some mechanism".

5.5. The protocol document will be silent on the issue of using the
validation state. This type of issue will be left entirely to the
bgpsec-ops document

5.6. I will add text to the document specifying that when RPKI state
changes the router will re-run policy on all affected updates. I will look
to 4271 to see if I can find any guidance in writing this text on
re-evaluation of received updates.

5.7. I believe that a normative reference to rpki-rtr-keys draft. It was
not clear to me whether an informative reference to rpki-rtr-keys is
needed. However, based on discussion in Amsterdam, it seems that an
informative reference to rpki-rtr-keys might be helpful.

---

From: Danny McPherson <[email-masked]>
Date: Thu, 11 Oct 2012 09:51:19 -0400

On Oct 9, 2012, at 11:36 PM, Matthew Lepinski wrote:
> 
> I would like to confirm on the list that the discussions at the last interim reflect the consensus of the working group. 
> In this message, I list for each open issue, my understanding of the sense of the room in Amsterdam. If you believe that for any of these issues that I may be misunderstanding the consensus of the working group, please start a discussion on the list as soon as possible. I am currently working on the -06 version of the protocol draft, therefore, if you have an objection to anything in this message, please raise it promptly.

While I have no problem with this reflecting what occurred at the interim meeting, I again don't think we can reach any sort of closure on any of the bgpsec-proto work until the Threats and subsequent Requirements documents are closed.  

If the WG believes we don't need or should ignore those, then I'd really like to just state that that's the case and continue as if they don't matter or simply stop wasting cycles on them.

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Oct 2012 09:58:13 -0400

> While I have no problem with this reflecting what occurred at the interim meeting, I again don't think we can reach any sort of closure on any of the bgpsec-proto work until the Threats and subsequ…

i had thought there was agreement at the last interim that
threats/requirements needed to get baked before the protocol doc move
to the next step in the process.

---

From: Danny McPherson <[email-masked]>
Date: Thu, 11 Oct 2012 10:59:43 -0400

> to the next step in the process.

While I am happy to hear this, it's not clear to me from the proceedings available, can you please provide a pointer?

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Oct 2012 12:12:06 -0400

> While I am happy to hear this, it's not clear to me from the proceedings available, can you please provide a pointer?

sadly I can't find the notes on the interwebs... I'll see if we/chairs
forgot to post them, or my search-foo with webcrawler is crap.

I do note that there's a new revision ('new' as of 9/14-ish?) of threats:
<http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats>

requirements is still june-only:
<http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs>

Did you get a chance (I think you had some questions/comments/etc
outstanding) to review -threats since 9/14?

-chris

---

From: Arturo Servin <[email-masked]>
Date: Thu, 11 Oct 2012 14:24:51 -0200

Chris,

	I think that you and Sandy mentioned that
draft-ietf-sidr-bgpsec-threats and draft-ietf-sidr-bgpsec-threats should
be done before
draft-ietf-sidr-bgpsec-protocol but it was just by email, I believe.

http://www.ietf.org/mail-archive/web/sidr/current/msg05078.html
http://www.ietf.org/mail-archive/web/sidr/current/msg05080.html

	I was not in the interim, so I do not know if you discussed the issue
there again.

Regards,
as

On 11/10/2012 14:12, Christopher Morrow wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 11 Oct 2012 14:06:51 -0400

> 	I was not in the interim, so I do not know if you discussed the issue

fwiw, I was at the interim, and I do recall the comment being made.  

That said (and at the risk of stating the obvious), can we not agree that the protocol draft will almost certainly need changes and/or an overhaul depending on the scale of the changes that may be coming to the threats and reqs drafts?  I'm just thinking that if we are going to continue to pursue those drafts as prerequisites, then iterating over and polishing their derivative work (the protocol draft) now seems like it may yield text that becomes obsoleted by those prerequisites, right?

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 12 Oct 2012 10:13:06 -0400

> fwiw, I was at the interim, and I do recall the comment being made.

at least I wasn't misremembering. (and the notes were posted by sandy a bit ago)

> That said (and at the risk of stating the obvious), can we not agree that the protocol draft will almost certainly need changes and/or an overhaul depending on the scale of the changes that may be…

protocol may, indeed, require changes, or not... read threats to make
sure it's ok and we can concentrate on the requirements doc now? :)

I suppose we'll send a more official 'read the threats doc, kthxbi'
today as a reminder.

-chris