Subject: [sidr] I-D Action:draft-ietf-sidr-arch-06.txt

From: [email-masked]
Date: Mon, 9 Mar 2009 16:30:01 -0700 (PDT)

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           : An Infrastructure to Support Secure Internet Routing
	Author(s)       : M. Lepinski, S. Kent
	Filename        : draft-ietf-sidr-arch-06.txt
	Pages           : 24
	Date            : 2009-03-09

This document describes an architecture for an infrastructure to 
support improved security of Internet routing. The foundation of this 
architecture is a public key infrastructure (PKI) that represents the 
allocation hierarchy of IP address space and Autonomous System 
Numbers; and a distributed repository system for storing and 
disseminating the data objects that comprise the PKI, as well as 
other signed objects necessary for improved routing security. As an 
initial application of this architecture, the document describes how 
a legitimate holder of IP address space can explicitly and verifiably 
authorize one or more ASes to originate routes to that address space. 
Such verifiable authorizations could be used, for example, to more 
securely construct BGP route filters.

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Terry Manderson <[email-masked]>
Date: Wed, 11 Mar 2009 16:54:22 +1000

Stephen and Matt,

I raise the following after reading sidr-arch-06 in light of the  
recent rescerts and ta draft versions.

Section 2.5 ERX.

With the recent change in suggested TA behaviours (the ETA and RTA)  
I'm not sure I see any reason to have the multiple CAs as represented.  
The RTA allows the *IR to grow or shrink the resource holdings in the  
RTA without having to adjust the RP TA (ETA). Wouldn't it be far  
simpler to make the transfers (ERX and others to come) an  
administrative function and co-ordination between the TA organisations  
at that level where resources are listed in the 3779 attributes  
following the paradigm that no two TA organisations can be  
authoritative for the same information? (in that model)

Also thinking to the future of more transfer arrangements, following  
recent RIR policy processes. (while not specifically an IETF issue,  
has flow on effect)

Additionally, the structure proposed implies to me that the ERX block  
would go back to the originated RIR if relinquished (handed back) by  
the holder. I'm not clear that this is the case. Last time I traversed  
the policy on this I thought the resource remained with the _current_  
RIR for reallocation. (but could be wrong - I couldn't find anything  
in the ERX faqs @ the RIR websites to confirm/deny)

If you do maintain this structure, the description for the diagram  
(figure 1) says "EXR" not "ERX".

Cheers
Terry

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 11 Mar 2009 09:17:41 +0100

Terry Manderson wrote:
[...]
> would go back to the originated RIR if relinquished (handed back) by the 
> holder. I'm not clear that this is the case. Last time I traversed the 
> policy on this I thought the resource remained with the _current_ RIR 
> for reallocation. (but could be wrong - I couldn't find anything in the 
> ERX faqs @ the RIR websites to confirm/deny)

AFAIK there is no policy for this yet. There may be one soon.

Robert

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Mar 2009 03:46:06 -0700

> AFAIK there is no policy for this yet. There may be one soon.

why should ephemeral political policy be enshrined in the TA structure?

randy

---

From: Terry Manderson <[email-masked]>
Date: Thu, 12 Mar 2009 11:01:31 +1000

Hi Robert,

On 11/03/2009, at 6:17 PM, Robert Kisteleki wrote:

> Terry Manderson wrote:
> [...]
>> Additionally, the structure proposed implies to me that the ERX  
>> block would go back to the originated RIR if relinquished (handed  
>> back) by the holder. I'm not clear that this is the case. Last time  
>> I traversed the policy on this I thought the resource remained with  
>> the _current_ RIR for reallocation. (but could be wrong - I  
>> couldn't find anything in the ERX faqs @ the RIR websites to  
>> confirm/deny)
>

In which case I would be inclined to treat ERX no differently to other  
resources. Allowing the RTA to grow and shrink as necessary for ERX or  
other transfers which makes for less complexity and confusion in the  
structure - and that I think should pursued. It would then allow all  
permutations of policy to work without incorrectly asserting what the  
politics should be.

eg
RIR 1 retains allocation
RIR 1 returns allocation to RIR 2
RIR 2 hands allocation back to the IANA
.. and several others.

Terry

---

From: Robert Loomans <[email-masked]>
Date: Thu, 12 Mar 2009 11:27:26 +1000

> ... where resources are listed in the 3779 attributes following the
> paradigm that no two TA organisations can be authoritative for the
> same information? (in that model)

I'm not sure that's a valid assumption. I believe that this would
preclude make-before-break transfers.

Rob

-- 
Robert Loomans                         email:       [email-masked]
Senior Software Engineer, APNIC        sip:    [email-masked]
http://www.apnic.net/                  phone:         +61 7 3858 3100

---

From: Terry Manderson <[email-masked]>
Date: Thu, 12 Mar 2009 11:49:53 +1000

> preclude make-before-break transfers.

I don't remember seeing the a make-before-break issue raised in any  
draft, can you point me to a reference?

In mooted transfers of resources from one company on one side of the  
world and under RIR 1 to a company on the other side of the world  
under RIR 2 I really don't see that a make before break argument  
applies. And really - we are talking about cert re-issuance times of  
24 hours or less. I'd wager that business process would take longer  
than the cert dance.

Terry

---

From: Rob Austein <[email-masked]>
Date: Thu, 12 Mar 2009 00:27:28 -0400

> draft, can you point me to a reference?

May not have gotten into any draft, but keeping routing live has
certainly been an assumed requirement for some of us. :)

> 24 hours or less. I'd wager that business process would take longer  

Think about corporate acquisitions for a moment.  EngulfAndDevour,
headquartered in region A, buys MomAndPopISP, in region B.
MomAndPopISP is a going concern whose founders want to retire, grow
tomatoes, and deal with no unit of time shorter than a season.
EngulfAndDevour has paid heavily for good will of MomAndPopISP's
customer base and wants MomAndPopISP's routing to continue to work
during transfer of MomAndPopISP's resources from region B to region A.
Any downtime at all is unacceptable.  Hence make-before-break.

---

From: Terry Manderson <[email-masked]>
Date: Thu, 12 Mar 2009 15:23:29 +1000

> certainly been an assumed requirement for some of us. :)

Not saying it isn't - just observing that I don't recall reading that  
clearly fundamental requirement :)

> Any downtime at all is unacceptable.  Hence make-before-break.

As a corporate acquisition, wouldn't EngulfAndDevour using its  
acquired relationships ask for some strong co-ordination between  
region A's RIR and region B's RIR? Perhaps requesting that their  
certificate shift and re-issuance (and ROA move) happen in a near  
simultaneous fashion at UTC 0100hrs? I would have hoped to count on  
such organisations to be well coordinated.

But wasn't this structure for ERX? Not for general corporate take-overs?

Further - and this is probably just me, but if the co-ordination  
function cannot be counted on - I don't think I would be moving  
resources from one region to another, when network downtime is  
unacceptable. (maybe that is too sensible ;)

As stated, I would much prefer that the structure be as simple as  
possible, and the co-ordination function be improved through some  
inter-RIR brokerage/exhange/transfer protocol. I wonder (just thinking  
aloud) if there would be dire consequences of a 24hr overlap in  
information. Clearly a question about RP decision time if the ROAs  
differ.. but other than that? (maybe a @beers discussion)

Terry

---

From: Heather Schiller <[email-masked]>
Date: Thu, 12 Mar 2009 10:44:11 -0400

> Any downtime at all is unacceptable.  Hence make-before-break.

Why would this acquisition result in an inter-RIR transfer of the 
resource?  Wouldn't EngulfAndDevour go to RIR in region B and say "Hi we 
acquired MomAndPopISP, please update the company name on the record" 
Isn't that how it is done today?

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Mar 2009 07:50:17 -0700

> resource?

cert validation chain swing

---

From: Heather Schiller <[email-masked]>
Date: Thu, 12 Mar 2009 11:02:16 -0400

> cert validation chain swing

Sorry Randy, you were too terse or I'm too dense.  I'm still not following.

Rob said: "..during transfer of MomAndPopISP's resources from region B 
to region A."

  I don't understand *why* the resource would move from region B to 
region A in the given example?  Maybe I misunderstood and the author 
didn't intend to imply that the resource would move between regions?  I 
do understand that the cert and name on file in region B would have to 
be updated, and understand that they would want it done quickly and 
efficiently.

   I would be interested to know if resources are being transferred 
between RIR's today as part of corporate acquisition/divestitures. 
AFAIK, they are not.  If that is the case, I don't understand why it 
would change (given current policies and practices) with the SIDR work, 
as the work here would not change the policy underwhich a resource could 
be moved.

  --heather

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Mar 2009 08:41:20 -0700

> region A in the given example?

the buyer and seller prefer doing business in their 'home' regions.
figuring out one rir's bureacrazy is hard enough, and does not
contribute to the bottom line.

randy

---

From: "K. Sriram" <[email-masked]>
Date: Thu, 12 Mar 2009 12:45:11 -0400

I am curious as to what happens if MomAndPopISP's address space has a 
ROA in region B
created by a higher-tier ISP, say BigISP, in region B.
Let us say BigISP is an ISP one level higher in the hierarchy above 
MomAndPopISP.
As a result, it appears that EngulfAndDevour in Region A would also need
cooperation of BigISP in Region B to first revoke the existing ROA before
it can create a new ROA for MomAndPopISP in its own region (Region A)?
What incentive will BigISP have to cooperate and help EngulfAndDevour
without causing delays?

Sriram  

-- 

K. Sriram 
+1 301 975 3973
http://www.antd.nist.gov/~ksriram/

---

From: Heather Schiller <[email-masked]>
Date: Thu, 12 Mar 2009 13:03:56 -0400

> contribute to the bottom line.

Taking off the SIDR hat for a moment.. I don't think there is currently 
policy/practice that allows this.  If there is, I'd really appreciate 
someone quoting the policy - or providing examples of where this has 
happened (non-ERX, non-RIR startup examples)

If transfers aren't currently permitted - there isn't a problem.  If 
transfers are currently permitted, or might be in the future (see the 
"Allocation of IPv4 Blocks to Regional Internet Registries" proposal) 
Then I can understand the fuss.  I'd just like to know if there is 
actually a problem to solve here.

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Mar 2009 10:08:26 -0700

> policy/practice that allows this.

as rir policies seem rather ephmeral, perhaps we should not limit
technology to the current ones.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 12 Mar 2009 13:37:23 -0500 (Eastern Standard Time)

On Thu, 12 Mar 2009, Heather Schiller wrote:

>
>
> Randy Bush wrote:
>>> I don't understand *why* the resource would move from region B to region A 
>>> in the given example?
>> 
> policy/practice that allows this.  If there is, I'd really appreciate someone 
> quoting the policy - or providing examples of where this has happened 
> (non-ERX, non-RIR startup examples)
>
> "Allocation of IPv4 Blocks to Regional Internet Registries" proposal) Then I 
> can understand the fuss.  I'd just like to know if there is actually a 
> problem to solve here.

I don't know if this answers your question, but APNIC reached consensus on 
(and is in last call on) a transfer policy at the last meeting, which says 
in part:

   4.6 Address transfers are permitted between APNIC account holders and
   other RIR account holders, following the policies of all the respective
   RIRs.

I found this at: http://www.apnic.net/policy/proposals/prop-050-v004.html

And RIPE has a "transfer of allocations" section in their policy manual 
(http://www.ripe.net/ripe/docs/ripe-449.html#55)
that is a bit more complicated.  It is clear that only RIPE members can 
receive a transfer, so transfers to other RIRs are out.  The section talks 
about both "re-allocation" and "transfer", but it looks like those are 
synonymous.  The wording also makes it look like you can only transfer an 
allocation that was a direct allocation to you, i.e, if your address space 
is a sub-allocation from a different ISP, you can't transfer it to anyone 
else. Maybe that's to keep the book-keeping sane.

And I might have mistaken your question entirely and be pointing to things 
that you are well aware of.

--Sandy

---

From: Terry Manderson <[email-masked]>
Date: Fri, 13 Mar 2009 09:11:48 +1000

On 12/03/2009, at 3:23 PM, Terry Manderson wrote:
> inter-RIR brokerage/exhange/transfer protocol. I wonder (just  
> thinking aloud) if there would be dire consequences of a 24hr  
> overlap in information. Clearly a question about RP decision time if  
> the ROAs differ.. but other than that? (maybe a @beers discussion)
>

Could the following option be valid to maintain structural simplicity,  
thinking that certificates have both a space function, and a time  
function?

(and noting that this is not a ERX transfer)

EngulfAndDevour acquires MomAndPopISP.
EngulfAndDevour advises both RIRs of the purchase
EngulfAndDevour advises that at 0100hrs UTC on a future date all  
resources (ROAs et al) are transferred to RIR 1.
RIR 1 advises RIR 2 to reissue all of MomAndPopISP resources (ROAs et  
al) with a validity period that ends at 0059:59hrs UTC on that date
RIR 1 issues the old MomAndPopISP resources for EngulfAndDevour with a  
validity period that begins at 0100hrs UTC on that future date.

Through all this, routing will still work, RPs don't have a confusing  
decision to make (validity time takes care of that), no TAs are making  
conflicting statements due to the time principle, and the structure of  
the RPKI is simple such that RIRs aren't maintaining CAs of other  
RIRs, further (and based on a brief email discussion with on RIR  
policy staff) the resources transferred to an RIR under would stay at  
that rir, until another transfer event (ERX included). But as randy  
says, RIR policy are subject to change - best to design this to avoid  
codifying that in a standard where possible.

Terry

---

From: Terry Manderson <[email-masked]>
Date: Fri, 13 Mar 2009 10:10:20 +1000

Sriram,

On 13/03/2009, at 2:45 AM, K. Sriram wrote:

> I am curious as to what happens if MomAndPopISP's address space has  
> a ROA in region B

That means, most likely, that the resources listed in the ROA are  
allocated to BigISP and I would presume that MomAndPopISP were simply  
'renting' the resources from BigISP. Otherwise MomAndPopISP would  
probably create their own ROA if it were PI space.

> it can create a new ROA for MomAndPopISP in its own region (Region A)?

In that case MomAndPopISP are irrelevant - the transfer is then from  
BigISP to
EngulfAndDevour.

> What incentive will BigISP have to cooperate and help EngulfAndDevour

All and none. It depends on the business relationship between the two  
since the resources sound like they are allocated to BigISP, not  
MomAndPopISP.

Terry

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Mar 2009 22:11:22 -0700

> validity period that begins at 0100hrs UTC on that future date.

factor in cert/roa propagation delays of a day or two

randy

---

From: Terry Manderson <[email-masked]>
Date: Fri, 13 Mar 2009 15:33:31 +1000

> factor in cert/roa propagation delays of a day or two

Right, not a last minute activity.. cert issue events need to happen  
in advance for propagation.

T.

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Mar 2009 22:52:46 -0700

> in advance for propagation.

which we have been caling "make before break."  but we have assumed a
lot of user control so the blame is on them when their routing breaks as
opposed to automating and finding we need to apologize to some lawyers
that it was optimistic.

randy

---

From: Terry Manderson <[email-masked]>
Date: Fri, 13 Mar 2009 16:02:57 +1000

> opposed to automating and finding we need to apologize to some lawyers

I don't think this negates the idea of still having the RTA grow/ 
shrink versus multi-subordinate other-RIR CAs under a RIR TA. (ie  
using timed validity to effect a settlement time)

But I'll think on this more - while I accept the role of lawyers in  
modern society, I would prefer to not have bloat in the structure  
because of them or other organisational effects.

Terry

---

From: <[email-masked]>
Date: Thu, 12 Mar 2009 15:05:01 -0000

unsubscribe

---

From: Danny McPherson <[email-masked]>
Date: Sat, 14 Mar 2009 08:54:29 -0600

> in advance for propagation.

And, of course, accommodate the model where the operator
"aborts" for any of an array of reasons.  There's a
critical operational role for RIRs here, and they'd well
better be prepared to act in that capacity.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Sat, 14 Mar 2009 08:56:52 -0600

> What incentive will BigISP have to cooperate and help EngulfAndDevour

The distinction here is PI v. PA space.  You shouldn't
see this happening for PA space.

-danny

---

From: "Barry Raveendran Greene" <[email-masked]>
Date: Sat, 14 Mar 2009 08:37:38 -0700

> There's a critical 
> operational role for RIRs here, and they'd well better be 
> prepared to act in that capacity.

We're assuming that the RIRs are going to fund and staff for this
operational role. That is assumption that would lead to disappointment and
operational impact.

Some may view this as a outside party imposing cost. 

IMHO - we need the RIR's to formally sign up - stating that they are willing
to take on this operational role with the proper funding to support long
term.