Subject: [sidr] WGLC: draft-ietf-sidr-rpsl-sig - End Jul 02 2015

From: Chris Morrow <[email-masked]>
Date: Thu, 18 Jun 2015 11:14:20 +0200

Howdy WG Folks,

Today is your day! we start a WGLC for:
  draft-ietf-sidr-rpsl-sig
  <https://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-07>

Abstract:
  "This document describes a method to allow parties to electronically
   sign RPSL-like objects and validate such electronic signatures.  This
   allows relying parties to detect accidental or malicious
   modifications on such objects.  It also allows parties who run
   Internet Routing Registries or similar databases, but do not yet have
   RPSS-like authentication of the maintainers of certain objects, to
   verify that the additions or modifications of such database objects
   are done by the legitimate holder(s) of the Internet resources
   mentioned in those objects."

This document is through 7 revisions, over quite a period of time, the
Authors feel as though they have attended to all commentary so far and
would appreciate a final read-through and thought about pushing this
forward to IETF Last Call.

Thanks!
-chris
co-chair-will-o-the-wisp

---

From: Geoff Huston <[email-masked]>
Date: Wed, 24 Jun 2015 12:26:59 +1000

section 3.1, bullet 4 - s/notaion/notation/

Bullet 4 of this list looks confused

* Date and time fields MUST be converted to 64-bit NTP Timestamp Format [RFC5905].

     thats a binary value, 32 bits of seconds since epoch and 32 bitss of fractions - right?
     Does this also mean that the Era is 1 January 1900?

*  AS numbers MUST be converted to ASPLAIN syntax [RFC5396].

     hang on - thats ascii - why is the time field binary and this field ascii?

*  IPv6 addresses must be canonicalized as defined in [RFC5952].

     this is also ascii 

*  IPv4 addresses MUST be converted to a 32-bit representation
          (e.g., Unix's inet_aton()).

     inet_aton returns a binary struct - which is NOT ascii. 

*  All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR
          notaion [RFC4632].

     so I think you are referring to a range of IP addresses.

     I assume that this means that at times this will be a list of addresses
     (i.e. the range of addresses 10.0.0.1 - 10.0.0.2 is 10.0.0.1/32 and 10.0.0.2/32)

     Are you wanting a cononical CIDR form? (i.e. should the pair of prefixes 10.0.0.0/24 and 10.0.1.0/24
     be represented as 10.0.0.0/23?)

     Other RPKI specs (e.g. RFC6487) referenced the canonical representation of a
     set of addresses as defined in RFC3779. I assume you had a good reason not to
     use the same approach

So why are some items in this list ascii and some binary? Would it make more sense to use either all binary or all ascii here?

regards,

    Geoff

> On 18 Jun 2015, at 7:14 pm, Chris Morrow <[email-masked]> wrote:
> 
> Howdy WG Folks,
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Wed, 24 Jun 2015 12:27:38 +1000

this is also ascii

regards,

Geoff

Howdy WG Folks,

Abstract:

Thanks!
-chris
co-chair-will-o-the-wisp

---

From: Geoff Huston <[email-masked]>
Date: Wed, 24 Jun 2015 12:27:43 +1000

this is also ascii 

regards,

   Geoff

---

From: Brian Haberman <[email-masked]>
Date: Wed, 24 Jun 2015 10:54:01 -0400

Hi Geoff,
     Thanks for the review.  Some responses in-line...

> section 3.1, bullet 4 - s/notaion/notation/

Will fix.

>      thats a binary value, 32 bits of seconds since epoch and 32 bitss of fractions - right?

In the code I wrote a few years ago, I convert the timestamp to an ascii
string representation. Some of the conversion logic is in 5905 and the
rest is based on the C libraries for managing time.

>      Does this also mean that the Era is 1 January 1900?

Yes, it does... and that may be a problem in 21 years. Changing this to
the 128-bit Date Format from 5905 doesn't appear to be an issue.  When I
get some time in the next few days, I will update my prototype code and
test it out.

>      hang on - thats ascii - why is the time field binary and this field ascii?

As noted above, the time is converted to ASCII.

> *  IPv6 addresses must be canonicalized as defined in [RFC5952].

Yes.

>      inet_aton returns a binary struct - which is NOT ascii. 

But can be converted to the ASCII representation of the 32-bit number.
I will update the draft to be explicit about that.

> *  All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR

Yes, as described in RPSL (RFCs 2280 and 2622).

>      set of addresses as defined in RFC3779. I assume you had a good reason not to

The 3779 approach moves away from the RPSL representation of prefixes.
Introducing ASN.1-based representations to RPSL seems... odd.

Regards,
Brian

---

From: Geoff Huston <[email-masked]>
Date: Fri, 26 Jun 2015 09:57:23 +1000

Thanks for the responses Brian. Some followup responses interleaved with your text follow.

> rest is based on the C libraries for managing time.

So the document needs to define the epoch and the exact method of encoding to ascii I would’ve thought.

> get some time in the next few days, I will update my prototype code and

code is good. A clear unambiguous spec is also good!

> As noted above, the time is converted to ASCII.

Better if the document makes this clear.

> I will update the draft to be explicit about that.

explicit is good - but why not use dotted quad notation?

> Introducing ASN.1-based representations to RPSL seems... odd.

so I think we are talking past each other.  Lewt me try to explain myself with a simply question

How should I represent the following ranges of number resources in a canonical format according to this draft?

a) the IPv4 address range 10.0.0.0 through to 10.0.2.255 ?

b) the ASN range 131072 through to 131075

c) the IPv6 range 2001:0:0:0:0:2:0:0:0 through to 2001:0:0:0:0:5:ffff:ffff:ffff

Geoff

---

From: Brian Haberman <[email-masked]>
Date: Mon, 29 Jun 2015 11:53:40 -0400

Hi Geoff,
    Sorry for the delay.  These are useful comments and I have some
responses in-line...

> So the document needs to define the epoch and the exact method of encoding to ascii I would’ve thought.

The epoch is defined within the confines of 5905, but doesn't apply to
the Timestamp format..  I will draft some text that articulates the
conversion methodology.

> code is good. A clear unambiguous spec is also good!

Agreed.  The NTP Date Format is more appropriate.  I will draft some
text discussing the use of the Date Format and representing it in ASCII.

> Better if the document makes this clear.

Agreed.

> explicit is good - but why not use dotted quad notation?

The original thought between the authors was to normalize IPv4 addresses
to ensure consistent representation.  Having thought about this some
more, I believe we can accomplish that goal using RPSL's IPv4 address,
prefix, and range types.

> How should I represent the following ranges of number resources in a canonical format according to this draft?

Given the change proposed above...

> a) the IPv4 address range 10.0.0.0 through to 10.0.2.255 ?

10.0.0.0/22 (<address-prefix> per RFC 2622).

> b) the ASN range 131072 through to 131075

Several ways, but an as-block works well (as-block: AS131072 - AS131075,
per RFC 2725 and applying the ASPLAIN representation). It could also be
represented using as-list or as-set.  However, that would require
additional requirements that those attributes be signed as well.

> c) the IPv6 range 2001:0:0:0:0:2:0:0:0 through to 2001:0:0:0:0:5:ffff:ffff:ffff

First, I am going to assume that the last 16 bits are extraneous (unless
IPv6 addresses are now 144 bits long).

2001::/93.

Other examples that include hex digits need to apply the normalization
described in RFC 5952.

So, I think that one item that needs clarifying is the intent to re-use
RPSL attributes as much as possible and apply normalization where there
could be ambiguities.  That can be done in the intro.  I will add some
additional text to section 3 to clarify that the originator of the data
needs to pick the appropriate attributes to represent the data and
normalize the values as needed.

Thanks,
Brian

---

From: Geoff Huston <[email-masked]>
Date: Tue, 30 Jun 2015 12:38:28 +1000

thanks Brian,

Just a couple of minor pickups left : …

> 10.0.0.0/22 (<address-prefix> per RFC 2622).

that address range encompasses 3 x /24s

10.0.0.0/24, 10.0.1.0/24 and 10.0.2.0/24

so that list is one alternative

a second alternative is the list

10.0.0.0/23, 10.0.2.0/24

a third alternative is the address range

10.0.0.0- 10.0.0.2.255, but thats not CIDR 

So this intent is to define a single cononical representation that allows rapid comparison, right?

so you either use CIDR and allow for a list, or you revert to a range presentation and refer to start and finish addresses. But either way you need to clarify how to reer to ranges that are not conveniently aligned into a single CIDR boundary

> additional requirements that those attributes be signed as well.

right - how to represent a range of AS’s is the underlying question here.

> IPv6 addresses are now 144 bits long).

the problem here is that the start of this block is not 2001:0:0:0:0:0:0:0, but 2001:0:0:0:0:2:0:0

so once more this is a range of addresses not a single CIDR prefix. What is the proposed canonical representation of this range of addresses?

> normalize the values as needed.

yep - RFC3779 did that already, and you may want to use that canonical representation without the ASN.1 goop and use ascii instead, or you may have another preferred canonical format, BUT it is essential that the spec clearly and unambigously delas with address ranges.

(You may also want to consider discontiguous address ranges - I dunno if they exist in the route registries, but if they do then its in scope here)

Geoff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 30 Jun 2015 15:42:32 -0400

I made a few edits to correct spelling errors. I also have some 
questions about
ambiguities in the text and some suggestions for adding text to warn 
relying parties
about the danger of assuming that all signed attributes in an RPSL 
object are
trustworthy/valid.

I have attached a PDF of the MS Word reviewed text.

Steve