Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

From: Christopher Morrow <[email-masked]>
Date: Fri, 19 Aug 2011 00:00:16 -0400

Hello,
Waking a longishly dead thread to call some form of consensus on what
is now rev16 of this draft:

http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-16

I believe we cycled around most of the heated parts, finding
compromise and reaching steady-state (last real message on this topic
was 5 or so days ago).

At this point I think we're safe to go forward to IESG review. I'll be
packaging up a protos doc and mailing that forward tomorrow.

-chris
(co-chair-in-training)

On Wed, Feb 16, 2011 at 1:39 PM, Christopher Morrow
<[email-masked]> wrote:
> Ok folk,
> The rpki-rtr document:
>  <http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rpki-rtr>
>
> went through WGLC on version ~02, it's since had a slight mod (added a
> Cache-nonce added) which is here in section 4.1:
>
> "The Cache Nonce reassures the router that the serial numbers are
>   comensurate, i.e. the cache session has not been changed."
>
> and again in 4.2:
> "The Cache Nonce tells the cache what instance the router expects to
>   ensure that the serial numbers are comensurate, i.e. the cache
>   session has not been changed."
>
> and again in 4.4:
> "In response to a Reset Query, the Cache Nonce tells the router the
>   instance of the cache session for future confirmation.  In response
>   to a Serial Query, the Cache Nonce reassures the router that the
>   serial numbers are comensurate, i.e. the cache session has not been
>   changed."
>
> and again in 4.7:
> "The Cache Nonce MUST be the same as that of the corresponding Cache
>   Response which began the, possibly null, sequence of data PDUs."
>
> There's not much meat to the actual change, and the authors identified
> the problem on their own. So, in the spirit of valentines day, let's
> decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move
> forward. If there are no further comments/issues I'll push this
> version out over the weekend to the AD's as a publication request.
>
> -Chris
> <co-chair-messenger-bag==off>
>

---

From: "t.petch" <[email-masked]>
Date: Mon, 22 Aug 2011 13:03:11 +0200

Chris

I don't know if your training included
draft-ietf-tsvwg-iana-ports-10
currently in AUTH48 but it does say, as some on this list know well,

"   A service name or port number assignment request contains the
   following information.  The service name is the unique identifier of
   a given service:

      Service Name (REQUIRED)
      Transport Protocol(s) (REQUIRED)
      Assignee (REQUIRED)
      Contact (REQUIRED)
      Description (REQUIRED)
      Reference (REQUIRED)
      Port Number (OPTIONAL)
      Service Code (REQUIRED for DCCP only)
      Known Unauthorized Uses (OPTIONAL)
      Assignment Notes (OPTIONAL)"

which suggests a fairly rapid rejection of our I-D.  The section on two ports or
one, which I alluded to earlier, is section 7.2 which starts with
"   o  IANA strives to assign only one assigned port number per service
      or application"

Uh huh; I wish the iana I-D did not say what it says, and argued against it, in
tsvwg and ietf, but it does and is about to become an RFC which will control our
lives; sigh:-(

Tom Petch

----- Original Message -----
From: "Christopher Morrow" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; "Randy Bush" <[email-masked]>
Sent: Friday, August 19, 2011 6:00 AM
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

Hello,

-chris
(co-chair-in-training)

> <co-chair-messenger-bag==off>
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 22 Aug 2011 09:17:11 -0400

> currently in AUTH48 but it does say, as some on this list know well,

it didn't.

>      Assignment Notes (OPTIONAL)"

ok, so we had dealt with IANA requests after submission previously (I
thought). We can do that here, or while I make a protos doc an author
could spin a new rev with this data included, eh?

Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems
non-scalable in a number of dimensions. :(

-chris

---

From: "t.petch" <[email-masked]>
Date: Mon, 22 Aug 2011 14:42:59 +0200

----- Original Message -----
From: "Christopher Morrow" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Randy Bush" <[email-masked]>
Sent: Monday, August 22, 2011 3:17 PM
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

it didn't.

<tp>
Chris

CONTACT can be a WG, the ietf or iesg, or even a person.

My thinking was, be prepared for this to come back to us with a request for
information, rather than spin a new draft; I suspect there will be other
requests as
well.

I have been waiting for a port request to appear since the iana draft was
approved and have not seen one - this may be the first.

The port registry is one of those that IANA has converted to XML rendering it
almost unusable:-(

Tom Petch

</tp>

-chris

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Aug 2011 09:01:31 -0700

Hi, Tom,

On 8/22/2011 4:03 AM, t.petch wrote:
> which suggests a fairly rapid rejection of our I-D.

Sure, but on trivial grounds (the service names you provide have spaces).

To assist with your application, here's a suggestion (this need not be 
in the RFC, but the RFC should conform to the following information 
where it differs, e.g., the list of requested service names - note that 
this isn't guaranteed to fly, though, as per below):

         Service Name (REQUIRED) RPKI-Rtr
         Transport Protocol(s) (REQUIRED) TCP
         Assignee (REQUIRED) IESG <[email-masked]> (as per sec 8.1.1.)
         Contact (REQUIRED) IETF Chair <[email-masked]>
         Description (REQUIRED) request/response exchange, including
	an initial message indicating version number; data transferred
	as native records with in-band record separators and
	transaction terminators; transport connection is
	persistent across multiple request/response exchanges;
	exchanges MUST be protected by access control, and MAY
	use TCP MD5, TCP-AO, or IPsec
         Reference (REQUIRED) See RFC (TBD)
         Port Number (OPTIONAL) any in the well-known range
         Service Code (REQUIRED for DCCP only) N/A
         Known Unauthorized Uses (OPTIONAL) N/A
         Assignment Notes (OPTIONAL)

         Service Name (REQUIRED) RPKI-Rtr-TLS
         Transport Protocol(s) (REQUIRED) TCP
         Assignee (REQUIRED) (as per sec 8.1.1.)
         Contact (REQUIRED) IETF Chair <[email-masked]>
         Description (REQUIRED) request/response exchange, including
	an initial message indicating version number; data transferred
	as native records with in-band record separators and
	transaction terminators; transport connection is
	persistent across multiple request/response exchanges;
	exchanges MUST be protected by access control and TLS
         Reference (REQUIRED)See RFC (TBD)
         Port Number (OPTIONAL) any in the well-known range
         Service Code (REQUIRED for DCCP only) N/A
         Known Unauthorized Uses (OPTIONAL) N/A
         Assignment Notes (OPTIONAL)

Regarding Chris's question:
On 8/22/2011 6:17 AM, Christopher Morrow wrote:
 > non-scalable in a number of dimensions.

Again see Sec 8.1.1. It's a person (usually the person who issues the 
request) in all cases except IETF document stream assignments.

> The section on two ports or
>        or application"\

This was updated as a result of IETF last call and IESG review. The 
current text (pending final typo corrections) reads as follows (the 
tracker here shows this:)
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/writeup/

--
o  IANA strives to assign only one assigned port number per service
       or application

Note: At the time of writing of this document there is no IETF consensus
on when it is appropriate to use a second port for an insecure version 
of a protocol.
--

This is a bit of a sticky example, mostly because you're asking for a 
well-known port. It'd help to have IESG consensus on the use of an 
insecure protocol in that range.

The current doc is a bit confusing on this point - do you ever intend to 
allow both insecure and TCP MD5/TCP-AO/IPsec on the same port?

AFAICT, you actually want (need) three ports:

	RPKI-Rtr-open - insecure
	RPKI-Rtr-tnsec - transport/network security
	RPKI-Rtr-apsec	- application-layer security (TLS)

Then you need to explain clearly why you *cannot* determine which 
category a connection falls from the packets that arrive -- and 
performance alone is not a sufficient reason (that could then be used to 
argue, e.g., for dozens of ports for various services, and the port 
space is too limited to support that just for performance reasons).

It seems like -open is an uphill issue if you ask for a well-known port, 
IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Aug 2011 09:05:26 -0700

On 8/22/2011 5:42 AM, t.petch wrote:
...
> CONTACT can be a WG, the ietf or iesg, or even a person.

Contact is always a person. It can be a role (WG-chair email, IETF 
chair, etc.), but it's always a person -- typically the person who 
issues the request for the port, FWIW.

> information, rather than spin a new draft; I suspect there will be other

The doc needs to have sufficient information for IANA handling of the 
request, but the info in the doc on that point can change if needed 
(e.g., it's not unusual to ask for a port number and have the final RFC 
text include that value, which is assigned before AUTH48).

> approved and have not seen one - this may be the first.

Port requests for IETF docs typically happen during the final 
assignment, and are generated automatically from the IANA actions 
portion of the doc.

> The port registry is one of those that IANA has converted to XML rendering it

It would be useful to know (off-list if desired) why you have this view; 
the conversion was intended to make the information more useful to 
programs (e.g., than 'screen scraping'), more complete, and sortable on 
each field to show relationships more clearly.

Joe

---

From: "t.petch" <[email-masked]>
Date: Wed, 24 Aug 2011 12:51:46 +0200

Joe

Thanks for the information.  I had missed the IESG update to the guidelines on
Port allocation, which relaxes the constraints on a separate port for security a
little.

Also, from experience with requests to IANA for the specification of URI and
such like schemes, where there is a pro forma which I always see in the
requesting RFC, I had imagined that something similar would now be needed for
Port number requests but perhaps not; and if there is, then you have provided it
for us.

Tom Petch

----- Original Message -----
From: "Joe Touch" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Christopher Morrow" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Randy Bush" <[email-masked]>
Sent: Monday, August 22, 2011 6:01 PM

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 12:19:40 -0700

> Port number requests but perhaps not; and if there is, then you have provided it

There's an online form at IANA, but they're in the process of updating 
it based on the I-D below. The info below answers the questions that 
apply for this protocol.

Note, however, that there still remains an interesting question here - 
whether 1, 2, or 3 ports are really needed.

1 = insecure, out-of-band security (IPsec, TCP MD5, TCP-AO), in-band-sec 
(TLS) all on one port

2 = as per the current doc:
	- insecure and out-of-band (IPsec, TCP MD5, TCP-AO) (rpki-rtr)
	- TLS (rpki-rtr-tls)

3 = all three on separate ports

Is there ever a reason that this service should exist as a totally open 
and insecure port?

Also, is there a reason for not assuming that the out-of-band and 
in-band services cannot exist on the same port (other than performance 
of the connection establishment)?

(IMO, this might be more of a sticking point if a well-known port is 
requested)

Joe

> From: "Joe Touch"<[email-masked]>
> To: "t.petch"<[email-masked]>
> Cc: "Christopher Morrow"<[email-masked]>;<[email-masked]>;
> <[email-masked]>; "Randy Bush"<[email-masked]>
>>           Assignee (REQUIRED) IESG<[email-masked]>  (as per sec 8.1.1.)
>>           Contact (REQUIRED) IETF Chair<[email-masked]>
>>           Contact (REQUIRED) IETF Chair<[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Aug 2011 13:27:43 -0700

On Aug 24, 2011, at 12:19 PM, Joe Touch wrote:

> Is there ever a reason that this service should exist as a totally open and insecure port?

Given that it is explicitly listed in the draft, I find it worrisome that you even ask the question.

   Caches and routers MUST implement unprotected transport over TCP
   using a port, RPKI-Rtr, to be assigned, see Section 12.  Operators
   SHOULD use procedural means, ACLs, ... to reduce the exposure to
   authentication issues.

> Also, is there a reason for not assuming that the out-of-band and in-band services cannot exist on the same port (other than performance of the connection establishment)?

Those aren't enough !?!?

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 14:45:19 -0700

>     SHOULD use procedural means, ACLs, ... to reduce the exposure to

I saw a declaration that this was required, but no REASON that 
unprotected transport was necessary.

> of the connection establishment)?

"those"? I listed only one - performance.

There are not enough ports to assign multiples just for performance reasons.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Aug 2011 15:57:20 -0700

On Aug 24, 2011, at 2:45 PM, Joe Touch wrote:

> I saw a declaration that this was required, but no REASON that unprotected transport was necessary.

Three paragraphs earlier in the document:

   Unfortunately,
   there is no protocol to do so on all currently used platforms.
   Therefore, as of this document, there is no mandatory to implement
   transport which provides authentication and integrity protection.

This was discussed heavily in the WG.

> "those"? I listed only one - performance.

Sorry, I misread your parenthetical as "other than performance and connection establishment". The idea that you can do TLS on the same port as not-TLS has been widely debated. It was finally agreed (maybe not by you) that the STARTTLS method for sharing a port may or may not be appropriate for each protocol. When I look at this protocol, I do not see a way to do it without completely rewriting the protocol interactions.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 17:07:54 -0700

>     transport which provides authentication and integrity protection.

I recall that discussion, but not the assertion that this would mean 
that you'd suggest using an insecure port.

If that's the case, I strongly recommend NOT asking for a system port.

> Sorry, I misread your parenthetical as "other than performance and
> connection establishment". The idea that you can do TLS on the same port
> as not-TLS has been widely debated. It was finally agreed (maybe not by
> you) that the STARTTLS method for sharing a port may or may not be
> appropriate for each protocol. When I look at this protocol, I do not
> see a way to do it without completely rewriting the protocol interactions.

Here I wasn't asking about TLS vs open, I was asking about TLS vs. 
IPsec/MD5/AO, and whether that has a different answer than TLS vs. open.

Whether for this protocol or not, I would appreciate understanding that 
in more detail - even if off-list. I cannot see how the protocol matters 
if TLS is started or not on a per-connection basis since the TLS would 
wrap (or not) the data of the connect at the start. We can continue that 
off-list, though.

Joe