Subject: [Gen-art] Gen-art LC/Telechat review of draft-ietf-sidr-usecases-05.txt

From: Elwyn Davies <[email-masked]>
Date: Wed, 19 Dec 2012 20:17:54 +0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sidr-usecases-05.txt
Reviewer: Elwyn Davies
Review Date: 19 December 2012
IETF LC End Date: 20 December 2012
IESG Telechat date: (if known) 20 December 2012

Summary:
This doucment is almost ready for publication.  There are a couple of
very minor issues (glorified nits really) and a number of real nits. 

Major issues:

Minor issues:
s1.4: The document doesn't appear to use any RFC 2119 upper-cased words.
If this is correct (and it probably is as the document isn't specifying
requirements) then this para and the RFC2119 ref SHOULd be removed.

s2.1, para 1: 
>    assumed to be intended (i.e., considered
>    unsuspicious) unless proven otherwise by the existence of a valid
>    RPKI object.
It is possible that I don't understand the problem, but this appears to
be trying to prove a negative by the existence of something.  What RPKI
object would have to exist to make the route suspicious?

s6.2: Can the make-before-break principle be applied to the resource
certificate for Org B?  Presumably this would mean overlapping existence
of resource certs for Org A and Org B so that the ROA add can occur
before the revoke.  Is this a problem?

Nits/editorial comments:

Abstract/a1:  The opening sentence is a bit obscure:

> This document provides use cases, directions, and interpretations for
>    organizations and relying parties when creating or encountering RPKI
>    object scenarios in the public RPKI.  All of the above are discussed
>    here in relation to the Internet routing system.
> 
Maybe better:
   This document describes a number of use cases together with directions and 
   interpretations for
   organizations and relying parties when creating or encountering RPKI
   object scenarios in the public RPKI.  All of the above are discussed
   here in relation to the Internet routing system.

Abstract/s1 et seq: Need to expand RPKI

ss1.1/1.3:  Although ROA is expanded in s1.1 as part of a document
title, it would be helpful to include a definition in s1.3 as it is used
a great deal in the other definitions.

s1.3, para 1: Technically, I don't think you need the author's
permission as it is an IETF draft, but it is polite.

s1.3, several places: s/in consideration/under consideration/

s1.3, last para: Possibly need to clarify *what* is originated?  s/that
is originated/for which a route is advertised/

s2.1, para 1: s/stance/operational policy/?

s3.3: the two ASNs used in the example are visually easily confused.
Might be better to use a more obviously different second ASN.

s3.5: Might be useful to refer to the currently in progress
draft-ietf-idr-as0 regarding AS0.

s4: The wording of the first sentence will have to be changed (or just
removed) for the published RFC.

s5.2 and s5.3, first table, fourth line of body: s/YES/Yes/

s6.x: Given the 'make-before-break' principle, would it be sensible to
describe the add before the revoke in each case?

s7.1: Could the terms Valid, Invalid and Not Found be usefully included
in the definitions section?

s7.1.6: see comment re s3.5 and RFC 6483.

s7.1.7, 'comment' para: s/exit/exist/

---

From: Terry Manderson <[email-masked]>
Date: Wed, 19 Dec 2012 16:53:54 -0800

Hi Elwyn,

Thanks for your review. While Sriram holds the pen at this stage, I will
reply here.

> requirements) then this para and the RFC2119 ref SHOULd be removed.

Great observation, yes RFC2119 can be removed.

> object would have to exist to make the route suspicious?

Essentially a valid RPKI ROA object would need to exist that proves a route
is suspicious. Because the RPKI+ROA is a "bolt on after the fact" security
effort, you can do no more. Simply routing exists now, the RPKI would be
deployed in the future. So any route that is seen must be considered
intended unless proven otherwise.

> before the revoke.  Is this a problem?

The preference, I believe (and my co-authors can correct me) is that two
different resource certificates (unless one in subordinate to the other)
should never exist.

This problem is an open issue in SIDR related to the grandfathering topic.
So for now the usecase should be that overlap cannot occur.

>    here in relation to the Internet routing system.

Nicer, Thanks.

> Abstract/s1 et seq: Need to expand RPKI

Ack.

> a great deal in the other definitions.

Ack.

> permission as it is an IETF draft, but it is polite.

I'd like to err on the side of politeness :)

> s1.3, several places: s/in consideration/under consideration/

Ack

> is originated/for which a route is advertised/

Does

Multi-homed prefix or subnet: A prefix (i.e., subnet) for which a route is
   originated to two or more Autonomous Systems.

work for you?

> s2.1, para 1: s/stance/operational policy/?

nice :-)

> Might be better to use a more obviously different second ASN.

Sriram, are you able to change the text and the table to have one of the
ASNs be AS64511 for both sec 3.2 and 3.3?

> draft-ietf-idr-as0 regarding AS0.

I'm easy. Sriram, Russ?

> removed) for the published RFC.

Ack

> s5.2 and s5.3, first table, fourth line of body: s/YES/Yes/

Ack.

> describe the add before the revoke in each case?

ahh.. I think we have a disconnect. make before break is considered in the
routing sense that a route is considered o.k. (UNKNOWN) unless proven
otherwise, this means you can remove ALL RPKI object for a route, and it
will still exist happily until a new and conflicting RPKI ROA is created..
And we are working to that. Not necessarily making a new valid object before
breaking the old valid object. That would then imply ownership of a prefix
can then be in two places at the same time. And like the transfer of title
for a house, overlap tends to be considered a bad thing. (co-authors, chime
in here!)

> in the definitions section?

Yes.

> s7.1.6: see comment re s3.5 and RFC 6483.

Ack.

> s7.1.7, 'comment' para: s/exit/exist/

Ack.

Sriram, can you make the required changes as necessary to the holding
pattern copy assuming we all agree?

Cheers
Terry

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 20 Dec 2012 01:23:04 +0000

Hi, Terry.

Thanks for the swift reply.

Looks like all is well with most of he comments.

I guess the main consclusion would be that you maybe need to put in a
bit more explanation of the context to which make-before-break applies
as per your explanation to me below.

Excised the various 'acked' bits.. couple more comments in line.

Regards,
Elwyn

> intended unless proven otherwise.
I see now.. perhaps you could add something like:
... valid RPKI object that explicitly invalidates the route (see Section
7 for examples).
> So for now the usecase should be that overlap cannot occur.
Do you think this needs explicit  mention?
> >    here in relation to the Internet routing system.
:-)

>    originated to two or more Autonomous Systems.

Maybe 'through two or more' but basically 'yes, thanks'.
> nice

:-)

> for a house, overlap tends to be considered a bad thing. (co-authors, chime
See initial comment.. this is a useful explanation and some words to
this effect would avoid others with equally bad understanding of the
RPKI scenario making the same mistake.

Regards,
Elwyn

---

From: Terry Manderson <[email-masked]>
Date: Thu, 20 Dec 2012 17:02:39 -0800

> as per your explanation to me below.

I hear you, I will come back to you after Xmas with some expanded draft text
for s2.1.

> ... valid RPKI object that explicitly invalidates the route (see Section

That works for me.

> Do you think this needs explicit  mention?

No. I feel it is better to remain silent in the usecases. A requirements
document (should one ever be set as a charter deliverable) would define that
behaviour, which would then be reinforced by the RPKI architecture.

I personally feel it is better to bis this document should change be needed.

> Maybe 'through two or more' but basically 'yes, thanks'.

Works for me.

> RPKI scenario making the same mistake.

Ack. Will run draft text past co-authors and bring back post xmas.

Terry

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 21 Dec 2012 12:06:42 +0000

Hi, Terry.

That's all fine by me.

Have a great Christmas!

Elwyn

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 26 Dec 2012 00:17:36 -0500

Hi Elwyn,

I have carefully read all the comments in this thread.
Thank you for your review and comments -- very helpful.
I have a good understanding of all the changes I need to make.
I will spin a new version by Wednesday (12/26) evening or Thursday a.m. 
Will run it by Terry and Russ first and then post it here in this thread as an attachment.

Happy Holidays.

Sriram
________________________________________
From: Elwyn Davies [[email-masked]]
Sent: Friday, December 21, 2012 7:06 AM
To: Terry Manderson
Cc: General Area Review Team; [email-masked]
Subject: Re: Gen-art LC/Telechat review of  draft-ietf-sidr-usecases-05.txt

Hi, Terry.

That's all fine by me.

Have a great Christmas!

Elwyn

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 30 Dec 2012 15:25:40 +0000

Hi Sriram, Terry.

The new draft covers almost everything in the review and is fine with
one exception.

On ree-reading the draft and Terry's reponse to my original comment
about 'make-before-break', I have come to the conclusion that this
phrase is possibly confusing.  Arguably you actually have a
'break-before-make' policy! 

> for a house, overlap tends to be considered a bad thing. (co-authors,
the timeline for the transition between one ROA and a new one would be

Time BGP FIB Event       ROA Event              Route Validation status
T0   Route R1 recvd                             (initially?) NotFound
T0+  Route R1 installed                         NotFound
T1                       ROA1 covering R1 recvd Valid
T2                       ROA1 revoked           NotFound
T3                       ROA2 recvd             Invalid (or Valid)
T3+  Route R1 removed    (for the Invalid case)

So to my mind the treatment of the toutes might be described as
'optimistic acceptance' or 'negative vetting' (as routes are only thrown
out if explicit negative evidence is received) but the ROA
mechanism/policy is definitely break the old ROA before issuing a new
one to avoid having conflicting ones in existence.

It may be that:
- not using the term 'make-before-break' but rather using Terry's words
would avoid 'interpretation'.
- explaining that seeing contradictory ROAs in a router is bad news and
one should check for revocations - presumably the RPKI infrastructure
would prevent a DoS attack here.

Best wishes for the New Year,
Elwyn
On Thu, 2012-12-27 at 16:20 -0500, Sriram, Kotikalapudi wrote:
> Hi Elwyn, Terry:
> 
> Please find attached the revised -06 version .txt file and also the rfc-diff file (-05 vs. -06).
> I think I have captured all the comments you two have gone over,
> and also included are minor comments from Barry, Stewart, others.
> Please let me know if I missed anything.
> 
> Elwyn: Please let me know if need to upload a -06 version to the the IETF submissions page
> at some pioint. Thanks again for all your commnets and help.
> 
> Sriram
> 
> From: Sriram, Kotikalapudi [[email-masked]]
> Sent: Wednesday, December 26, 2012 12:17 AM
> To: Elwyn Davies; Terry Manderson
> Subject: RE: Gen-art LC/Telechat review of  draft-ietf-sidr-usecases-05.txt
> 
> Hi Elwyn,
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 31 Dec 2012 21:04:05 -0500

> The new draft covers almost everything in the review and is fine with

Thanks for the re-read.

Please see further down for my next comment/response.

> one to avoid having conflicting ones in existence.

The make-before-break principle clearly applies in these two situations:
(1) When there is a suballocation situation; see Example 1 below,
(2) If it is the same prefix owner creating a different ROA 
for all or part of the prefix; see Example 2 below.

Example 1 (suballocation situation): 

My ISP used to originate my prefix (suballocation) from their AS.
Now I have my own ASN and I wish to announce my prefix
with my AS as the origin,
and I still connect upstream to the same ISP AS.
The ISP had previously created a ROA for my suballocation
with their ASN as the origin AS.
Even though I will be creating a new ROA for my own said route origination, 
I would much prefer (even require) that they continue to keep that existing ROA active
at least until I am all good with my own new ROA.
I also prefer they continue to announce my prefix (or an aggregate above it) 
while I am getting up to speed.
They (my upstream ISP) will anyway receive my traffic and pass it down to my AS.
There will be no conflict between the two ROAs (mine and ISP's). 
They can be both be active and valid simultaneously. 
I (as suballocation owner) would be happy for that.
ISP can withdraw their ROA for my suballoaction later if they wish.

Example 2 (same prefix owner creating a different ROA):

Say, Org. A owns 10.1.0.0/20 and have ROA {10.1.0.0/20, AS 64499},
and currently announces route (10.1.0.0/20, AS 64499). 
They also have another AS that is AS 64511.
Say, they decided they want to split the prefix for TE or other purpose, and 
wish to announce 
10.1.0.0/21 from AS 64499, and 10.1.8.0/21 from AS64511.
Certainly, they should create new ROAs {10.1.0.0/21, AS 64499}
and {10.1.8.0/21, AS 64511} 
before they revoke/withdraw their existing ROA {10.1.0.0/20, AS 64499}.
They may even create the new more specific ROAs, and not withdraw the existing ROA.  
There is no conflict due to the different ROAs in this case.

Example 3 (the transfer case):
When there is a transfer of prefix ownership from Org. A to Org. B,
the onus is on the Org. B to create a ROA for their proposed
route announcement before actually announcing the route.
Note that Org. B has its own AS  (different from AS that Org. A has). 
Org. B creating its own ROA first is a safe thing to do rather than assume that 
the previous owner’s ROA will be revoked/withdrawn before 
Org. B announces its route.
A CRL will propagate for Org. A’s cert for that prefix
and their old ROA will be withdrawn/revoked,
but with this type of transfer use case, it is prudent for
Org. B to allow some time for its own ROA to be in place
before announcing its route.
This is more like make-ROA-then-announce principle.
We can add some clarification/suggestion of this nature in Section 6.
Please let us know if this seems reasonable.

Sriram