Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

From: David Mandelberg <[email-masked]>
Date: Thu, 06 Mar 2014 17:16:38 +0000

Sorry, one more question on this draft: Does it make sense to mandate an 
order for the AS Numbers field of the Router Key PDU? Otherwise, what 
happens if the cache announces a router key with one ordering, and 
withdraws that router key with the same AS numbers in a different order?

---

From: Rob Austein <[email-masked]>
Date: Thu, 06 Mar 2014 17:31:33 +0000

> withdraws that router key with the same AS numbers in a different order?

Seems plausible.  Not sure it's necessary, but almost certainly
harmless, and might help.  Other opinions welcome.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 6 Mar 2014 18:12:00 +0000

So the draft does two things - adds a new PDU and makes some changes to the overall protocol function.

I would expect that adding a new PDU would be a new document, not a revision to the protocol document.  Would you agree?

Since you are changing the protocol function anyway, I can see the efficiency in making the changes together.  Of course, if there's agreement about one part and not about the other, there's some fate sharing.  Comment?

The new PDU assumes the wg agrees to the revision of the router cert draft.  Correct?  So this is tied to progress of a revised router cert draft?  Is somebody already on board to provide that new draft?

--Sandy

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Mar 2014 18:37:25 +0000

> I would expect that adding a new PDU would be a new document, not a
> revision to the protocol document.  Would you agree?

the version numbers all change

> The new PDU assumes the wg agrees to the revision of the router cert
> draft.  Correct?  So this is tied to progress of a revised router cert
> draft?  Is somebody already on board to provide that new draft?

maybe you missed draft-ymbk-rpki-rtr-keys-01.txt

how much bureaucracy can we create here?

randy

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 6 Mar 2014 19:30:33 +0000

>> draft?  Is somebody already on board to provide that new draft?>
>

Rob's message said that the new PDU would "support binding a single router key to multiple ASNs".

I presumed that this came from the change to the router cert that Rob spoke about in the sidr meeting this week.  I presumed he was speaking about a change to draft-ietf-sidr-bgpsec-pki-profiles-06, in this part 

   Each BGPSEC Router Certificate MUST include the AS Resource
   Identifier Delegation extension, as specified in section 4.8.11 of
   [RFC6487].  The AS Resource Identifier Delegation extension MUST
   include exactly one AS number, and the "inherit" element MUST NOT be
   specified.

The 6810 change Rob suggests (and draft-ymbk-rpki-rtr-keys-01.txt, too) define a new PDU carrying the router cert's AS info to the router.  But draft-ietf-sidr-bgpsec-pki-profiles-06 needs to change, too, if multiple ASNs are going to be there to carry.

>how much bureaucracy can we create here?

This isn't a big job - a change from "exactly one" to "at least one" might be sufficient.  I think that's substantive, not bureaucratic.

--Sandy

________________________________________
From: Randy Bush [[email-masked]]
Sent: Thursday, March 06, 2014 1:37 PM
To: Murphy, Sandra
Cc: Rob Austein; [email-masked]
Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

randy

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 6 Mar 2014 19:35:16 +0000

On Thu, 6 Mar 2014, Rob Austein wrote:

> > Sorry, one more question on this draft: Does it make sense to 
> > mandate an order for the AS Numbers field of the Router Key PDU? 
> > Otherwise, what happens if the cache announces a router key with one 
> > ordering, and withdraws that router key with the same AS numbers in 
> > a different order?
> 
  maybe David can a little bit more elaborate on the advantages? I 
suspect that the routers needs to inspect the AS Numbers field per entry 
anyway.

  What is the meaning of the order?

Thanks
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Rob Austein <[email-masked]>
Date: Fri, 07 Mar 2014 10:39:58 +0000

At Thu, 6 Mar 2014 19:35:16 +0000, Matthias Waehlisch wrote:
> 
> > > Does it make sense to mandate an order for the AS Numbers field
> > > of the Router Key PDU?  Otherwise, what happens if the cache
> > > announces a router key with one ordering, and withdraws that
> > > router key with the same AS numbers in a different order?
>

David can speak for himself, but speaking on my own behalf as a
implementer: if we define a canonical order, comparing two PDUs is a
simple binary string comparison.  If we don't define a canonical
order, comparison is more complicated, hence more error-prone.  Given
that the rpki-rtr protocol requires duplicate elimination, we do need
to perform such comparisons, so making them as simple as possible
seems advisable.

FWIW, I think David's suggestion is a good one, and I'm likely to
implement it that way in my server whether required to do so or not.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 7 Mar 2014 11:47:37 +0000

>From conversation with authors, answers below

>protocol document.  Would you agree?

Answer: depends on the PDU

>Is somebody already on board to provide that new draft?

I missed the import of the following captured in the minutes:

             Steve Kent: As an author, we can fix this

Answer: "yes".

--Sandy

________________________________________
From: Murphy, Sandra
Sent: Thursday, March 06, 2014 1:12 PM
To: Rob Austein
Cc: [email-masked]; Randy Bush
Subject: RE: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

--Sandy

---

From: Rob Austein <[email-masked]>
Date: Fri, 07 Mar 2014 12:23:26 +0000

Updated (-01) draft posted, incorporating David's suggestions and the
promised text regarding interoperability between versions 0 and 1 of
the protocol.

Diff of changes against the RFC:

  http://subvert-ietf.hactrn.net/sidr-rpki-rtr-bis/draft-austein-sidr-rpki-rtr-rfc6810bis-01-from-rfc6810.diff.html

---

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 7 Mar 2014 12:37:19 +0000

On Fri, 7 Mar 2014, Rob Austein wrote:

> David can speak for himself,
>
  do you have any other scenario in mind, David?

> but speaking on my own behalf as a implementer: if we define a 
> canonical order, comparing two PDUs is a simple binary string 
> comparison.  If we don't define a canonical order, comparison is more 
> complicated, hence more error-prone.
> 
  It's probably a shift of the "complexity" ... but I agree that it 
simplifies the router part.

  What happens if the ASNs are not in order (for some strange bug 
reason)? It wouldn't harm the router?

> Given that the rpki-rtr protocol requires duplicate elimination, we do 
> need to perform such comparisons, so making them as simple as possible 
> seems advisable.
>
  I suppose this requires an update of the duplicate description 
(similar text of Section 5.6 in Section 5.10, and update Section 11, no 
11).

Cheers
  matthias

---

From: Rob Austein <[email-masked]>
Date: Sun, 09 Mar 2014 11:18:09 +0100

> simplifies the router part.

Not really more complicated for the cache.  I'm holding this router
certificate with an RFC 3779 ASIdentifiers extension and need to
convert that certificate into a Router Key PDU.  Turns out the
ASIdentifiers extension already lists the ASNs in the canonical order,
so I don't even have to sort it, in fact I'd have to work harder to
put the ASNs in any other order.

Sorting simplifies things in the cache too: stripping out all the PKI
glorp can result in apparent duplicates in the stripped data, which my
server is required to remove when constructing the feed my server
gives to the router.  At least in my implementation, having a single
canonical form for the PDU simplifies this process, which is why I'm
likely to implement it this way whether required to do so or not.

> reason)? It wouldn't harm the router?

Point.  So maybe caches MUST generate the canonical format but routers
MAY skip checking to see whether the cache goofed this up?

> (similar text of Section 5.6 in Section 5.10, and update Section 11, no 

Or consolidate the discussion of duplicate PDUs somewhere else in the
document, but yes, we need to nail that down.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Mar 2014 13:22:48 -0400

Sandy,

>               Steve Kent: As an author, we can fix this
I think the minutes associated my comment from above with the wrong 
discussion.
I think I made that comment in response to a suggested change to the 
router cert
I-D, to allow more than one AS to appear in a router cert.

Steve

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 11 Mar 2014 09:55:50 +0000

The comment from me about "to provide that new draft" was a comment about a new version of the router certs draft (draft-ietf-sidr-bgpsec-pki-profiles), so your comment applies.  

The minutes note your comment during the discussion with Rob suggesting the need for more than one AS in the router certificates.  The minutes do not note the draft name, and maybe should be amended to do so to be clear.

--Sandy 

________________________________________
From: sidr [[email-masked]] on behalf of Stephen Kent [[email-masked]]
Sent: Monday, March 10, 2014 1:22 PM
To: [email-masked]
Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

Sandy,

Steve

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 17 Mar 2014 00:40:30 +0100

Sorry for the late reply ...

> MAY skip checking to see whether the cache goofed this up?
  Sounds good.

> document, but yes, we need to nail that down.
  I'm more in favor of consolidating.

  Just to double check, because the term "duplicate" is not very clear 
in this context - at least to me. In contrast to RFC 6810, in RFC 
6810-bis a Router Key PDU contains a list of ASNs. The received PDU may 
differ even though parts of the content are duplicates.

  RFC 6810 says "identical to one it already has active", which means 
that we are checking pieces of content. For example, the router receives 
Router Key PDU with ASNs {10,20,30} and later the 'same' PDU but with 
ASNs {10,20}. I would consider this as a duplicate. However, in this 
case the ordering doesn't help to apply binary string comparison.

Thanks
  matthias

---

From: David Mandelberg <[email-masked]>
Date: Mon, 17 Mar 2014 11:51:00 -0400

> to perform such comparisons, so making them as simple as possible

I fully agree with the above.

> implement it that way in my server whether required to do so or not.

I'll probably also implement it that way.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 21 Mar 2014 17:24:38 +0100

> I fully agree with the above.

+1

> I'll probably also implement it that way.

+1

---

From: Rob Austein <[email-masked]>
Date: Thu, 27 Mar 2014 14:33:08 -0400

> Sorry for the late reply ...

Mine is even later, as I was mostly offline for more than a week.

> case the ordering doesn't help to apply binary string comparison.

This is a can of worms.  Thank you for being polite about it. :)

At this point I think the simplest solution would be to change the
format of the proposed Router Key PDU so that it contains exactly one
ASN.  In the rare cases (router operators, sanity check this, please)
where there is a need for multiple ASNs to share the same key, the
cache would just issue multiple Router Key PDUs, one for each ASN.
This approach is a bit verbose in the multi-ASN case, but has
trivially simple protocol semantics.

An alternative would be to require the cache to withdraw <K,10,20,30>
then announce <K,10,20>; in this case, "duplicate" would be defined
solely by the key.

My preference for the first approach is based on the assumption that
this is a rare case, therefore not worth optimizing at the expense of
additional protocol complexity.  In particular, I would really prefer
to avoid adding code paths that will almost never be executed into a
security protocol.