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

["Sriram, Kotikalapudi" <[e-mail]>]

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

Thanks for the re-read.

Please see further down for my next comment/response.

>
> 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!
>
> So if I (now) understand correctly the following explanation:
>
>> > s6.x: Given the 'make-before-break' principle, would it be sensible
>> to
>> > 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!)
>>
> 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.

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 

>
> 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