Subject: [sidr] Comments on draft-sidr-origin-ops-00

From: Maureen Stillman <[email-masked]>
Date: Sat, 8 Jan 2011 14:29:16 -0600

This is an important document.

I have 2 comments, 2 nits, one question and a comparison of this draft with
draft-sidr-pfx-validate section 6 called "deployment considerations".  I
have reviewed Section 5 of draft-sidr- origin-ops only.

Comment 1) The validation state terminology used in this draft is not
consistent with the terminology of draft-sidr-pfx-validate.  That draft uses
states: valid, invalid, not found, whereas this draft uses states: valid,
invalid, unknown.  Do we want these to be consistent across i-ds?  The 3
states are defined in draft-sidr-pfx-validate but are not defined here.  We
should either define them or point to the definition in
draft-sidr-pfx-validate where they are defined.  I will refer to this as
state "not found" in the remainder of my comments.

Comment 2) Some suggested text below for the opening of section 5.

Section 5. Routing Policy

Background

Currently, the origin status information is not verified.  With the
incremental deployment of RPKI, we will transition to origin validation
comprised of three states: valid, invalid and not found [see
draft-sidr-pfx-validate].  We specify a relative preference associated with
each state as follows:

Announcements with valid origins SHOULD be preferred over those with
*not found* or invalid origins.

Announcements with *not found* origin SHOULD be preferred over those
with invalid origins.

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

During the RPKI transition period, relative preference is introduced to
manage the uncertainty associated with a system in flux.  As the RPKI
transition moves forward, the number of origin validations with state "not
found" will decrease.

Nits:

Section 5. Routing Policy

1) Reasonable application of local policy should be designed eliminate
the threat of unroutability of prefixes due to ill-advised or
   incorrect certification policies.

Suggestion:

Reasonable application of local policy should be designed *to*
eliminate the threat of unroutability of prefixes due to ill-advised
or
   incorrect certification policies.

2) As origin validation will be rolled out over years coverage will be
spotty for a long time.  Hence a normal operator's policy should not
   be overly strict, perhaps preferring valid announcements and giving
very low preference, but still using, invalid announcements.

Suggestion:
As origin validation will be rolled out *incrementally* coverage will
be *incomplete* for a long time.  Hence an *word deleted* operator's
policy
should not be overly strict, perhaps preferring valid announcements,
*attaching a lower preference to but still using, not found
announcements*
and giving very low preference, but still using, invalid announcements.

I deleted the word "normal" since I don't know what normal is.  I
think you need to point out here that they will use all three, valid,
invalid
and not found announcement.  For some reason it is missing from this
paragraph but is correctly included in the list below.

Question:

I'm not sure I understand this.

"Reasonable application of local policy should be designed *to*
eliminate the threat of unroutability of prefixes due to ill-advised
or
incorrect certification policies."

What is ill-advised as opposed to incorrect?  Does ill-advised means
one kind of error and incorrect another?
If they are really one problem, then just use one term.

Comparison of draft-sidr-pfx-validate section 6 called "deployment
considerations":

I'm confused by the relationship of this draft to draft-sidr-pfx-validate
section 6 called "deployment considerations". Is this
the operational section and therefore should
draft-sidr-pfx-validatereference draft-sidr-origin-ops? The deployment
guidance is not
the same in sidr-pfx-validate as it is in sidr-origin-ops in the sense that
there are no SHOULDs or MUSTs. The deployment considerations
in sidr-pfx-validate are just advice. Here is the specific text from
draft-sidr-pfx-validate:

6. Deployment Considerations

"Once a route is received from an EBGP peer it is categorized
   according the procedure given in section 2.  Subsequently, routing
   policy as discussed in section 3
<http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-00#section-3>
can be used to take action based on
   the validation state.

   Policies which could be implemented include filtering routes based on
   validation state (for example, rejecting all "invalid" routes) or
   adjusting a route's degree of preference in the selection algorithm
   based on its validation state.  The latter could be accomplished by
   adjusting the value of such attributes as LOCAL_PREF.

   In some cases (particularly when the selection algorithm is
   influenced by the adjustment of a route property that is not
   propagated into IBGP) it could be necessary for routing correctness
   to propagate the validation state to the IBGP peer.  This can be
   accomplished on the sending side by setting a community or extended
   community based on the validation state, and on the receiving side by
   matching the (extended) community and setting the validation state."

Maureen

---

From: Randy Bush <[email-masked]>
Date: Sun, 09 Jan 2011 06:54:52 +0900

thank you, thank you, thank you, for your review.

> consistent with the terminology of draft-sidr-pfx-validate.  That
> draft uses states: valid, invalid, not found, whereas this draft uses
> states: valid, invalid, unknown.  Do we want these to be consistent
> across i-ds?  The 3 states are defined in draft-sidr-pfx-validate but
> are not defined here.  We should either define them or point to the
> definition in draft-sidr-pfx-validate where they are defined.

thanks.  will do.  are you happy with "not found?"  i have had to sit
through meetings with a bunch of folk discussing this until i had to
leave the room, and definitely have lost any opinion i might have ever
had on the subject.

> I will refer to this as state "not found" in the remainder of my
> comments.

whack me now, as i will make the change after more coffee.

> incremental deployment of RPKI, we will transition to origin
> validation comprised of three states: valid, invalid and not found
> [see draft-sidr-pfx-validate].  We specify a relative preference
> associated with each state as follows:

i am thinking of softening to s/We specify/In the absense of other
designed policy, we recommend/

> During the RPKI transition period, relative preference is introduced
> to manage the uncertainty associated with a system in flux.  As the
> RPKI transition moves forward, the number of origin validations with
> state "not found" will decrease.

thanks

> or incorrect certification policies.

thanks

>    spotty for a long time.  Hence a normal operator's policy should
>    not be overly strict, perhaps preferring valid announcements and
>    giving very low preference, but still using, invalid announcements.
> 
> Suggestion:

> policy should not be overly strict, perhaps preferring valid
> announcements, *attaching a lower preference to but still using, not
> found announcements* and giving very low preference, but still using,
> invalid announcements.
> 
> invalid and not found announcement.  For some reason it is missing
> from this paragraph but is correctly included in the list below.

i pretty much agree with all this.  but let me explain my weaseling and
'normal.'  in the back of my mind, i have operators who do weird things
such as security research, monitoring of the state of the validation
world, ... who may do strange things such as prefer invalid.  perhaps
i should not be weaseling about that and stick to vanilla, chocolate,
and strawberry?

> or incorrect certification policies."
> 
> one kind of error and incorrect another?  If they are really one
> problem, then just use one term.

two problems.  one is incorrect, erroneous, ...  another is the set of
issues devolving from the x.509 base requiring altrustic action by a
chain of organizations.  a significant number of operators, including me
on odd days of the week, are extremely worried about ICANN, RIR, ...
policies with regard to the RPKI.  think things such as legacy space,
RIR 'customers' in conflict with the RIR, ...

> I'm confused by the relationship of this draft to
> draft-sidr-pfx-validate section 6 called "deployment considerations".
> Is this the operational section and therefore should
> draft-sidr-pfx-validate reference draft-sidr-origin-ops?

probably a reference from pfx-validate would be good.  i'll have a talk
with the authors :)

> The deployment guidance is not the same in sidr-pfx-validate as it is
> in sidr-origin-ops in the sense that there are no SHOULDs or
> MUSTs. The deployment considerations in sidr-pfx-validate are just
> advice. Here is the specific text from draft-sidr-pfx-validate:
> 
>    can be used to take action based on the validation state.
> 
>    community based on the validation state, and on the receiving side
>    by matching the (extended) community and setting the validation
>    state."

i am not sure if this conflicts with or even overlays origin-ops.  it is
not suggesting policy, merely discussing mechanisms.  clue bat please.

and thanks again!

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 09 Jan 2011 07:24:46 +0900

> [see draft-sidr-pfx-validate].

hmmmm.  formally, currently the origin status information is Not Found.

randy

---

From: Maureen Stillman <[email-masked]>
Date: Sun, 9 Jan 2011 20:19:38 -0600

See inline replies indicated with *** below.

> leave the room, and definitely have lost any opinion i might have ever

*** I don't care which is used as long as it is the same in all internet
drafts.

> probably a reference from pfx-validate would be good.  i'll have a talk

*** Agree.

> >    <http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-00#section-3
> >

**** Well, frankly I think your text is just perfect and I prefer it to what
is in the first paragraph of this deployment considerations section.  (I'm
ignoring the second paragraph for this discussion BTW.)  By the use of the
word SHOULD instead of MUST along with the ranking of the relative
preference, you convey a strong sense of what the best practice is without
mandating it.  I think this is exactly the right way to do it.  Notice above
how they talk about throwing information away as an example "(for example,
rejecting all invalid routes)", but your text  points out why you might not
want to do this in case there is some problem/error.  The relative
preference guidelines are a very clever way of handling this state
information and I was convinced it was the best way to do it after reading
your draft.

As to whether or not the text (first paragraph above) conflicts or overlays
what you have written:

Since you did not use the word MUST, it does not conflict with it because
you allow anything.  They allow anything as well because they neither used
MUST nor SHOULD.   However, if your guidelines are taken (meaning the
SHOULDs), I believe your guidelines are a subset of what is recommended
above.  The important point is that your recommendations are more specific
and I feel like I have a better idea of what to do with the state
information and the advice is both sound and clever.

This is why I like what you wrote and think it should be referenced in this
section of draft-sidr-pfx-validate so they don't miss it.

Maureen