Re: BGPMON Alert Questions

[Mark Tinka <mark.tinka () seacom mu>]

On Thursday, April 10, 2014 12:30:51 PM Randy Bush wrote:

> as folk start to roll out rejection of invalids, we might
> think about how we report problems with folk registering
> inadequate roas, covering their customers, covering
> their deaggs (maybe deaggs get what they deserve), etc. 
> if they are not clued enough to generate prudent roas,
> they will not be clued enough to generate ghostbusters
> (and neither ripe's nor apnic's software supports gbrs
> today).

Agree.

If you are clued enough to generate ROA's, you are clued 
enough to generate ROA's for the de-aggregates (or, at 
least, respond to the errors that indicate that). But the 
reverse is also true.

It would be useful to use BGPmon's free RPKI validation 
feature, which e-mails you, incessantly, about validation 
failures due to un-ROA'd de-aggregates.

It will also help if the CA's run by the RIR's support 
prefix length definitions. For the Africa region, AFRINIC 
currently do not, meaning every de-aggregate needs to be 
ROA'd. It's planned, though...

> if my customer can not reach foo's customer, will foo's
> rir be willing to help?  if foo's customer can not reach
> mine, how to let foo know who to call/write?  do we need
> conventions?

This was one of the questions I've always pondered, and if 
you recall, was part of our panel discussion on the subject 
in Xi'an last year.

I think it would be helpful if CA delegation was supported 
by RIR's, and supported well, so that customers can deal 
with their ISP's CA instead of having to deal with the RIR 
instead (particularly for situations where RIR's aren't 24/7 
shops).

On the monitoring side, it will be critical for ISP's to 
provide looking glasses that customers can use to verify the 
delta between what has been ROA'd and what has been 
announced/rejected, particularly in the case of un-ROA'd de-
aggregates.

Mark.

Attachment: signature.asc
Description: This is a digitally signed message part.