Subject: [sidr] [Errata Held for Document Update] RFC7115 (4973)

From: RFC Errata System <[email-masked]>
Date: Sat, 25 Mar 2017 04:17:12 -0700 (PDT)

The following errata report has been held for document update 
for RFC7115, "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7115&eid=4973

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Tassos Chatzithomaoglou <[email-masked]>
Date Reported: 2017-03-18
Held by: Alvaro Retana (IESG)

Section: 3 & 5

Original Text
-------------
section 3
---------
For example, if, instead of 10.0.0.0/16-24, one issues
   10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed
   against 10.0.666.0/24. 

section 5
---------
Consider having a ROA for AS 42 for prefix
   10.0.0.0/16-24.  A BGP announcement for 10.0.666.0/24 from AS 666
   would be Invalid

Corrected Text
--------------
section 3
---------
For example, if, instead of 10.0.0.0/16-24, one issues
   10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed
   against 10.0.66.0/24. 

section 5
---------
Consider having a ROA for AS 42 for prefix
   10.0.0.0/16-24.  A BGP announcement for 10.0.66.0/24 from AS 666
   would be Invalid

Notes
-----
666 is not a valid octet for an ipv4 address

===
I am marking this report as "Held for Document Update" [1], which means that the author might consider its merits for a future update.  If the use of the "666" octet was intentional, then a short note explaining might be appropriate to avoid further confusion.

- Alvaro.

[1] https://www.ietf.org/iesg/statement/errata-processing.html

--------------------------------------
RFC7115 (draft-ietf-sidr-origin-ops-23)
--------------------------------------
Title               : Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)
Publication Date    : January 2014
Author(s)           : R. Bush
Category            : BEST CURRENT PRACTICE
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Mar 2017 06:36:47 -0500

> I am marking this report as "Held for Document Update" [1], which
> means that the author might consider its merits for a future update.
> If the use of the "666" octet was intentional, then a short note
> explaining might be appropriate to avoid further confusion.

problem is it's not a short note.

    In the current internet routing ecology, a /24 is the longest prefix
    which has a good chance at global propagation.  The prefix allocated
    by RFC 5737, with much verbosity, are three non-contiguous /24s.
    The result is that documents which want to discuss routable prefixes
    which involve subnetting can not use space from RFC 5737.  This is a
    general problem which someone (else) should fix.

    In RFC 7115, the subject of this erratum, routeable and subnettable
    examples were needed.  So the well-known private network 10/8, see
    RFC 1918, was used in the examples.  To indicate that it was not
    really intended to be used, an impossible octet, 666, was chosen.

this was explained a number of times as this rfc went through the
original sausage factory.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 27 Mar 2017 13:35:30 -0400

We’ve run into problems with the RFC5737 documentation examples not being suitable for the types of exampes we needed.

Previously, the suggestion was to put that explanation in the draft, to prevent recurrence of a complaint. e.g. https://mailarchive.ietf.org/arch/msg/sidr/0d99F1FOLGugyhM9JzmoDCE8KDA

However, the errata in this case is not posed as a complaint about the failure to use the documentation cases.  The errata says

That is a true statement.

Randy’s previous response was:

	666 was not accidental.

That is a true statement.

But I believe a  short note to explain the non-accidental use of 666 is something like:

In some cultures, the number 666 is supposed to be the number of “the beast”, i.e. the devil, and therefore a sign of evil.  The text chooses this number 666 in the prefix 10.0.666.0/24 with the intent to imply that the announcement is deliberately evil, disregarding the fact that 666 is not a legitimate ipv4 prefix octet.

Of course, I’m not the author, so I could be wrong.

—Sandy

> On Mar 25, 2017, at 7:36 AM, Randy Bush <[email-masked]> wrote:
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Mon, 27 Mar 2017 13:34:42 -0500

> In some cultures, the number 666 is supposed to be the number of “the
> beast”, i.e. the devil, and therefore a sign of evil.  The text
> chooses this number 666 in the prefix 10.0.666.0/24 with the intent to
> imply that the announcement is deliberately evil, disregarding the
> fact that 666 is not a legitimate ipv4 prefix octet.
> 

you are, but no big deal.  it could have been anything gt 255, but i
knew 666 would catch the western eye.

randy

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 01 Apr 2017 00:54:20 +0300

Since RFC's intention is to provide guidance, i believe that saying "a forged origin attack cannot succeed against 10.0.666.0/24" is a little bit confusing, because this statement is valid even without any RPKI in place.

After all, there is another reference of a non-documentation but valid prefix 10.0.42.0/24 already included and imho it wouldn't do any harm to include one more.

--
Tassos