Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

From: Sandra Murphy <[email-masked]>
Date: Sun, 5 Jul 2015 11:19:33 -0400

In November last year, a more detailed description of transfer was suggested as a means to move ahead with the validation-reconsidered discussion.  This draft is such a more detailed description.

(http://tools.ietf.org/agenda/91/slides/slides-91-sidr-0.pdf is you can't remember that far back.)

But there have been very few comments on this draft.  The hope is that this will give the wg the grounds for an informed opinion on "the need to alter the RPKI validation process along the lines of the 'validation reconsidered' draft", to quote the presentation.

Please, please, please.  Start discussion now.

Is this accurate from the standpoint of transfer activities?  from the standpoint of RPKI actions?

And the further question - does this help you to understand the validation reconsidered algorithm?

--Sandy, speaking as wg co-chair

On Jun 1, 2015, at 8:16 PM, Randy Bush <[email-masked]> wrote:

>> Title: Resource Transfer in the Resource Public Key Infrastructure
> 
> this is a very rough first draft.  all folk who agreed to author have
> not even reviewed.  i published partly to get them to wake up and tell
> me how broken my understanding is.
> 
> randy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 10:05:37 -0400

Three observations:

     - the briefing you cited was a high level discussion that did not 
make a strong
case for the validation revisited I-D.

     - I submitted comments on the list about Randy's transfer I-D.

     - draft-kent-sidr-adverse-actions-00 documents a range of potential 
problems that
can arise in the RPKI. The analysis argues for a broader solution that 
would encompass
the overclaiming problem.

Steve

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Jul 2015 09:27:52 +0900

really do appreciate review.

do not appreciate pdfs of word docs; makes copy paste and commenting
back a major pain.  though i have come to suspect that is one of your
goals.  so i will not comment on your comments in that pdf, though i
adopted/adapted the majority, with which i agreed.  

> - I don't consider myself to be on the hook for a "torn Euro" protocol

back in 2007, you really did say you would do it.  but this year it the
kook kids would use a blockchain contract; that'll be a fun section to
write :)

> - I think the doc should distinguish between transfers of "live"
>   address space vs. transfers of space that is not currently in
>   use. The former are more complex tan the latter and thus merit a
>   different discussion

operationally, you do not have a solid proof of [dis-]use.  and i do not
see how they should be treated differently.  prudence says do it as if it
is live.

> - the text does not yet adequately describe the steps that need to
>   take place when the Buyer or Seller are not directly under a Swing
>   Point.

sent text

> - the TAO doc described a procedure for resource transfer that
>   avoids the concern you cited in Section 5.

good.  when we get to that doc, we can then deal

i did not finish until after the dreadline.  so all will be revealed in
two weeks.  for a small fee, early peeks might be available.

randy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Jul 2015 11:41:59 -0400

Randy,

> really do appreciate review.
you're welcome.
> adopted/adapted the majority, with which i agreed.
I review docs in MS Word, because it makes it easy for me to correct typos
and to precisely identify where comments apply. Because you reject Word
docs, the best accommodation I can offer, given my unwillingness to
adopt a different review mechanism, is to generate a PDF of the Word doc.
I have no trouble copying and pasting text from a PDF, so I don't understand
your comment about the difficulty of copy/paste. I do admit that responding,
inline, to comments inn the PDF format is not easy. It would work fine if
you accepted the Word doc, but ...
> kook kids would use a blockchain contract; that'll be a fun section to
yes, 8 years ago I said that I (the royal I?) could do this. Time passed
and I advised you a couple of years ago that it was not going to happen.
I relayed this news based on advice from Matt Lepinski, who is much
more knowledgeable on these crypto protocols than I. His conclusion was
that the papers published on this sort of mechanism did not yet yield
mature, practical, implementable protocols.
> see how they should be treated differently.  prudence says do it as if it
The TAO I-D describes the differences in constraints imposed on the
transfer process based on live vs. unused space. Unused is much, much easier
and seems to be the most common type of space transferred across RIR 
boundaries.
Thus it seems worth considering the distinction in a discussion of the 
problem.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 8 Jul 2015 13:30:54 -0400

On Jul 7, 2015, at 11:41 AM, Stephen Kent <[email-masked]> wrote:

> and seems to be the most common type of space transferred across RIR boundaries.
> Thus it seems worth considering the distinction in a discussion of the problem.

I wasn't looking for this, but I happened upon an APNIC page that describes transfer processes for three cases: unused space, for M&A, and for historical resources.  Answering their questions to get to the right case never got me to a page that is explicitly about transferring live address space.  M&A are likely to be live and historical could be live, I suppose.  i don't find anything in their policy manual that says transfers are only for unused space.

Here's the page about transfer in general:

https://www.apnic.net/services/become-a-member/manage-your-membership/transfer-resources

I think it would be interesting to hear from the RIR's as to whether they require resources to be unused, and for how long, before a transfer is possible.

That of course does not mean that transfers only occur between RIRs, or that we can always know whether address space is in use.

--Sandy, speaking as a regular ol' member

P.S.  From the APNIC site, here are some interesting flowcharts of the process:

Transfer of unused IPv4 and AS Numbers APNIC account holders (flowchart): https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure%20of%20unused%20IPv4%20and%20AS%20Numbers%20between%20APNIC%20accounts.pdf

Transfer procedure of unused IPv4 from ARIN to APNIC accounts (flowchart): https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure%20of%20unused%20IPv4%20from%20ARIN%20to%20APNIC%20accounts.pdf

detailed diagram for IPv4 transfer from other RIR to APNIC accounts:  https://www.apnic.net/services/become-a-member/manage-your-membership/transfer-resources/ARIN-to-APNIC-IPv4-Transfer-with-Fees.jpg

---

From: Andy Newton <[email-masked]>
Date: Thu, 9 Jul 2015 19:15:34 +0000

On Jul 8, 2015, at 1:30 PM, Sandra Murphy <[email-masked]<mailto:[email-masked]>> wrote:

The reality is that we rarely get transfers of RPKI certified space, but to answer your question: we don’t deny or delay a transfer just because it is RPKI live.

-andy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 10 Jul 2015 16:55:09 -0400

Andy,

In this context "live" refers to address space in use as opposed to 
allocated
but not in use. So your reply doesn't address the question.

Steve

>> I think it would be interesting to hear from the RIR's as to whether 
>> they require resources to be unused, and for how long, before a 
>> transfer is possible.
>
> The reality is that we rarely get transfers of RPKI certified space, 
> but to answer your question: we don’t deny or delay a transfer just 
> because it is RPKI live.
>
> -andy

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jul 2015 14:14:52 -0700

making assumptions if and how address space is or is not used is a
recipe for mistakes and is not really useful.

randy

---

From: Arturo Servin <[email-masked]>
Date: Sat, 11 Jul 2015 22:18:04 +0000

How would you define that address space is unused? Because it is
unannounced to the global BGP table?

Because there is not traffic to it even though is announced?

This question has come up in several policy discussion in almost every RIR,
it has never been consensus on the answer. So we should probably considered
every transfer as been in use.

The draft is a good start, thanks for writing it. As soon as I have some
time I will send some comments.

/as

On Fri, 10 Jul 2015 at 18:15 Randy Bush <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Sat, 11 Jul 2015 20:51:58 -0300

As Arturo mentions, defining 'actual use' of number resources has proved
quite tricky.

The only workable assumption is that space that is marked 'available' or
'reserved' in the delegated-extended files is not in use whereas
everything else is in use, regardless of whether it is announced in the
Internet or not.

Even this assumption could lead to unexpected situations here and there
as there could be space being recovered that is still routed in bgp
while being marked as reserved, not mentioning possible ongoing route
hijacks of 'available' space still getting traffic.

cheers!

-Carlos

On 7/11/15 7:18 PM, Arturo Servin wrote:
> This question has come up in several policy discussion in almost every
> RIR, it has never been consensus on the answer. So we should probably
> considered every transfer as been in use.
> 
> On Fri, 10 Jul 2015 at 18:15 Randy Bush <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Jul 2015 17:36:20 -0700

yup.  we have a long history of trying to assign colors, flavors,
sounds, ... to integers.  it has never worked out very well.

randy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jul 2015 20:26:36 -0400

I disagree.

In this context the entity relinquishing the address space should
know whether the space is in use or not. We ought to be able to
take advantage of this knowledge to simplify the transfer process,
when applicable.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jul 2015 20:35:51 -0400

In the TAO proposal the entity relinquishing the address space is 
presumed to know,
and to declare the transfer accordingly. That seems to be the simplest 
approach,
and if that entity screws up, its users are impacted.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jul 2015 20:37:15 -0400

Carlos,

> As Arturo mentions, defining 'actual use' of number resources has proved
to an outsider maybe, but the entity initiating the transfer presumably 
knows,
right?

There's not need to infer this status from externally observable info.

Steve

---

From: Randy Bush <[email-masked]>
Date: Mon, 13 Jul 2015 19:05:16 -0700

> presumed to know, and to declare the transfer accordingly. That seems
> to be the simplest approach, and if that entity screws up, its users
> are impacted.

and this is the ietf, so who gives a damn about the users?  right.

randy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jul 2015 09:46:31 -0400

Randy,

What I meant to imply is that:
      - because the entity transferring the space knows whether it is is use
      - and because asserting that it isn't, when it is, will adversely 
affect users
         affiliated with that entity
     - therefore the entity in question is motivated to get it right
     - but, in the worst case, the damage is limited to users who could be
       screwed my the same entity due to other careless/erroneous behavior

Steve

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Jul 2015 07:07:29 -0700

> - because the entity transferring the space knows whether it is

as the operators and rirs here keep trying to tell you, this is not a
safe assumption.  unlike you, some of us make mistakes.

>    affect users affiliated with that entity

there are potholes in the road.  this does not mean it is ok to dig more
of them.  in fact, we are trying to reduce them.

randy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jul 2015 10:34:50 -0400

So, your argument is that because a mis-declaration of space as unused vs.
can by an ISP cause harm, we should engineer a transfer model that imposes
additional complexity on what seems likely to be the most common case.

(I assume transfer of unused space is or will be the most common case 
because
it represents the space that is sold and we've been told that RIRs expect a
big increase in transfers due to sales of v4 space.)

I acknowledge the merits of your argument, but I also like to engineer
solutions that optimize for the common case.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Jul 2015 16:41:41 -0400

Sandy,

> I wasn't looking for this, but I happened upon an APNIC page that describes transfer processes for three cases: unused space, for M&A, and for historical resources.  Answering their questions to get to the right case never got me to a page that is explicitly about transferring live address space.  M&A are likely to be live and historical could be live, I suppose.
It's interesting that they make these distinctions, presumably for 
policy purposes.
> i don't find anything in their policy manual that says transfers are only for unused space.
I did not suggested that. What I said was that it seems likely that the 
growing number
of address space transfers will be for unused space, IF the reason for 
the transfer is a sale
of assets. (This seems to be the rationale cited for the growth in v4 
address space transfers.)
And, I noted that it seems attractive to engineer a solution to for 
unused space transfers
IF the solution is simpler than for live space transfers (it is), and IF 
unused space transfers
are the common case.

Randy's view is that it is preferable to engineer a single solution that 
is agnostic
about whether the address space is in use or not, even if that is a more 
complex
solution. His rationale seems to be that its safer to treat all space as 
in use, so as
to avoid the damage to users that arises if the entity transferring the 
space can't
properly classify it properly.

Steve

---

From: Andy Newton <[email-masked]>
Date: Thu, 16 Jul 2015 13:18:33 +0000

On Jul 15, 2015, at 4:41 PM, Stephen Kent <[email-masked]<mailto:[email-masked]>> wrote:

Randy's view is that it is preferable to engineer a single solution that is agnostic
about whether the address space is in use or not, even if that is a more complex
solution. His rationale seems to be that its safer to treat all space as in use, so as
to avoid the damage to users that arises if the entity transferring the space can't
properly classify it properly.

Isn’t the “unused” scenario what we have today? Why do we need a solution for something that is already being accomplished?

-andy

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jul 2015 09:56:36 -0400

Andy,

The context for the discussion is address space transfer in the RPKI 
context.
We don't have an RFC describing how to do that, AFAIK. So, when you say that
this is the scenario we have today, to what are you referring?

Steve
> Isn’t the “unused” scenario what we have today? Why do we need a 
> solution for something that is already being accomplished?
>
> -andy

---

From: Andy Newton <[email-masked]>
Date: Thu, 16 Jul 2015 17:04:03 +0000

On Jul 16, 2015, at 9:56 AM, Stephen Kent <[email-masked]<mailto:[email-masked]>> wrote:

Andy,

The context for the discussion is address space transfer in the RPKI context.
We don't have an RFC describing how to do that, AFAIK. So, when you say that
this is the scenario we have today, to what are you referring?

Steve

On Jul 15, 2015, at 4:41 PM, Stephen Kent <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

-andy

Steve,

Given what I said initially in this thread, I thought we were talking about the same thing. I guess not. We could tease this apart, but is it worth it if “Randy’s view” covers all situations?

-andy

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Jul 2015 06:24:32 +0200

> Randy's view is that it is preferable to engineer a single solution
> that is agnostic about whether the address space is in use or not,
> even if that is a more complex solution. His rationale seems to be
> that its safer to treat all space as in use, so as to avoid the damage
> to users that arises if the entity transferring the space can't

thank you for putting words in my mouth, especially as they are the
correct words :)

> solution for something that is already being accomplished?

in steve's model, one has to implement both.  job security for engineers
:)

randy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 17 Jul 2015 09:40:22 -0400

Andy,

> ...
> Steve,
>
> Given what I said initially in this thread, I thought we were talking 
> about the same thing. I guess not. We could tease this apart, but is 
> it worth it if “Randy’s view” covers all situations?
>
> -andy
Randy's approach covers both cases, at the cost of some added complexity 
for what I suspect
is the most common case. Whether that's preferable to two similar, but 
slightly different
mechanisms, where one is optimized for the (purported) most common case 
is a matter of
engineering taste. The WG will have to decide at some point, when we 
have complete, detailed
proposals for both.

Steve