Subject: [sidr] WGLC for draft-ietf-sidr-pfx-validate-00

From: Sandra Murphy <[email-masked]>
Date: Thu, 18 Nov 2010 04:23:45 -0500 (EST)

(OK, so there *is* another one, making lucky 13.)

Randy Bush has requested a WG LC for draft "BGP Prefix Origin
Validation"

The document and the draft version history are available at
http://tools.ietf.org/wg/sidr/draft-ietf-sidr-pfx-validate.

The Last Call will end Thu, 2 Dec 2010 (AOE).

As usual, please address all comments to the WG mailing list, and
please be clear in your comments to this last call if you are
supporting the document's submission to the IESG or if you are
opposed. If you are opposed, please indicate why.

--Sandy, speaking with wg chair cap on

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Nov 2010 10:32:31 +0100

> http://tools.ietf.org/wg/sidr/draft-ietf-sidr-pfx-validate.

strangely enough, i support this one too

randy

---

From: Miya Kohno <[email-masked]>
Date: Thu, 18 Nov 2010 17:39:40 +0800

I support this document progressing. Miya

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Sandra Murphy
> Sent: Thursday, November 18, 2010 6:24 PM
> To: [email-masked]
> Subject: [sidr] WGLC for draft-ietf-sidr-pfx-validate-00
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 18 Nov 2010 04:49:15 -0500 (EST)

Looks like I need to say:

Support on wg calls from authors of the documents under consideration is 
essentially a no-op for my determination of consensus.  I consider having 
authored a document sufficient indication of support.

(Note that this means that adding a whole bunch of co-authors could leave 
a draft without anyone to stand and cheer when needed.)

--Sandy

---

From: George Michaelson <[email-masked]>
Date: Thu, 18 Nov 2010 11:07:22 +0100

On 18/11/2010, at 10:49 AM, Sandra Murphy wrote:

> Support on wg calls from authors of the documents under consideration is essentially a no-op for my determination of consensus.  I consider having authored a document sufficient indication of support.
> 
> (Note that this means that adding a whole bunch of co-authors could leave a draft without anyone to stand and cheer when needed.)
> 
> --Sandy
> 

Then please note my co-authorship of keyroll, repos-struct, res-certs, provisioning, roa-validation, ta and adjust accordingly.

And accept my apologies for a faux pas

-george

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 18 Nov 2010 05:24:35 -0500 (EST)

Which part of "no-op" did you interpret as indicating a faux pas?

Just trying to help people avoid sending more mail than necessary.

Tho' since people seem to be optimizing by aggregation there probably 
won't be much overall reduction in email.

There's no intent to indicate a faux pas in that observation, either.

--Sandy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 19 Nov 2010 01:20:27 +1100

> opposed. If you are opposed, please indicate why.

I don't think this document is ready to head to the IESG. 

By and large I agree with the observations and recommendations in this document, but I don;t believe that this is ready for the IESG. More wordsmithing for clarity and consistency is requires in my view (see below)

Also, one statement struck me as needing further commentary:

Section 5. Routing Policy

   Announcements with invalid origins MAY be used, but SHOULD be less
   preferred than those with valid or unknown.

Here I agree with the sentiment in terms of the relativity to valid or unknown, but I am worried about the MAY statement here, and I would like the document to explain this further.

For example, a simple reading of the document leads one to believe that all announcements MAY still be accepted according to the routing policy selection allowed in section 5, yet if that were the case then the ability of origin validation to "deal with inadvertent mis-advertisement" is questionable.

I would prefer the document to look at the implication of _why_ a party MAY accept a route that the origination validation framework is leading to a local judgement that the route is invalid. i.e. is it because of missing information in the relying party's local cache, which may bne resolved over time? Is is due to potential circularity of dependence, where parts of the RPKI distributed repository lie behind routes that can only be judged as valid using certs and ROAs found in that repository? 

I would also like to see the security considerations section include a statement to the effect that if a party were to use routes that have an invalid validity state then the ability to detect and filter certain forms of mis-advertisement would in effect be negated.

Back to the wordsmithing and consistency comment, the terminology of unvalidatable origins and unknown origin is used in different sentences - it would be better to use consistent terminology.

It would also be good if the terminology of validity state is consistent - are we talking about "announcements" or "routes"? Are we talking about "valid origin" or "routes that are validated by the RPKI ROA framework"?

So close, but not quite ready for shipping yet in my opinion.

(My apologies - I should've commented earlier on this, but its only a WGLC that leads to these reviews happening for me.)

  thanks,

    Geoff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 22 Nov 2010 19:44:18 -0500

The document does not yet reflect the consensus
generated at the Beijing meeting on treating
updates with AS_SET as having indeterminable origin AS.

Quoting the document:
** Begin quote:
//origin_as is NONE if the AS_PATH begins with a non-trivial
//AS_SET and has no [AS4_]AGGREGATOR attribute.
...
...
4. Route Aggregation

When an UPDATE message carries AGGREGATOR attribute, 
the "UPDATE origin AS number" is set to the value encoded in 
the AGGREGATOR instead of being derived from the AS_PATH attribute.
** End quote.

The above quoted statements in the document contradict said consensus.

Please also see comment: 
http://www.ietf.org/mail-archive/web/sidr/current/msg02203.html 

Thanks,
Sriram

---

From: Pradosh Mohapatra <[email-masked]>
Date: Tue, 30 Nov 2010 09:59:25 -0800

Hi Geoff,

> I would prefer the document to look at the implication of _why_ a party MAY accept a route that the origination validation framework is leading to a local judgement that the route is invalid. i.e.…

I am afraid that any attempt to enumerate the cases where an invalid route MAY be accepted will be incomplete! Rather, could we add a statement to the effect that accepting invalid routes is a pure local matter and should be done with utmost care?

> I would also like to see the security considerations section include a statement to the effect that if a party were to use routes that have an invalid validity state then the ability to detect and…

Ack.

> Back to the wordsmithing and consistency comment, the terminology of unvalidatable origins and unknown origin is used in different sentences - it would be better to use consistent terminology.

Ack.

> It would also be good if the terminology of validity state is consistent - are we talking about "announcements" or "routes"? Are we talking about "valid origin" or "routes that are validated by the…

Ack.

> (My apologies - I should've commented earlier on this, but its only a WGLC that leads to these reviews happening for me.)

No worries, thanks for these. Will be reflected in the next version.

- Pradosh

---

From: Pradosh Mohapatra <[email-masked]>
Date: Tue, 30 Nov 2010 10:02:57 -0800

Hi Sriram,

> The above quoted statements in the document contradict said consensus.

Sorry, I haven't quite followed the WG list and the last IETF happenings due to PTO; so wasn't aware this is the consensus now. I will look around and do the necessary edits for the next revision of the document.

Thanks,
- Pradosh

---

From: Geoff Huston <[email-masked]>
Date: Wed, 1 Dec 2010 15:01:50 +1100

Firstly, I must note that there are a whole ot of use of "may" as distinct from the normative "MAY" in this document, "should" as distinct from the normative "SHOULD", etc.  As thisd is a document intended for a Standards Track, the document needs to be strict about its use of the normative forms of the requirements language as noted in section 1.1 of the document

e.g.: " An AS _may_ originate more than one prefix set.  Thus, multiple prefix sets in the database _may_ contain the same origin AS(es).

> I am afraid that any attempt to enumerate the cases where an invalid route MAY be accepted will be incomplete! Rather, could we add a statement to the effect that accepting invalid routes is a pure…

works for me

  Geoff