Subject: [sidr] draft-ietf-sidr-origin-ops-19

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 05 Sep 2012 14:03:31 +0900

I've been away from the list for a while, but
Randy brought my attentiont to this draft and
I thought it was important. I support this
draft going forward. I also have a few trivial comments.

   Announcements with Invalid origins SHOULD NOT be used, but MAY be
   used to meet special operational needs.  In such circumstances, the
   announcement SHOULD have a lower preference than that given to Valid
   or NotFound.

Before I'm comfortable enough to start trashing Invalids,
I would first do the MAY, and once I get more experienced and comfortable,
I will do the SHOULD NOT.

I also ask myself

Q:Is there any way to check against the Invalid data and does it
make sense to do so?

 A. yes check logs, use a 3rd party tool to cross check, check a different cache, etc...
    anything else?

Q:What are the possible causes of invalid origins? I guess pointers
to documents would be helpful here, but unfortunately I don't know of any...

 A. mis-origination, ROA publishing mistake, etc...

Q:Should I just start by sending syslogs until I'm comfortable
with trashing routes?

 A. yes

Seiichi @ operator AS2518

---

From: Arturo Servin <[email-masked]>
Date: Wed, 5 Sep 2012 14:33:41 +0100

Today it appears that people make their ROAs incorrectly:

	- bad origin ASN (the ASN used in the route is different from the ROAs but both are registered to the ROA/Certificate issuer)
	- wrong max prefix length (people make their ROAs using their aggregates but they announce smaller prefixes)

	http://www.labs.lacnic.net/rpkitools/looking_glass/rest/invalid/cidr/0.0.0.0/0/

Regards,
as

---

From: Seiichi Kawamura <[email-masked]>
Date: Tue, 11 Sep 2012 14:40:25 +0900

This is pretty hot data. Thanks!

Regards,
Seiichi