Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation

From: George Michaelson <[email-masked]>
Date: Mon, 3 Aug 2009 12:14:05 +1000

On 30/07/2009, at 8:59 PM, Geoff Huston wrote:

> WG Chair hat off
>
> It is my impression from the WG discussion at IETF 75 on the  
> interpretation of a ROA that there is a common view that a ROA acts  
> as an implicit "denial" for those route objects that have address  
> prefixes that are more specific than the set of prefixes specified  
> in the ROA, and for those route objects which have originating AS  
> numbers other than those listed in valid ROAs that span the address  
> prefix listed in the route object.
>
> I therefore propose to the WG that I will resubmit draft-huston-sidr- 
> roa-validation-01.txt as draft-ietf-sidr-roa-validation-02.txt on  
> the basis that this appears to be consistent with the discussion I  
> have just heard in the WG meeting this morning.
>
> thanks,.
>
> Geoff
>

As co-author of the draft-ietf-sidr-roa-validation I also observe that  
the WG has no interest in pursuing a BOA based model (an explicit  
denial structure) and that the revised draft therefore aligns with  
people's expectations in documenting the validation process.

-George

---

From: Terry Manderson <[email-masked]>
Date: Sun, 2 Aug 2009 19:56:08 -0700

> people's expectations in documenting the validation process.

It is truly a regrettable situation that the workgroup has been lulled into
this position. A ROA that has an implicit deny creates a major break
scenario since the RPKI system will be in partial deployment for many years,
- the resulting requirement is that every LIR's customers MUST participate
in RPKI else the issuance of the LIR's ROA will invalidate all customer
announcements in the examples provided by Geoff.

I cannot see then, how the RPKI will actually get deployment as it will sit
in a 'too hard' basket. In effect, all ROAs have to be created in a bottom
up mode, yet the resource certs issued top-down.

The BOA provides two functions, to protect the un-used and unallocated
resources from misuse and to allow a partial deployment mechanism in a make
before break process where the LIR can adopt, and issue ROAs, and once all
customers are on board - a BOA can then be issued which then 'locks down'
the prefix.

To adapt the logic pseudo code from Dave Ward's presentation and revert the
understanding of the ROA to _not_ be and implicit 'invalid' but instead
'not_found':

1. query key = <BGP destination, masklen>, data = origin AS
2. result = BGP_PFXV_STATE_NOT_FOUND
3. walk prefix roa_validation table to look for the query key
4. for each matched ³entry² node in prefix roa_validation table,
5.     walk all records with different maxLength values
6.         for each ³record² within range (query masklen <= maxLength)
7.            if query origin AS == record origin AS
8.               result = BGP_PFXV_STATE_VALID
9.               return (result)
10.           endif
11.           prefix_exists = TRUE
12.        endfor
13. endfor
14. walk prefix boa_validation table to look for the query key
15. if matched ³entry² node in prefix boa_validation table (query masklen <=
maxLength)
16.        prefix_exists = TRUE
17. endif
18. if not prefix_exists
19.        walk ASN boa_validation table to look for origin AS
20.        if record found in ASN boa_validation table
21.            ASN_exists = TRUE
22.        endif
23. endif
24. if prefix_exists == TRUE or ASN_exists == TRUE,
25.    result = BGP_PFXV_STATE_INVALID
26. endif
27. return (result)

This allows the ROA to be created by the LIR, but provide a 'soft landing'
for the LIR's customers. eg allow an adoption, and not a flag day. The BOA
isn't an off switch in this case but a very valid and useful explicit deny.

Terry

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 3 Aug 2009 16:41:38 -0400 (Eastern Daylight Time)

> scenario since the RPKI system will be in partial deployment for many years,

Certainly the problems of partial deployment is what motivated the call 
for a set of use cases that would help judge the various proposals for 
validation of BGP routes.

> announcements in the examples provided by Geoff.

Another suggestion has been that an LIR/ISP with RPKI-unaware customers 
would generate the certs and ROAs for that customer.

What do do with the unaware customers will be an important consideration 
in partial deployment and I invite everyone to consider this carefully.

> isn't an off switch in this case but a very valid and useful explicit deny.

Is there a use case in the use case draft that distinguishes this 
validation from that proposed by Dave?

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

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 3 Aug 2009 14:14:24 -0700

Hi Terry,

| It is truly a regrettable situation that the workgroup has been lulled
| into
| this position. A ROA that has an implicit deny creates a major break
| scenario since the RPKI system will be in partial deployment for many
| years,
| - the resulting requirement is that every LIR's customers MUST
| participate
| in RPKI else the issuance of the LIR's ROA will invalidate all customer
| announcements in the examples provided by Geoff.

The customers do not have to participate in the RPKI. The LIR can issue the 
ROA on their behalf, no? In any case, yes, we do assume that the more 
specifics that get sub-allocated should also have a corresponding ROA 
issued. Else they become INVALID in the validation logic. I do not see how
BOAs solve the "make-before-break" problem though. The moment they become
separate instances (RPKI objects vs. prefix announcements in BGP), they can
arrive in any order and a valid prefix can become invalid or vice versa.

| I cannot see then, how the RPKI will actually get deployment as it will
| sit
| in a 'too hard' basket. In effect, all ROAs have to be created in a
| bottom
| up mode, yet the resource certs issued top-down.
| 
| The BOA provides two functions, to protect the un-used and unallocated
| resources from misuse and to allow a partial deployment mechanism in a
| make
| before break process where the LIR can adopt, and issue ROAs, and once
| all
| customers are on board - a BOA can then be issued which then 'locks
| down'
| the prefix.
| 
| To adapt the logic pseudo code from Dave Ward's presentation and revert
| the
| understanding of the ROA to _not_ be and implicit 'invalid' but instead
| 'not_found':
| 
| 1. query key = <BGP destination, masklen>, data = origin AS
| 2. result = BGP_PFXV_STATE_NOT_FOUND
| 3. walk prefix roa_validation table to look for the query key
| 4. for each matched ³entry² node in prefix roa_validation table,
| 5.     walk all records with different maxLength values
| 6.         for each ³record² within range (query masklen <= maxLength)
| 7.            if query origin AS == record origin AS
| 8.               result = BGP_PFXV_STATE_VALID
| 9.               return (result)
| 10.           endif
| 11.           prefix_exists = TRUE
| 12.        endfor
| 13. endfor
| 14. walk prefix boa_validation table to look for the query key
| 15. if matched ³entry² node in prefix boa_validation table (query
| masklen <=
| maxLength)
| 16.        prefix_exists = TRUE
| 17. endif
| 18. if not prefix_exists
| 19.        walk ASN boa_validation table to look for origin AS
| 20.        if record found in ASN boa_validation table
| 21.            ASN_exists = TRUE
| 22.        endif
| 23. endif
| 24. if prefix_exists == TRUE or ASN_exists == TRUE,
| 25.    result = BGP_PFXV_STATE_INVALID
| 26. endif
| 27. return (result)

Having implemented the prototype code for prefix validation, I can only 
say that the above addition creates unnecessary complexity that I would 
like to avoid in implementation ;-) In the BGP code on a router, I would 
like to just have a database of prefix <-> AS mappings (leave the rest to 
the RPKI repository/cache) and perform the prefix origin validation 
from that database. That keeps it simple and efficient.

My $.002,
- Pradosh

---

From: Rob Austein <[email-masked]>
Date: Mon, 03 Aug 2009 17:25:27 -0400

At Sun, 2 Aug 2009 19:56:08 -0700, Terry Manderson wrote:
> 
> It is truly a regrettable situation that the workgroup has been
> lulled into this position.

Kindly tone down the rhetoric.

> A ROA that has an implicit deny creates a major break scenario since
> the RPKI system will be in partial deployment for many years, - the
> resulting requirement is that every LIR's customers MUST participate
> in RPKI else the issuance of the LIR's ROA will invalidate all
> customer announcements in the examples provided by Geoff.

No, the LIR just has to issue ROAs for any of its customers that are
unwilling or unable to generate their own.  The LIR has to know what
resources each of its children has and which of its children are
RPKI-capable in any case, the rest is a small matter of programming.

This has been covered on the mailing list and in presentations to the
WG: see, eg, Randy's slides from the Stockholm meeting just last week.

---

From: Terry Manderson <[email-masked]>
Date: Mon, 3 Aug 2009 14:45:36 -0700

Hi Pradosh,

> The customers do not have to participate in the RPKI. The LIR can issue the

Not "LIR can", "LIR MUST".

That is where I have the issue, the interpretation then drives that the LIR
or LIR customer have no options.

> ROA on their behalf, no? In any case, yes, we do assume that the more

yes, it is one option. The interpretation of ROAs makes it the only option,
as all else is invalid.

> BOAs solve the "make-before-break" problem though. The moment they become

Think through the process not from a clean state RIB, but one where the RPKI
is creeping in.

> arrive in any order and a valid prefix can become invalid or vice versa.

Yes. Though premise is that right now, everything is assumed valid.

> like to avoid in implementation ;-)

As a thought process, think through the prefix validation from two ROAs:
AS0 1.2.3.4/24 maxLength 24
AS32 1.2.3.4/24 maxLengh 24

.. enjoy.

> In the BGP code on a router, I would

I understand that motivation.

So how do you account for the case of prefix not wanting to be routed, lets
say the old B-root prefix that wasn't supposed to have been seen after a
certain date?

> My $.002,

Global Financial Crisis huh? ;-)

Terry

---

From: Terry Manderson <[email-masked]>
Date: Mon, 3 Aug 2009 14:50:47 -0700

> Kindly tone down the rhetoric.

Apologies if you were offended.

> No, the LIR just has to issue ROAs for any of its customers that are

Not "just has to", "MUST issue".

> RPKI-capable in any case, the rest is a small matter of programming.

I'm sorry, I think that is glib. I think It is front ending quite a lot of
work on large LIRs. Small LIRs may not have the resources.

> WG: see, eg, Randy's slides from the Stockholm meeting just last week.

yes. I just don't agree.

Terry

---

From: Rob Austein <[email-masked]>
Date: Mon, 03 Aug 2009 18:22:14 -0400

> work on large LIRs. Small LIRs may not have the resources.

Haven't modeled in detail, but suspect work involved is on roughly the
same order of magnitude as issuing certs to children in the first
place.  A bit more work generating the ROAs themselves, a bit less
work maintaining the provisioning relationship (up-down protocol) with
child.  At worst it's likely a small constant multiplier, eg, 2x.
Bottom line is that an LIR too small to do one is probably too small
to do the other.

---

From: Terry Manderson <[email-masked]>
Date: Mon, 3 Aug 2009 15:36:27 -0700

> arrive in any order and a valid prefix can become invalid or vice versa.

So here is another thought, playing devils advocate and with the
understanding that in a perfect world this would never happen. This
unfortunately isn't a perfect world.

Lets say we are half way through the the RPKI deployment for all LIRs that
have address space in 10/8. Our trusty RIR based in Elbonia does a slight
error and issues a ROA for 10/8 maxLenghth /8; AS65534 - clearly in error.
The downside is that it automatically makes all routes not yet covered by a
ROA be invalid. According to the current interpretation.

Does that not concern you?

Terry

---

From: Rob Austein <[email-masked]>
Date: Mon, 03 Aug 2009 19:15:27 -0400

> Does that not concern you?

It seems likely that your hypothetical Elbonian RIR would also manage
to screw up a combination of ROAs and BOAs.

Sure, screwups near the root of a tree are dangerous.
Adding more ways to screw up does not seem like an improvement.

In any case: I think I've said enough on this topic for a while.

---

From: Terry Manderson <[email-masked]>
Date: Mon, 3 Aug 2009 17:29:43 -0700

> to screw up a combination of ROAs and BOAs.

Probably, however I posit that it would need to be a well orchestrated screw
up of the combination of roas, boas and resource certs to then adversely
affect routing if the ROA semantic was 'not_found' instead of invalid.

> Adding more ways to screw up does not seem like an improvement.

One thing I'm trying to do is minimize the effect of the screw-up. Where the
issuance of one single ROA doesn't have such a widespread and terminal
effect.

> In any case: I think I've said enough on this topic for a while.

dare I say.. ditto.

Terry

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Aug 2009 10:29:38 -0400

At 5:25 PM -0400 8/3/09, Rob Austein wrote:
>...

Does the LIR (ISP) need to know if any of his (RPKI_incapable) 
customers are multi-homed and, if so, to whom they are connected, in 
order to generate ROAs for those paths?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Aug 2009 21:04:19 -0400

I still believe that the ability to make negative assertions seems 
like an important feature for incremental deployment of the RPKI. My 
proposal makes use of ROAs with an AS# of 0 to convey the notion that 
the specified prefixes are NOT to be routed. If you reject any 
advertisements for AS# 0 anyway, would that add any appreciable 
complexity to your code?

Steve

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 4 Aug 2009 21:01:29 -0400

The thread subject line was: "revision to draft-ietf-sidr-roa-validation"
Please allow me to use a new subject line as shown.

I've read through the entire thread, and I am in agreement with Terry on
the need for soft decision during partial deployment and also about
the use of BOA to end the soft decision period for a prefix. 
In Terry's words "... a BOA can then be issued which then 'locks down'
the prefix."
  
I presented a slide at the Stockholm SIDR WG meeting to generate some
discussion on the need for soft decision during incremental adoption. I feel
that the outcome of the discussion was not exactly conclusive. Views were
expressed both ways - to consider suballocation (or more specific prefix)
"Invalid" or treat it softly as "ROA not found" (when there is no requisite
ROA for it). I think some more attention must be paid to details before a
conclusion is reached. I personally find it easier to describe stuff with
slides and diagrams rather than just in words. So I have prepared a set of
slides to highlight the details and propose two solution methods. 
Link to the slides:

http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf 

It will be much appreciated if you can review the material in the slides 
and offer your comments.
(I must admit that Terry has already said in this thread 
some of the material that I have explained in the slides,
but the slides try to put it all in perspective and 
also the idea on slide 6 would perhaps be new to this discussion. 
I am in favor of BOA per use case as illustrated in slide 5. 

Sriram

-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of >Terry Manderson
>Sent: Sunday, August 02, 2009 10:56 PM
>To: [email-masked]
>Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation

---

From: Geoff Huston <[email-masked]>
Date: Wed, 5 Aug 2009 11:31:42 +1000

WG Chair hat OFF

On 05/08/2009, at 11:04 AM, Stephen Kent wrote:

> proposal makes use of ROAs with an AS# of 0 to convey the notion  
> that the specified prefixes are NOT to be routed. If you reject any  

I believe that the validation procedure described in the roa- 
validation working group draft and the pseudo-code the pmohapat draft  
are consistent in that they will mark a prefix described in an AS0 ROA  
as "invalid" as long as there is no other valid ROA that produces a  
"valid" outcome. i.e. with no additional "special case" handling, an  
AS0 ROA would indeed generate the "invalid" outcome and hence act as a  
"negative assertion" in the context of these specifications.

Geoff

---

From: Terry Manderson <[email-masked]>
Date: Wed, 5 Aug 2009 13:51:36 +1000

On 05/08/2009, at 11:31 AM, Geoff Huston wrote:

>> like an important feature for incremental deployment of the RPKI.  
>> My proposal makes use of ROAs with an AS# of 0 to convey the notion  
> validation working group draft and the pseudo-code the pmohapat  
> draft are consistent in that they will mark a prefix described in an  
> AS0 ROA as "invalid" as long as there is no other valid ROA that  
> produces a "valid" outcome. i.e. with no additional "special case"  
> handling, an AS0 ROA would indeed generate the "invalid" outcome and  
> hence act as a "negative assertion" in the context of these  
> specifications.

In essence I agree with Steve that making non-use attestations is an  
important feature. I guess that I diverge there and think of the AS0  
ROA in 4 areas:

1) It overloads AS0 with more meaning than I would personally give it.
2) The AS0 ROA does not allow nor cover the idea that some people  
might want to restrict use of AS numbers as well
3) _If_ a valid ROA does exist for a valid prefix as well as a AS0  
ROA, the decision tree is yet to be mooted.
4) Academically I look on the AS0 ROA as the 'ex falso quodlibet'. eg  
I am making a attestation of use, but in the same breath mandating non- 
use. (it, in itself, is defining a contradiction as the ROA is meant  
to assert route-ability, not the inverse)

That said, I'm more than happy to assist in documenting the AS0 ROA as  
an alternative option as a 50% solution that might be more palatable  
than the idea of a defined RPKI object (eg BOA - that has the well  
known and unambiguous semantics)

I think the validation structure that Geoff speaks of would work,  
provided there is ordering on the handling of a AS0 ROA. Does that  
add  complexity? yes. As much as BOAs? is there collision avoidance? I  
don't yet know I haven't modelled it. Pradosh, penny for your thoughts?

Cheers
Terry

---

From: Larry Blunk <[email-masked]>
Date: Wed, 05 Aug 2009 11:52:56 -0400

Why would an EE Cert be issued for a sub-allocation
if the holder is not prepared to create ROA's for it?
Considerable experience with this scenario with IRR's suggest
that the providers will simply create ROA's for the sub-allocation
if the downstream customer is not SIDR aware (just as providers now
create route objects for sub-allocations to customers who are
not IRR aware).

     Could one simply condition the "Not Found"/"Invalid" decision
based on the existence or non-existence of the EE Cert for the
sub-allocation?   If an EE Cert exists for for the sub-allocation,
but there is no ROA, treat updates for the prefix as "Not Found".
If there is no EE-Cert for the sub-allocation, treat updates for
the prefix as "Invalid".

 -Larry

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 5 Aug 2009 20:27:35 -0400

Please see responses inline.
Sriram

-----Original Message-----
From: Larry Blunk [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2009 11:53 AM
To: Sriram, Kotikalapudi
Cc: Terry Manderson; [email-masked]
Subject: Re: [sidr] Soft Decision during Incremental Adoption

Response:
KS: I heard from folks at Verizon and ARIN that the sub-allocations
can run up to seven levels deep. Many of the children/grandchildren
may be capable of creating their own ROAs but do not exactly 
synchronize with the creation of a ROA by the top level parent.
Considerable level of coordination may be involved here. 
So it may be good to give them some grace period (with soft decision)
before the parent creates a BOA and locks down the prefix.

Response:
KS: I was also thinking about that possibility. I have not thought 
through what the underlying issues may be with EE certs.
I would like to see if others have comments about your idea.

 -Larry

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Aug 2009 21:33:37 -0400

Terry,

	- As the creator of ROas I don't share the view that using an 
AS # of 0 is overloading the semantics :-).

	- I agree that this proposal does not allow one to express a 
negative assertion about ASNs, but I also do not recall a strong cas 
being made for the need to do so.

	- a valid ROA ought mot exist for both an AS 0 and and non-0 
AS. Only the holder of the prefix in question could generate such a 
conflict, and an equivalent conflict could arise w/o the AS 0 
convention.

	- I advocate the AS 0 convention  precisely because it seems 
to fit easily with straightforward implementations of ROA-provcessing 
code. The positive assertion of a ROA is not inverted by this 
convention, but rather the
As # happens to be reserved and this connotes the right semantics. 
(I am sorry that my  command ofLatin is not sufficient to try to 
generate an appropriate phrase to support this argument :-).)

Steve

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Aug 2009 11:46:31 +1000

ἡδέως γὰρ ἀνέχεσθε τῶν ἀφρόνων  
φρόνιμοι ὄντες·

---

From: Geoff Huston <[email-masked]>
Date: Thu, 6 Aug 2009 14:30:17 +1000

> ἡδέως γὰρ ἀνέχεσθε τῶν ἀφρόνων  

Timeo danaos et dona ferentis ?

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 06 Aug 2009 16:57:55 +0400

> to screw up a combination of ROAs and BOAs.
May be it will be more interesting to return to the question "How 
transition period can be performed with "INVALID" paradigm implemented?"

This is more important as I think than inventing of scenarios of 
screwing up something.

Notice with which Terry has started (about long transition period when 
RPKI will start its deployment, if any) contains the crucial problem of 
the project.

So, any schemes which are not allowing smooth coexistence of RPKI and 
non-RPKI parts of the world for a looong period of time simply will not fly.

dol@

---

From: Robert Kisteleki <[email-masked]>
Date: Thu, 06 Aug 2009 23:26:50 +0200

Geoff Huston wrote:
>> ἡδέως γὰρ ἀνέχεσθε τῶν ἀφρόνων φρόνιμοι ὄντες·
> 

A légpárnás hajóm tele van angolnákkal!

Robert

PS: excuses, I couldn't resist

---

From: Terry Manderson <[email-masked]>
Date: Thu, 6 Aug 2009 22:53:42 -0700

Hi Steve,

> AS # of 0 is overloading the semantics :-).

agree to disagree? :-)

> being made for the need to do so.

Assuming that the cidr-report (http://www.cidr-report.org) is accurate:

http://www.cidr-report.org/as2.0/bogus-as-advertisements.html

197 unallocated (bogon) AS's making 1416 prefix announcements.

I believe when we start talking seriously about path validation, this will
become important. I see that as a strong case.

> conflict, and an equivalent conflict could arise w/o the AS 0

Provided the interpretation of a ROA is one that does not have an implicit
deny. 

What would be the interpretation of the following ROAs
10/8 maxlength 32 AS2222
10/16 maxlength 32 AS 0

? 

> As # happens to be reserved and this connotes the right semantics.

So in my readying of the ROA draft, it a ROA conveys the permission of
a ASN to advertise the prefix. How can AS 0 advertise the prefix?
(or am I being picky on wording?)

> generate an appropriate phrase to support this argument :-).)

Based on the thread of quotes that followed, I'll refrain from doing so in
future. :-(

Cheers,
Terry

---

From: Andy Newton <[email-masked]>
Date: Fri, 7 Aug 2009 08:42:12 -0400

>> AS # of 0 is overloading the semantics :-).

I'm inclined to agree with Terry on this, as it falls into the same category
as using HTML comments to define scripts -- yeah it works, but the results
are messy.  Separation of concerns is a best practice in computer systems.
There is a point of clarity as well.  While this seems understandable to
those creating the specs, it might lead to head scratching five years from
now to people who must learn the system.  It is like the maintenance
programmer who has to come back around to the original developer and ask,
"Why did you do this?"

-andy

---

From: Larry Blunk <[email-masked]>
Date: Fri, 07 Aug 2009 10:07:24 -0400

> before the parent creates a BOA and locks down the prefix.

    But we are only concerned with sub-allocations which
also involve Autonomous System boundaries.  (see sidr-arch
section 7.2.1)  This is a considerably smaller subset and does
 not go nearly as deep.   Speaking from our experience as a
provider, we generally frown on customers who wish to
announce a sub-allocation from our space to multi-home and prefer they
get their own PI space.   We've made a few exceptions, but
they are rare.   I can't imagine a situation where we'd permit
this to go 2 levels deep (allowing a sub-allocation of a sub-allocation
to be announced from yet another AS).    I don't see us issuing
CA Cert's to customers given the limited number of cases involved.
We'd simply issue ROA's on their behalf (see option 2 of 7.2.2 in 
sidr-arch).

 -Larry

---

From: Robert Kisteleki <[email-masked]>
Date: Fri, 07 Aug 2009 16:32:13 +0200

> We'd simply issue ROA's on their behalf (see option 2 of 7.2.2 in 

Larry,

AFAIK more than one level deep sub-allocations are a fact of life. "a few 
exceptions", as you put it, is a good enough argument to think about this. 
In an allocation chain of IR->ISP1->ISP2->EndUser the IR or ISP1 does not 
necessarily know about sub-allocations, therefore cannot anticipate what the 
EndUser will do with them. It'd be really sad if an act (like issuing a 
covering ROA) from IR or ISP1 in this case would effectively kill EndUser's 
_other_ announcements. I don't believe we should allow this in a partial 
RPPKI deployment.

> RPKI-capable in any case, the rest is a small matter of programming.

The LIR may now about its children, but does not always to know if its 
*grandchildren* are RPKI capable or not. As a grandchild, you'd be 
completely at the mercy of your grandparent, which sounds scary. I believe 
this issue cannot be solved with "a small matter of programming".

Robert

---

From: Larry Blunk <[email-masked]>
Date: Fri, 07 Aug 2009 11:21:20 -0400

Robert Kisteleki wrote:
> AFAIK more than one level deep sub-allocations are a fact of life. "a 
> few exceptions", as you put it, is a good enough argument to think 
> about this. In an allocation chain of IR->ISP1->ISP2->EndUser the IR 
> or ISP1 does not necessarily know about sub-allocations, therefore 
> cannot anticipate what the EndUser will do with them. It'd be really 
> sad if an act (like issuing a covering ROA) from IR or ISP1 in this 
> case would effectively kill EndUser's _other_ announcements. I don't 
> believe we should allow this in a partial RPPKI deployment.

      Again, this is not simply about sub-allocations, but rather the 
smaller case of
sub-allocations involving autonomous system boundaries.   The allocation 
chain
above is not relevant to SIDR if there is no change in autonomous system.
If EndUser decides to get an AS and wants to punch a hole in the ISP1
aggregate announcement in order to multi-home, that is something that ISP1
would very much need to anticipate and be involved with.

      The case of ISP2 getting an AS and using it to multi-home an
ISP1 sub-allocation is not too un-common (larger ISP1's have
set aside blocks of space for just such cases).    I'm arguing that it
is considerably rarer for EndUser to announce space out of ISP1's
sub-allocation to ISP2.

      It shouldn't be too difficult to do some analysis of BGP tables to
look for such cases.  Perhaps someone has done it already.

> completely at the mercy of your grandparent, which sounds scary. I 
> believe this issue cannot be solved with "a small matter of programming".

    Not scary at all.   As a grandparent, I very much want to
be involved when my grandchild starts messing around with BGP and
wants to announce space out of my allocation.   ISP's have a very
different perspective from RIR's when making an allocation.   RIR's
don't involve themselves in the routing of the sub-allocations,
ISP's do.

 -Larry

---

From: Tony Tauber <[email-masked]>
Date: Fri, 7 Aug 2009 11:15:28 -0700

On Fri, Aug 07, 2009 at 11:21:20AM -0400, Larry Blunk wrote:
> Robert Kisteleki wrote:
>>
>> The LIR may now about its children, but does not always to know if
>> its  *grandchildren* are RPKI capable or not. As a grandchild, you'd
>> be  completely at the mercy of your grandparent, which sounds scary.
>> I  believe this issue cannot be solved with "a small matter of
>> programming".
>

Speaking from my ISP experience, I agree with Larry's sentiments here.

Tony

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Aug 2009 12:43:02 +0900

>> - the resulting requirement is that every LIR's customers MUST
>> participate in RPKI else the issuance of the LIR's ROA will
>> invalidate all customer announcements in the examples provided by
>> Geoff.
> The customers do not have to participate in the RPKI. The LIR can
> issue the ROA on their behalf, no?

they do pay us.  it'll be a simple part of provisioning.  "will you be
generating the roa(s) for your announcements, or do you expect us to?"

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Aug 2009 12:47:10 +0900

> Not "just has to", "MUST issue".

big deal.  and we must connect wires to them.  the list of musts to
provision a customer is rather large.  this one will go with the ones
having to do with accepting their bgp announcement in the first place,
bgp session, filters, and all that.

let us not inflate the trivial.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Aug 2009 12:47:48 +0900

> order to generate ROAs for those paths?

no.  roas do not have paths.

randy

---

From: Terry Manderson <[email-masked]>
Date: Sun, 9 Aug 2009 23:15:12 -0700

> bgp session, filters, and all that.

Ahh I think I see some disjoint here. If this was a clean skin and RPKI was
already deployed, I would agree this would be in the set of processes.

But it isn't, and the LIR/ISP has to go do this dance with all their
customers before they can issue their own ROA. I just don't see that helping
deployment at all.

Terry

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Aug 2009 15:17:51 +0900

> customers before they can issue their own ROA. I just don't see that helping

and this is difficult why?

hint: the operators here seem to see little problem.  do we not have
enough problems without inventing them?

randy

---

From: Terry Manderson <[email-masked]>
Date: Sun, 9 Aug 2009 23:42:01 -0700

> and this is difficult why?

Not saying its difficult. Saying its a block to deployment for a LIR who has
customers that originate the assigned prefix from a separate AS.
But maybe that is what operators want.. always easier to put things in a
'too hard' basket. Always easier to lock those customers in.

> enough problems without inventing them?

What is "here"? this list? where you work?

I don't see this an inventing problems. I think it is realizing that the
mooted interpretation is going to go badly for some in anything but a
complete deployment. I would prefer that we, as a working group, aren't
putting forward something that is going to cause pain. I think there are
enough hairy monsters surrounding this work already.

I'm currently putting together an analysis of this from the DFZ as to
impact. I'll post again in a few days.

T.

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Aug 2009 16:08:09 +0900

> 'too hard' basket. Always easier to lock those customers in.

<BZZZZZT!!!> we do not need the accusations, black helicopters, evil
.*s, ...  thanks for maintaining a polite discussion.

the customer is using a sub-alloc from me.  i have to provision the
circuit, build bgp sessions, ...  and exactly how is helping the lazy
ones to field a roa further locking them in?

> complete deployment.

except this point is far from being made.

> I would prefer that we, as a working group, aren't putting forward
> something that is going to cause pain. I think there are enough hairy
> monsters surrounding this work already.

agree wholeheartedly.

> impact. I'll post again in a few days.

[ side note.  i suggest abandoning the term dfz.  maybe we start saying
  bgp speaking zone or something.  see my iepg preso. ]

---

From: Terry Manderson <[email-masked]>
Date: Mon, 10 Aug 2009 01:32:43 -0700

> .*s, ...  thanks for maintaining a polite discussion.

It wasn't meant as a sideward accusation. I've seen this "business practice"
done by many (gosh just look at v6, DNSSEC, etc). While I don't believe its
the IETF position to discuss a business case for anything, having seen the
effects where excuses are made to not adopt something based on effort level
- I have a genuine concern that allowing excuses like we have to get our
customers to do it first, or we have to do it for our customers (wow that
does sound like v6 ;), will -as already stated- be a hindrance. But hey,
I'll take the WG lead - seems to be a split so far, some want a implicit
deny, some want an explicit deny.

Perhaps we need to think about it in terms of flexibility and utility?

> ones to field a roa further locking them in?

I suspect you might be more helpful than others. It is the case where a LIR
doesn't provision a ROA for the lazy. effectively making their aggregate the
only path to them. A learning exercise for the customer? no doubt. One that
has ramifications beyond trying to implement a form of routing security..

> except this point is far from being made.

I think it is getting there..

Terry

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 10 Aug 2009 10:12:09 -0400

> enough hairy monsters surrounding this work already.

Does this mean there ought to be a deployment doc written as well? I
think that in general the 'eww crypto stuff' card will get pulled out
(a bunch) but if this is relatively painless to setup and maintain
(getting a cert from an RIR shouldn't be too rough in 2009, adding to
your OSS the bits that sign down an assignment to a customer may be
but shouldn't be hard) a lot of the excuses go away.

-Chris

---

From: [email-masked] (Sandy Murphy)
Date: Mon, 10 Aug 2009 15:10:04 -0400 (EDT)

>generating the roa(s) for your announcements, or do you expect us to?"

I can see how this will work during the provisioning process.

Can you say how it will work during initical deployment in an ISP
who has many customers?  Go through the list of all customers, asking
this question?  Go through the list of all mulit-homed customers,
asking this question?  Do you have a record of those who are multi-homed
or would you generate one from RV data?

Etc.

--Sandy

---

From: [email-masked] (Sandy Murphy)
Date: Mon, 10 Aug 2009 17:13:04 -0400 (EDT)

>Not "just has to", "MUST issue".

Terry, could you be specific about what an ISP with a clueless
customer would need to do (generate certs, sign ROAs, etc.) in the
explicit deny case?

Your message of Date: Sun, 2 Aug 2009 19:56:08 -0700

>customers are on board - a BOA can then be issued which then 'locks down'

which leaves me not understanding what happens before all the customers
are on board.

--Sandy

---

From: [email-masked] (Sandy Murphy)
Date: Mon, 10 Aug 2009 17:29:50 -0400 (EDT)

>programmer who has to come back around to the original developer and ask,

A comment on this line of argument (rather than a comment on explicit
vs implicit deny or ROA 0 vs BOA):

Some IETF routing protocols do use distinguished values for certain fields
to convey a particular unique semantics or desired behavior.

Consider OSPF and MAXAGE and LSInfinity.

Consider RIP and the value 16 representing "infinity".

Consider GSTM and the use of 255 for the TTL.

--Sandy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 10 Aug 2009 19:02:52 -0400

I think this might help clarify what Steve's concern is,
which I think several others here also share.
Consider the subnet 198.32.176.0/24 and 
take a look at their connectivity graph:    
http://www.robtex.com/route/198.32.176.0-24.html
>From this graph, four different ASes seem to originate 
this prefix in BGP. The subnet seems directly multi-homed
to four ASes.

Now in the link below, search for 198.32.176.0 and then you
will see that a route record exists with AS4637 but
in BGP there are six ASes (including the four from above graph)
which originate this prefix (note AS4637 in NOT one of them):
http://www.robtex.com/as/as4637.html#bgp
(I think that is meaning of the data, please correct me if I
am wrong.)

One of the ASes that originates this prefix is AS701 (UUNET).
If you look at this url below, the Org name for this prefix 
is EP.NET but AS701 (UUNET) is listed as associated AS. 
http://cqcounter.com/whois/

Perhaps Randy (or others interested) can walk us through 
what happens with RPKI and ROA registrations in this scenario?
I am trying to understand how scenarios like this will be handled.

Sriram  

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush
> Sent: Friday, August 07, 2009 11:48 PM
> To: Stephen Kent
> Cc: Rob Austein; [email-masked]

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 10 Aug 2009 16:27:46 -0700

| I think this might help clarify what Steve's concern is,
| which I think several others here also share.
| Consider the subnet 198.32.176.0/24 and
| take a look at their connectivity graph:
| http://www.robtex.com/route/198.32.176.0-24.html
| From this graph, four different ASes seem to originate
| this prefix in BGP. The subnet seems directly multi-homed
| to four ASes.
| 
| Now in the link below, search for 198.32.176.0 and then you
| will see that a route record exists with AS4637 but
| in BGP there are six ASes (including the four from above graph)
| which originate this prefix (note AS4637 in NOT one of them):
| http://www.robtex.com/as/as4637.html#bgp
| (I think that is meaning of the data, please correct me if I
| am wrong.)
| 
| One of the ASes that originates this prefix is AS701 (UUNET).
| If you look at this url below, the Org name for this prefix
| is EP.NET but AS701 (UUNET) is listed as associated AS.
| http://cqcounter.com/whois/
| 
| Perhaps Randy (or others interested) can walk us through
| what happens with RPKI and ROA registrations in this scenario?
| I am trying to understand how scenarios like this will be handled.

There can be multiple valid ASes that can originate the same address
prefix. It just means that multiple ROAs have to be issued. So I must be
missing the problem definition.

- Pradosh

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 10 Aug 2009 16:58:05 -0700

| In essence I agree with Steve that making non-use attestations is an
| important feature. I guess that I diverge there and think of the AS0
| ROA in 4 areas:
| 
| 1) It overloads AS0 with more meaning than I would personally give it.
| 2) The AS0 ROA does not allow nor cover the idea that some people
| might want to restrict use of AS numbers as well
| 3) _If_ a valid ROA does exist for a valid prefix as well as a AS0
| ROA, the decision tree is yet to be mooted.
| 4) Academically I look on the AS0 ROA as the 'ex falso quodlibet'. eg
| I am making a attestation of use, but in the same breath mandating
non-
| use. (it, in itself, is defining a contradiction as the ROA is meant
| to assert route-ability, not the inverse)

If you think of AS#0 as "just another" AS and perform the validation
logic in the usual way, it should fall into place and most of the above
pitfalls should not arise. i.e. it's not a negative attestation or a
contradiction: AS#0 is the valid owner of the prefix and no one else. So
if the prefix is advertised by another AS, the AS#s will not match and
the result will come out to be INVALID. Your point #3 above also falls
into place easily -- there are more than one ASes that originate the
prefix -- that's a valid case. I am concerned, however, about the
ambiguity with AS#0 -- correlating multiple address ranges that are
completely exclusive by putting them under the bucket of AS#0 (I guess
that's what you meant by point#1 above?). If it can be some other AS in
the allocation chain going all the way to the root, that could be a
better alternative. But I understand that not all the entities in the
chain have ASes.

BTW, is the following a correct summary of the origin validation issues
that have been brought up?

1) Handling sub-allocation and more specifics,
2) Taking care of allocated, but unused (so non-routable) addresses to
entities that do not have an ASN,
3) Non-allocated prefix ranges

- Pradosh

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 10 Aug 2009 19:59:43 -0400

Pradosh:

The context was this email from Steve Kent (copied below)
and Randy's response (which I copied in my previous email).
In the scenario we are looking at, the multiple ASes 
with whom the prefix seems multi-homed belong to
different ISPs (uunet, NTT, eu network AG, etc.).     

Sriram 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Tuesday, August 04, 2009 10:30 AM
To: Rob Austein
Cc: [email-masked]
Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation

Steve

> From: Pradosh Mohapatra (pmohapat) [mailto:[email-masked]]
> Sent: Monday, August 10, 2009 7:28 PM
> To: Sriram, Kotikalapudi; Randy Bush; Stephen Kent
> Subject: RE: [sidr] revision to draft-ietf-sidr-roa-validation
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Aug 2009 10:28:59 +0900

> or would you generate one from RV data?

i know of no one who would use the external irr to traverse their bgp
speaking customer list.  which means there probably are some. :)

perhaps two or three keep serious enough data in internal irr instances,
e.g. ntt, level(3).  but even then, i doubt those are their 'data of
record.'

depending on their scale and level of automation, folk track their
delegated customers by various means from text files, to some commercial
and open source products, to custom apps with sql databases.  but they
do track them.  have to for ip management reasons and to explain space
utilization to upstream allocator(s).

sure, there will be a few slobs and mistakes.  we call that operations.
but the rpki roll-out will shake messes out of the system from iana on
down.  hell, right now, arin and ripe are signing 0/0.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Aug 2009 10:32:09 +0900

> I think this might help clarify what Steve's concern is, which I think
> several others here also share.  Consider the subnet 198.32.176.0/24
> and take a look at their connectivity graph:
> http://www.robtex.com/route/198.32.176.0-24.html >From this graph,
> four different ASes seem to originate this prefix in BGP. The subnet
> seems directly multi-homed to four ASes.
> 
> Now in the link below, search for 198.32.176.0 and then you will see
> that a route record exists with AS4637 but in BGP there are six ASes
> (including the four from above graph) which originate this prefix
> (note AS4637 in NOT one of them):
> http://www.robtex.com/as/as4637.html#bgp (I think that is meaning of
> the data, please correct me if I am wrong.)
> 
> One of the ASes that originates this prefix is AS701 (UUNET).  If you
> look at this url below, the Org name for this prefix is EP.NET but
> AS701 (UUNET) is listed as associated AS.  http://cqcounter.com/whois/
> 
> Perhaps Randy (or others interested) can walk us through what happens
> with RPKI and ROA registrations in this scenario?  I am trying to
> understand how scenarios like this will be handled.

we already had this discussion once, originated by danny.  that's an
exchange point.  in this case, an IX with poorly managed address alloc
data because it is manning's.

randy

---

From: [email-masked]
Date: Tue, 11 Aug 2009 04:36:10 +0000

> data because it is manning's.

	well - the poorly managed bit might be correct - upkeep has
	degenerated over time as the PAIX facility was sold and resold...
	but expect things there to clear up quite a bit in the next few
	months.  S&D has taken a renewed interest getting the cruft corrected.

	regarding the above concern that the same prefix is announced by
	multiple parties...  http://www.ep.net/policy.html  might be instructive.

	if folks think this is "poorly managed" ... they are entitled to their
	opinions.  If you would like Randy to step in here, i'd be pleased to
	hear the offer.

	current planning is to get the RPKI registrations in place with ARIN
	for all EP.NET blocks within the month - and assign certs to any ASN
	that connects.

	presuming the good folks designing this stuff have allowed for that
	operational model...   if not, then I'm sure something else will emerge.

--bill

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Aug 2009 14:26:26 +0900

> 	opinions.  If you would like Randy to step in here, i'd be pleased to

i do not take on tasks i do not have the time to do well.

ep.net reverse delegations have been problematic for years for ixen all
over the bleeping planet.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Aug 2009 00:10:11 +0900

> (b) I was trying to suggest how an ISP might come up with  a list of
> all those customers who need a ROA generated for them.

if it is not already known to us, and it darned well should be, we could
just look at the bgp announcement from the delegated downstream.

the hole is the asn with some of our space who is not announcing it
downstream of us.  but these are special relationships, usually being
kind to emigres, and are tracked.  of course, if they have wandered off
with a chunk of our address space without our consent, then tough
patooties, eh?

this is all just normal day to day ops.  we have to earn our keep
somehow.  if the ops thought this stuff would make an ops mess, we would
be screaming.  as it is, non-ops are saying we have an ops problem.
well, this is one of the rare instances in the ietf where the ops
actually got in early.  and we don't need representation.

> Only those customers who are multi-homed need a ROA

close.  those announcing from a different asn.

> You missed the base question: do you envision an ISP on initial
> deployment asking a long list of customers if they want a ROA signed
> for them?

more like tell them that they can get certs and roas by using our web
interface, run certware, or whatever.  go to http://whatever/ and read
all about it and follow one of thr recipies.  and also tell them not to
worry, if they don't want to do it right off, we'll do it for them.  we
are paid to make their packets move.

believe it or not, we do have operational relationships with customers.
strange as i guess it seems to much of this crowd, we are in business,
and business is about customers and service.  we don't just suck their
blood and shoot them from black helicopters.  we only do that on odd
numbered days.

randy