Subject: [Gen-art] Gen-ART LC review of draft-ietf-sidr-roa-validation-10.txt

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Apr 2011 00:34:35 +1200

Please see attached review.

---

From: Geoff Huston <[email-masked]>
Date: Sun, 10 Apr 2011 01:13:18 +1000

On 09/04/2011, at 10:34 PM, Brian E Carpenter wrote:

> <draft-ietf-sidr-roa-validation-10-carpenter.txt>

Thanks Brian,

I'm not sure as to the appropriate form of response, but let me respond to the two minor issues you identified in this review (many thanks for the review, by the way)

> 3.  Applying Validation Outcomes to Route Selection
...
>      "valid" is to be preferred over
>      "unknown", which is to be preferred over
>      "invalid".
...
>   It is a matter of local routing policy as to the actions to be
>   undertaken by a routing entity in processing those routes with
>   "unknown" validity states.

you commented that: 

That seems to leave open the possibility that an aggregated route (which
is by definition "unknown") would be rejected. Assuming that the various
separate routes that were aggregated together never reached this particular
router, the result would be a black hole. At the least, it seems that this
should be mentioned, even if it is an intentional possibility.

But the next sentence in the document states:

   Due to considerations of partial use of
   ROAs in heterogeneous environments, such as in the public Internet,
   it is advised that local policy settings should not result in
   "unknown" validity state outcomes being considered as sufficient
   grounds to reject a route outright from further consideration as a
   local "best" route.

Also, given the current proposal in the IDR WG to deprecate the use
of AS Sets (and by implication deprecate the (rarely used if ever)
practice of proxy aggregation, I am unsure of the need to call out 
proxy aggregation in this context.

> 5.  Route Validation Lifetime
>
>   The "lifetime" of a validation outcome refers to the time period
>   during which the original validation outcome can be still applied.
>   The implicit assumption here is that when the validation lifetime
>   expires the routing object should be re-tested for validity.

you commented that:

OK, but shouldn't a previously "valid" route be downgraded to
"unknown" after the lifetime expires and until the validity has
been re-tested?

Not necessarily. When a route is validated, the validation lifetime refers
to the validation time of the EE cert used to sign that ROA. When the
ROA is no longer valid the route should be re-tested for validity. It it
possible that there is another ROA that still validates the route, or in the
absence of the ROA that previously validated the route, the route may 
be considered invalid (i.e. there is an AS 0 ROA still extant that encompasses
this prefix). For this reason the text specifically indicates that the
appropriate action is to retest the route for validity in the context of the
current local cache of valid ROAs.

At this stage I am unsure if changes to the draft are warranted, as
I believe that the issues you highlight here are addressed in the
document as it stands.

regards,

  Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Apr 2011 19:35:45 +1200

> I'm not sure as to the appropriate form of response, but let me respond to the two minor issues you identified in this review (many thanks for the review, by the way)

This is just fine... the gen-art archive is public, so replying here
is on the record.

>    grounds to reject a route outright from further consideration as a

Yes, indeed, and all I was thinking of was adding a sentence here saying
that the "unknown" category might include aggregates. It's a direct implication
of the earlier text but I tend to assume that not all readers will
notice all implications.

> proxy aggregation in this context.

I won't get into that debate ;-)

> current local cache of valid ROAs.

Yes, but I have no sense of the timing - would the time taken to revalidate
the route leave a long enough gap for some kind of security exposure while
an expired route was still marked as valid? Maybe I am worrying about
nothing.

> I believe that the issues you highlight here are addressed in the

Sure, these were minor comments, unless your shepherd feels differently.

   Brian

---

From: Chris Morrow <[email-masked]>
Date: Sun, 10 Apr 2011 14:57:25 +0200

I hate to intrude, but...

> I won't get into that debate ;-)

Brian,
Is this not 'proxy aggregation' but something like just announcing an
aggregate where you don't actually hold the supernet as an allocated
prefix to you?

For example:
  206.44.0.0/16

being held up for a customer by their ISP... ideally the ISP has a ROA
for this, but today it's a handshake agreement with a former employee
(on both sides I would bet)

-chris

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 11 Apr 2011 22:15:59 -0400 (Eastern Daylight Time)

> of the earlier text but I tend to assume that not all readers will

I don't know that I quite understand your objection in the first place. 
Aggregates are not *by definition* "unknown" unless they are proxy 
aggregates.  Normal aggreages exist and are valid.  An ISP with a /16 who 
suballocates /18s to customers and then propogates only the aggregate /16 
can issue a ROA for the /16 itself and make the aggregate valid.

And proxy aggregates implies AS_SETs which as Geoff notes are being 
deprecated and are formally ruled out of bounds in the sidr work.

And "unknown" routes don't necessarily result in a blackhole.  If 
"unknown" routes are acceptable by local policy, the traffic will get 
through.  The only way a definition of "unknown" would result in a 
blackhole would be if the local policy was so strict that it would reject 
its only route to a prefix.  Local shoot-foot policy decisions can occur 
already for many different reasons, this is nothing new.

> an expired route was still marked as valid? Maybe I am worrying about

Information necessary to revalidate the route should be available locally, 
and so should take little time.

> Sure, these were minor comments, unless your shepherd feels differently.

I am not convinced that changes to the draft are necessary here.

>   Brian

--Sandy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Apr 2011 19:24:26 +1200

On 2011-04-12 14:15, Sandra Murphy wrote:
>>> I'm not sure as to the appropriate form of response, but let me
>>> respond to the two minor issues you identified in this review (many
>>> thanks for the review, by the way)
>>
> aggregates.  Normal aggreages exist and are valid.  An ISP with a /16
> who suballocates /18s to customers and then propogates only the
> aggregate /16 can issue a ROA for the /16 itself and make the aggregate
> valid.
> 

That was new to me, but in any case I was not raising an objection.
I was only suggesting that implementors reading the document might
miss this point when planning their policy. If they intend to respect
proxy aggregates (which is their choice whatever the IETF says) they
would need to allow for this rather than choosing to automatically
reject all 'unknown'.

> blackhole would be if the local policy was so strict that it would
> reject its only route to a prefix.  Local shoot-foot policy decisions
> can occur already for many different reasons, this is nothing new.

Indeed. But again: my point was that readers might not think through
all the implications, so give them a warning. "Note that as indicated
above, "unknown" routes may include proxy aggregates."

> Information necessary to revalidate the route should be available
> locally, and so should take little time.

OK, but that was not immediately obvious to me.

> I am not convinced that changes to the draft are necessary here.

That's your call.

   Brian