Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt / error handling;

From: Randy Bush <[email-masked]>
Date: Sat, 02 Jul 2011 10:50:18 +0900

hannes,

you raised two issues:

  o versioning, protocol upgrade, ...  i will open that can of worms up
    in another message

  o what do do when the router receives a duplicate ipvx prefix.  the
    relevant text from 5.5 says

	In the RPKI, nothing prevents a signing certificate from issuing two
	identical ROAs, and nothing prohibits the existence of two identical
	route: or route6: objects in the IRR.  In this case there would be no
	semantic difference between the objects, merely a process redundancy.

	In the RPKI, there is also an actual need for what might appear to a
	router as identical IPvX PDUs.  This can occur when an upstream
	certificate is being reissued or there is an address ownership
	transfer up the validation chain.  The ROA would be identical in the
	router sense, i.e. have the same {prefix, len, max-len, asn}, but a
	different validation path in the RPKI.  This is important to the
	RPKI, but not to the router.

	The cache server is responsible for assuring that it has told the
	router client to have one and only one IPvX PDU for a unique {prefix,
	len, max-len, asn} at any one point in time.  Should the router
	client receive an IPvX PDU with a {prefix, len, max-len, asn}
	identical to one it already has active, it SHOULD raise a Duplicate
	Announcement Received error.

i.e. in the rpki world, duplicates make sense and are allowed.  on the
router, they do not make sense.  hence the cache is formally responsible
for that boundary, and must not send dupes to the router.

this was meant to clearly state that, if the router receives a
duplicate, then either
  o the cache is broken because it must not send dupes, or
  o the router's data for that cache are incorrect, and it is not
    really a dupe.

in either case, something is very broken.  in this protocol, unlike bgp,
when things are very broken, drop the session.  unlime bgp, the router
has other sessions with similar data, other caches available to it, ...

perhaps the next version should be even more explicit

   The cache server MUST ensure that it has told the router client to
   have one and only one IPvX PDU for a unique {prefix, len, max-len,
   asn} at any one point in time.  Should the router client receive an
   IPvX PDU with a {prefix, len, max-len, asn} identical to one it
   already has active, it SHOULD raise a Duplicate Announcement Received
   error.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Jul 2011 11:08:17 +0900

on versioning, upgrading, new pdus, ... i fear that i have been very
sloppy.  for instance, the iana consideration section does not ask for a
registry for Protocol version.

on the naggumite far right we have the problem i stated earlier, the
goal in dropping the session if an unrecognized pdu type is received is

    it prevents chaotic pretend upgrading producing a bunch of incorrect
    garbage in the router's database which leads to incorrect validity
    decisions and thus incorrect routing.

    imagine that the unrecognized pdu was signaling "flush all data with
    origin AS 42," or "delete all roas for prefix P or longer."

on the be liberal in what you receive far left we have

    1. the router does not recognize the new PDU and returns an error.
    2. by including the unrecognized PDU in the error message the
       cache knows what particular PDU type has caused grief,
       such that it can log it and bring it to the operators attention.

    ---

    ok lets go through this:

    i was worried about e.g. a "central" deployment model where all your ASBRs
    have a session to a central cache. now consider you want to upgrade
    the cache with rob's latest sw (which introduces new PDUs).

    now all rpki-rtr sessions start to flap, unless you have upgraded
    routers to support the new PDUs. - you might argue that you should simply
    upgrade the routers first, thereby implying a certain upgrade order/procedure.
    that is going to be a problem:

    at some of my larger customers operational responsibilities (routers, servers)
    are strictly seperate and this hidden requirement to upgrade routers first,
    will likely be causing support-tickets at vendors of routing and local-cache
    software.

i suspect that the core of the disagreement may be a difference in
model.  

the bgp heads are used to a unique session whose data may be critical
and can not afford to be lost.

others of us are strongly attached to correctness and are less worried
about dropping sessions because they are not unique in the data sense.
the router is getting the same (well close to) data from other caches,
so the cost of dropping any one session is negligible.

i think that if we can resolve this difference i can then hack the docco
to match.

i suspect that a consequence of the right wing position may be that the
Protocol Version must change if PDU Types are added or changed.  this
may imply that, on session start, when the cache receives a PDU from the
router, it has to adjust to the router's version 'capability'.  hmmmm.

randy

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 5 Jul 2011 17:43:38 -0400

On Jul 1, 2011, at 10:08 PM, Randy Bush wrote:
> Protocol Version must change if PDU Types are added or changed.  

That's a viable option.  I'll leave it to others to comment whether it's palatable to them or not.

> this

Yes, the lack of any establishment phase makes this part a little squicky.  One can either decide to tolerate the grossness, or add an explicit version PDU exchange or similar.  The latter seems nicer but might itself require a version bump to introduce?

--John

---

From: Pradosh Mohapatra <[email-masked]>
Date: Wed, 6 Jul 2011 14:31:19 -0700

> That's a viable option.  I'll leave it to others to comment whether it's palatable to them or not.

It seems to be an overkill though! It depends on what PDU is being introduced (yes, that means a notion of mandatory and optional PDUs ;-)). PDU change, definitely!

> Yes, the lack of any establishment phase makes this part a little squicky.  One can either decide to tolerate the grossness, or add an explicit version PDU exchange or similar.  The latter seems ni…

Putting the version# in to the reserved part of the reset query PDU seems like a good start.

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Jul 2011 06:28:23 +0900

> Putting the version# in to the reserved part of the reset query PDU

it is already in the version number field.

randy

---

From: Pradosh Mohapatra <[email-masked]>
Date: Wed, 6 Jul 2011 15:03:09 -0700

> it is already in the version number field.

Oops! sorry ;-( I meant to say that should suffice (as a version exchange mechanism) since the router always sends a reset query after session establishment.

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Jul 2011 07:29:27 +0900

> Oops! sorry ;-( I meant to say that should suffice (as a version
> exchange mechanism) since the router always sends a reset query after
> session establishment.

that part is easy:
  o router sends version
  o if server can sing that version, all goes ahead
  o if not, server sends error and disconnects
  o router tries another server

but you bring up allowing the router to ignore unknown pdu types if the
version matches.  i.e. there can be new pdu types which do not have
important semantics.  just so i can wrap my head, which is on first
cuppa, around this, could you give me an example?  my first reaction is,
if it has no important semantics, then why add it? :)

if a sender MUST only send unimportant unknown pdus, to enforce this,
how does the recipient know if the unknown pdu type it just received is
important or not?  i guess the sender can paint them grey. :)

but moving past this cloudy space, ...

how do we tell the iana that it can only add to the pdu type registry if
the version is bumped?  or is it a registry of 

  version  pdu-type
     0        0
     0	      1
     ...
     1       13
     1	     14
     ...

randy

---

From: Pradosh Mohapatra <[email-masked]>
Date: Wed, 6 Jul 2011 19:11:09 -0700

> if it has no important semantics, then why add it? :)

E.g.

If and when (;-)) we add origin validation for VPN routes and we do it by adding
a VPN prefix PDU.

> important or not?  i guess the sender can paint them grey. :)

By definition, if it's the same version#, all unknown PDUs are unimportant...
Otherwise, they are important ;-)

> the version is bumped?  or is it a registry of 

This should work if it can be done!