Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt

From: [email-masked]
Date: Wed, 29 Jun 2011 00:00:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

	Title           : The RPKI/Router Protocol
	Author(s)       : Randy Bush
                          Rob Austein
	Filename        : draft-ietf-sidr-rpki-rtr-13.txt
	Pages           : 24
	Date            : 2011-06-28

   In order to formally validate the origin ASs of BGP announcements,
   routers need a simple but reliable mechanism to receive RPKI
   [I-D.ietf-sidr-arch] prefix origin data from a trusted cache.  This
   document describes a protocol to deliver validated prefix origin data
   to routers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-13.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-13.txt

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 29 Jun 2011 11:16:52 +0200

hi,

i have some concerns about the error handling of error codes;
IMO error codes 5,6,7 should not be "fatal" in the sense that
the session needs to get re-signaled;

   5: Unsupported PDU Type (fatal):  The PDU Type is not known by the
      receiver of the PDU.

<-- this prevents seamless upgrading once we want to extend the protocol;
    why is this fatal ?

   6: Withdrawal of Unknown Record (fatal):  The received PDU has Flag=0
      but a record for the Prefix/PrefixLength/MaxLength triple does not
      exist in the receiver's database.

   7: Duplicate Announcement Received (fatal):  The received PDU has an
      identical {prefix, len, max-len, asn} tuple as a PDU which is
      still active in the router.

<-- why do we need to reset the session here for reasons 6 & 7 ? -
    in the spirit of "be tolerant what you receive" a receiving router
    can do the right thing w/o disrupting the session.

tx,

/hannes

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 Jun 2011 20:03:14 +0900

hi hannes,

first, i need to confess that i have disagreed with 'be liberal in what
you accept' from day zero.  that way lies entropy.

> <-- this prevents seamless upgrading once we want to extend the protocol;

not exactly.  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."

>     can do the right thing w/o disrupting the session.

in general, all these indicate that the receiver and the sender are
seriously out of whack.  e.g. if the receiver goes ahead despite 6 or 7,
the receiver's data are most likely incorrect in the sense that it will
[in]validate an update which it should not.  if that's not fatal, what
is?

but, i think at root, we have a disagreement on the idea of requiring
'correctness.'  as i said, i admit to being a naggumite.

randy

---

From: "George, Wesley" <[email-masked]>
Date: Wed, 29 Jun 2011 12:16:57 -0400

I think we're a little light on text in 7 now that we've added so many options. I think it would be helpful to provide some rationale as to why AO is preferred over the other methods, why they are considered a secondary option, etc.
IOW, why *shouldn't* I just keep using TLS or SSH transport? Why is AO actually better/eventually mandatory to implement? Multiple members of this WG had strong opinions, we should be documenting our reasoning. Convince the reader that they should be yelling at YFV for AO support...
7.3 regarding MD5. At the very least, there should be a note that TCP-MD5 has been obsoleted by TCP-AO.

Thanks,

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, June 29, 2011 3:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-13.txt
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 Jun 2011 05:35:19 +0900

> I think we're a little light on text in 7 now that we've added so many
> options. I think it would be helpful to provide some rationale as to
> why AO is preferred over the other methods, why they are considered a
> secondary option, etc.
>
> IOW, why *shouldn't* I just keep using TLS or SSH transport? Why is AO
> actually better/eventually mandatory to implement? Multiple members of
> this WG had strong opinions, we should be documenting our
> reasoning. Convince the reader that they should be yelling at YFV for
> AO support...
>

this is all covered in the transport area.  do we really want this
routing security doc to get into the transport wars?  where's the win?

randy

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 Jun 2011 14:03:28 -0700

Hi, Wes,

On 6/29/2011 9:16 AM, George, Wesley wrote:
> I think we're a little light on text in 7 now that we've added so
> many options. I think it would be helpful to provide some rationale
> as to why AO is preferred over the other methods, why they are
> considered a secondary option, etc. IOW, why *shouldn't* I just keep
> using TLS or SSH transport?  Why is AO actually better/eventually
 > mandatory to implement? Multiple members of this WG had strong
 > opinions, we should be documenting our reasoning. Convince the reader
 > that they should be yelling at YFV for AO support...

I agree it would be useful to explain this, e.g., that the reason is 
that TLS/SSH doesn't protect the transport layer from interruption (even 
if such interruption is recoverable).

> TCP-MD5 has been obsoleted by TCP-AO.

Agreed. And that the reason for its use is support for legacy systems 
where TCP-AO is not yet available, as per the AO RFC.

Joe

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 30 Jun 2011 08:21:42 +0200

On Wed, Jun 29, 2011 at 08:03:14PM +0900, Randy Bush wrote:
| hi hannes,
| 
| first, i need to confess that i have disagreed with 'be liberal in what
| you accept' from day zero.  that way lies entropy.
| 
| >    5: Unsupported PDU Type (fatal):  The PDU Type is not known by the
| >       receiver of the PDU.
| > 
| > <-- this prevents seamless upgrading once we want to extend the protocol;
| >     why is this fatal ?
| 
| not exactly.  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."

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.

| >    6: Withdrawal of Unknown Record (fatal):  The received PDU has Flag=0
| >       but a record for the Prefix/PrefixLength/MaxLength triple does not
| >       exist in the receiver's database.
| > 
| >    7: Duplicate Announcement Received (fatal):  The received PDU has an
| >       identical {prefix, len, max-len, asn} tuple as a PDU which is
| >       still active in the router.
| > 
| > <-- why do we need to reset the session here for reasons 6 & 7 ? -
| >     in the spirit of "be tolerant what you receive" a receiving router
| >     can do the right thing w/o disrupting the session.
| 
| in general, all these indicate that the receiver and the sender are
| seriously out of whack.  e.g. if the receiver goes ahead despite 6 or 7,
| the receiver's data are most likely incorrect in the sense that it will
| [in]validate an update which it should not.  if that's not fatal, what
| is?

the IP PDUs in the protocol have canceling semantics - i.e. latest status
wins. so whats the point in bitching about the latest state ?

| but, i think at root, we have a disagreement on the idea of requiring
| 'correctness.'  as i said, i admit to being a naggumite.

consider the following exchange:
   (all IPvXn prefix PDUd carry exactly the same update);

   Cache                         Router
     ~                             ~
     | -------- Notify ----------> |  (optional)
     |                             |
     | <----- Reset Query -------- | R requests data
     |                             |
     | ----- Cache Response -----> | C confirms request
     | ------- IPvX Prefix1 -----> | C sends zero or more
     | ------- IPvX Prefix2 -----> |   IPv4 and IPv6 Prefix
     | ------- IPvX Prefix3 -----> |   Payload PDUs
     | ------  End of Data ------> | C sends End of Data
     |                             |   and sends new serial
     | <----- Reset Query -------- | R requests data
     |                             |
     | ----- Cache Response -----> | C confirms request
     | ------- IPvX Prefix1 -----> | C sends zero or more
     | ------- IPvX Prefix2 -----> |   IPv4 and IPv6 Prefix
     | ------- IPvX Prefix3 -----> |   Payload PDUs
     | ------  End of Data ------> | C sends End of Data
     |                             |   and sends new serial

question:
  is the second IPvX Prefix1 Update a duplicate update ?
    if so: must the cache filter those out ?
    if so: how can i guarantee that a "Reset Query" really
           gets me the latest view ?

---

From: "George, Wesley" <[email-masked]>
Date: Thu, 30 Jun 2011 10:14:43 -0400

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Wednesday, June 29, 2011 4:35 PM
To: George, Wesley
Cc: [email-masked]
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-13.txt

Like it or not, it's already in the middle of it - the additions to this section are a direct result of feedback that it would not be approved if it only used MD5 and a lack of support for AO.
You're welcome to cite sections of other drafts or RFCs from transport that cover this, I'm not asking specifically for new text unless none exists that is adequate.
The win is completeness for the audience beyond the current participants in this WG. I've been party to the discussions because I've been following the list, and it still brought up the question in my mind. What happens when people who aren't on SIDR and/or are not familiar with the transport area start reading this and are looking for some rationale and guidance?

As I've said in earlier messages, you have to remember that the folks implementing this in networks are the routing folks. They're not necessarily the same folks as the security folks, and so you have to assume slightly less background knowledge when it comes to the nuances of the security considerations of this implementation.

Wes