Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt

From: Stephen Kent <[email-masked]>
Date: Mon, 1 Dec 2008 11:23:23 -0500

At 6:12 PM -0600 11/24/08, George Michaelson wrote:
>Some people now appear to want an *implicit* meaning of 'if not in 
>ROA, then excluded' -but, they also somehow want this to be 
>conditional.

I an incremental deployment context, a context with which we will 
have to deal for several (many?) years, we can't reject all 
assertions that are not verifiable via use of ROAs.

>Secondly, there is a semantic difference between 'all which is not 
>explicitly permitted is forbidden' and 'this is explicitly 
>forbidden'.

ibid.

>We have tried to make an explicit semantic around the word NOT:
>
>	NOT prefix <x>/<y>
>
>ie do NOT accept <x>/<y> as a valid route. Thats what a BOA says. 
>its explicit what prefixes are being knocked out.
>
>Others seem to want an *implicit* NOT. But, it appears to be a 
>conditionally implicit NOT: how can you decide when it does, or does 
>not apply?
>
>This is of course two different problems:
>
>1) how do you conditionally flag it does or doesn't apply? The ROA 
>has no syntax for this
>2) what is the scope of the "NOT" logic?
>
>in an explicit (BOA) world, the scope can be any prefix(s) you like: 
>its an explicit statement of intent around the NOT word.

a BOA cannot make assertions about prefixes the issues does not 
control, so the statement above is not quite true.

>in a world of ROA only, the only NOT you can have is "anything else" 
>so its demonstrably semantically weaker.

I proposed issuing a ROA with an AS of 1, so that it would explicitly 
"trump" any non-authenticated assertions about the prefix(es) in 
question. That is a counter to the generally less-powerful ROA 
semantics, yet it requires no new processing by relying parties. 
That's why I prefer a ROA-based approach to a BOA-based approach.

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

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Dec 2008 15:34:19 -0700

On Nov 25, 2008, at 6:39 PM, Geoff Huston wrote:
>
> Sure. So here's some use cases of BOAs:
>
> 1. I have been allocated 203.10.61.0/24. I do not use it today in  
> any public routing context. It should not appear in BGP at all. I do  
> not give my authorization to any AS to originate a route for this  
> prefix, or any more specific of this prefix. If I generate a BOA for  
> 203.10.61.0/24 then my intention of saying that any use of this  
> prefix in the public Internet is unauthorized is clear.

If you do not give your authorization then do not issue a ROA.
With the incremental deployment argument, I'm not sure who would
be looking at BOAs if they're not looking at ROAs.

> 2. I have been allocated AS 131074 as an AS number. I do not use it  
> today in any public routing context. It should not appear in BGP at  
> all either as an origination AS nor as a transit AS in any AS path.  
> If I generate a BOA for AS131074 then my intention of saying that  
> any use of this AS number in the public Internet is unauthorized is  
> clear.

But the draft currently does not mitigate "nor as a transit AS",
unless I'm missing something.  Specifically:

S.5 graf 2:

"If a route object has an AS origination that refers to an AS number  
that is listed in a valid BOA, then the route object can be regarded  
as a Bogon object, and local policies that apply to Bogon AS's can be  
applied to the object. This holds whether or not the address prefix of  
the route object is described by a valid ROA or not."

I see nothing about "or as a transit AS" in there.

> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any  
> more specific advertisement of this prefix is unauthorized. If I  
> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my  
> intention is clear.

I still don't by it..  As an operator, you tell me who is authorized
to originate and that's the only origin AS I accept.  That's easier to
configure in a router, requires less objects in the RPKI, and makes life
much simpler.

> And a non-use case of BOAs:
>
> 4. I am a wholesale ISP, and while I allocate address space to my  
> clients from my aggregate address block (10.0.0.0/8) I also permit  
> my clients to use their more specific prefix at local exchanges. My  
> AS number is 131072 and I have generated a ROA for 10.0.0.0/8 ,  
> maxlength=8  origin AS 131072. I do not have a problem with more  
> specifics of 10.0.0.0/8 being used in routing contexts, as part of  
> my wholesale stance. I would prefer that my ROA did not cause my  
> customer's more specifics to be treated as unauthorized routes,  
> irrespective of whether they are ready to use a ROA today or not.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Dec 2008 15:35:12 -0700

BOA I-D authors,
Perhaps some of my confusion from this discussion stems from
the use of the term "bogon".  So, with that, I have two more
questions I'm hoping will help clarify the goals here for me.

1) Given the use of the term "bogon" within sidr today, it's
clearly much wider than the traditional "unallocated from
IANA or an RIR" AS number or prefix.  Exactly what is a "bogon"
in your mind, and shouldn't it be spelled out in the draft?
The use of the term "invalid" recurs throughout, but what
constitutes a bogon here appears to be well beyond today's
operational interpretation of such a term.  Projecting this
effort under the auspices of "bogons" as we know them today
seems a bit inadequate.

2) The BOA draft suggests that if a valid ROA exists for a
given prefix then a BOA should be disregarded.  Can you explain
to me where or why this apparent conflict would occur?

3) Also, I'm still not entirely up to speed here, but say, as
an ISP, I issue a ROA for a prefix I want to permit another
AS to originate.  IF a BOA exists for the AS originating the
route then according to the BOA draft "local policies" should
be enacted (e.g., drop the "route object").  However, if for
a prefix, then if a ROA exists it should essentially trump the
BOA.  Could you explain the logic behind this text?

Thanks!

-danny

---

From: Geoff Huston <[email-masked]>
Date: Tue, 2 Dec 2008 10:00:14 +1100

WG Chair hat off

On 02/12/2008, at 9:34 AM, Danny McPherson wrote:

>> any public routing context. It should not appear in BGP at all. I  
>> do not give my authorization to any AS to originate a route for  
>> this prefix, or any more specific of this prefix. If I generate a  
>> BOA for 203.10.61.0/24 then my intention of saying that any use of  
>> this prefix in the public Internet is unauthorized is clear.
>

I'm sorry, but I cannot see any logic in that response. If I do not  
give my authorization and I would like to inform everyone else that  
any use of this address, or this AS is an instance of a hijack then  
your response seems to be saying to me that I should not do anything.  
If that is what you are saying then it seems to be a totally  
ineffectual course of action in my opinion.

> as a Bogon object, and local policies that apply to Bogon AS's can  
> be applied to the object. This holds whether or not the address  
> prefix of the route object is described by a valid ROA or not."
>

My apologies - we are not allowed to talk about transit yet as its not  
an agreed requirement coming out of RSPSEC. So if I remove "nor as a  
transit AS" and sundry words then I trust that the point I was making  
is amply clear.

> configure in a router, requires less objects in the RPKI, and makes  

No security at all makes like enormously simpler.  At some point it is  
necessary to understand what makes a robust security environemnt even  
in a world of partial use and piecemeal adoptions and then work  
through the issues related to operational deployment. But you appear  
to have some other approach in mind.

>> irrespective of whether they are ready to use a ROA today or not.

Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 1 Dec 2008 18:12:39 -0500 (Eastern Standard Time)

On Mon, 1 Dec 2008, Danny McPherson wrote:

>> 1. I have been allocated 203.10.61.0/24. I do not use it today in any 
>> public routing context. It should not appear in BGP at all. I do not give 
>> my authorization to any AS to originate a route for this prefix, or any 
>> more specific of this prefix. If I generate a BOA for 203.10.61.0/24 then 
>> my intention of saying that any use of this prefix in the public Internet 
>> is unauthorized is clear.
>

The issue in incremental deployment is not what the people who haven't 
deployed it should do but what the people who DO deploy it should do. 
What do the people who DO understand ROAs(and BOAs) do when they see 
something unsecured - it might be legit, just not produced by someone who 
understands ROAs(BOAs).

>
>> 2. I have been allocated AS 131074 as an AS number. I do not use it today 
>> in any public routing context. It should not appear in BGP at all either as 
>> an origination AS nor as a transit AS in any AS path. If I generate a BOA 
>> for AS131074 then my intention of saying that any use of this AS number in 
>> the public Internet is unauthorized is clear.
>
> "If a route object has an AS origination that refers to an AS number that is 
> listed in a valid BOA, then the route object can be regarded as a Bogon 
> object, and local policies that apply to Bogon AS's can be applied to the 
> object. This holds whether or not the address prefix of the route object is 
> described by a valid ROA or not."
>
>> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any more 
>> specific advertisement of this prefix is unauthorized. If I generate a BOA 
>> for 203.10.60.0/23 AND 203.10.62.0/23 then my intention is clear.
>

So it seems you are in the "and that's all" camp in interpreting ROAs, 
right?

Does your answer assume operators are using ROAs to produce route filters? 
Does your answer change if operators are using ROAs in the decision 
procedure, as presented at the last meeting?

--Sandy

>> 4. I am a wholesale ISP, and while I allocate address space to my clients 
>> from my aggregate address block (10.0.0.0/8) I also permit my clients to 
>> use their more specific prefix at local exchanges. My AS number is 131072 
>> and I have generated a ROA for 10.0.0.0/8 , maxlength=8  origin AS 131072. 
>> I do not have a problem with more specifics of 10.0.0.0/8 being used in 
>> routing contexts, as part of my wholesale stance. I would prefer that my 
>> ROA did not cause my customer's more specifics to be treated as 
>> unauthorized routes, irrespective of whether they are ready to use a ROA 
>> today or not.
>
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Dec 2008 08:30:34 +0900

> Does your answer assume operators are using ROAs to produce route
> filters? Does your answer change if operators are using ROAs in the
> decision procedure, as presented at the last meeting?

from my pov, no

randy

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 1 Dec 2008 16:05:28 -0800

Hi Geoff,

| >> 1. I have been allocated 203.10.61.0/24. I do not use it 
| today in any 
| >> public routing context. It should not appear in BGP at 
| all. I do not 
| >> give my authorization to any AS to originate a route for 
| this prefix, 
| >> or any more specific of this prefix. If I generate a BOA for 
| >> 203.10.61.0/24 then my intention of saying that any use of this 
| >> prefix in the public Internet is unauthorized is clear.
| >
| > If you do not give your authorization then do not issue a ROA.
| > With the incremental deployment argument, I'm not sure who would be 
| > looking at BOAs if they're not looking at ROAs.
| 
| I'm sorry, but I cannot see any logic in that response. If I 
| do not give my authorization and I would like to inform 
| everyone else that any use of this address, or this AS is an 
| instance of a hijack then your response seems to be saying to 
| me that I should not do anything.  
| If that is what you are saying then it seems to be a totally 
| ineffectual course of action in my opinion.

What if: when "I have been allocated 203.10.61.0/24", I issue an
ROA for the same with my origin AS? Doesn't that automatically
mean that all the advertisements of the prefix from another origin
AS are automatically invalid? And since I will not be generating
any updates for this prefix, it will not appear in BGP at all!
Doesn't that solve the problem you cited? Are you concerned that
some other AS would also issue an ROA for the same or a more
specific block of the prefix? That can't be!

| >> 2. I have been allocated AS 131074 as an AS number. I do 
| not use it 
| >> today in any public routing context. It should not appear 
| in BGP at 
| >> all either as an origination AS nor as a transit AS in any AS path.
| >> If I generate a BOA for AS131074 then my intention of 
| saying that any 
| >> use of this AS number in the public Internet is unauthorized is 
| >> clear.
| >
| > But the draft currently does not mitigate "nor as a transit AS", 
| > unless I'm missing something.  Specifically:
| >
| > S.5 graf 2:
| >
| > "If a route object has an AS origination that refers to an 
| AS number 
| > that is listed in a valid BOA, then the route object can be 
| regarded 
| > as a Bogon object, and local policies that apply to Bogon 
| AS's can be 
| > applied to the object. This holds whether or not the 
| address prefix of 
| > the route object is described by a valid ROA or not."
| >
| > I see nothing about "or as a transit AS" in there.
| 
| My apologies - we are not allowed to talk about transit yet 
| as its not an agreed requirement coming out of RSPSEC. So if 
| I remove "nor as a transit AS" and sundry words then I trust 
| that the point I was making is amply clear.

How important is the case of "AS protection" as opposed to
"prefix" protection? Doesn't this automatically become a
by-product of ROA level checks?

| >> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any 
| >> more specific advertisement of this prefix is unauthorized. If I 
| >> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my 
| >> intention is clear.
| >
| > I still don't by it..  As an operator, you tell me who is 
| authorized 
| > to originate and that's the only origin AS I accept.  
| That's easier to 
| > configure in a router, requires less objects in the RPKI, and makes 
| > life much simpler.
| 
| 
| No security at all makes like enormously simpler.  At some 
| point it is  
| necessary to understand what makes a robust security 
| environemnt even  
| in a world of partial use and piecemeal adoptions and then work  
| through the issues related to operational deployment. But you appear  
| to have some other approach in mind.

As others have suggested, when "I have been allocated 203.10.60.0/22",
I issue an ROA for 203.10.60.0/22-22. That automatically means that
there can't be any other advertisements for this prefix or its more
specifics (unless I suballocate a more specific block and a new ROA
gets added to the repository for that]. Is there any case that's not 
handled by doing this?

- Pradosh

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Dec 2008 09:08:27 +0900

> AS are automatically invalid?

no, not if roas exist for them too.  while having the same prefix
announced by multiple ass is unusual, it is valid practice.  think anycast.

randy

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 1 Dec 2008 16:14:57 -0800

| > What if: when "I have been allocated 203.10.61.0/24", I 
| issue an ROA 
| > for the same with my origin AS? Doesn't that automatically 
| mean that 
| > all the advertisements of the prefix from another origin AS are 
| > automatically invalid?
| 
| no, not if roas exist for them too.  while having the same 
| prefix announced by multiple ass is unusual, it is valid 
| practice.  think anycast.

Agreed. What I meant is that existence of ROA(s) should be 
sufficient to detect invalid uses/filter invalid BGP announcements.
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Dec 2008 09:16:48 +0900

> sufficient to detect invalid uses/filter invalid BGP announcements.

of course

randy

---

From: Geoff Huston <[email-masked]>
Date: Tue, 2 Dec 2008 11:22:22 +1100

WG Chair Hat OFF

> AS are automatically invalid?

No. Some folk believe that this should be the case, others believe  
that this should not be the case. Those who believe that this should  
not be the case are  proposing the BOA as a form of explicitly stating  
what is invalid without having to state what is valid.

By the way, given that you have published a ROA aithorizing your  
origin AS to advertise the prefix, I suspect that this has created  
some further vulnerabilities that a BOA would not create. What happens  
if I use this ROA you've created to hijack with your prefix by  
prepending your origin AS to my AS? Can a third party detect that this  
is a hijack of your prefix from the origination information and the  
ROA? I do not think so.

> And since I will not be generating
> Doesn't that solve the problem you cited?

no - see above,.

> Are you concerned that

> by-product of ROA level checks?

No, it does not. There are many instances of use of AS numbers what  
are not recorded in any allocation database. See the attached list for  
today's set of bogon ASs

> gets added to the repository for that]. Is there any case that's not

That's your _assumption_ of the sematics of a ROA. What reference  
material or working group draft can you cite for semantic  
interpretation of a ROA? draft-ieft-sidr-roa-validation? I don't think  
so. The point of hte BOA draft it that it challenges this assumption  
by taking the position that such route aorigination authorities are  
explicitly scoped to the authority described in the object, without  
the implicit inclusion of any other authority or denial.

AS referred to earlier, here's the list of today's bogon AS numbers,  
just in case you thought  that this is a non-problem:

AS4801	  Announced by     	AS703	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS4801	  Announced by     	AS9304	  HUTCHISON-AS-AP Hutchison Global  
Communications
AS8008	  Announced by     	AS23577	  ATM-MPLS-AS-KR Korea Telecom
AS9218	  Announced by     	AS71	  HP-INTERNET-AS Hewlett-Packard Company
AS9798	  Announced by     	AS151	  IND-NTC-AS - Hewlett-Packard Company
AS9935	  Announced by     	AS2687	  ASATTCA AT&T Global Network  
Services - AP
AS11153	  Announced by     	AS10910	  INTERNAP-BLK - Internap Network  
Services Corporation
AS11196	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS11253	  Announced by     	AS4323	  TWTC - tw telecom holdings, inc.
AS11378	  Announced by     	AS22822	  LLNW - Limelight Networks, Inc.
AS11536	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS11536	  Announced by     	AS13333	  NAUTICOM-NET - Pinnatech, Inc.
AS11600	  Announced by     	AS6461	  MFNX MFN - Metromedia Fiber Network
AS11720	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS11967	  Announced by     	AS6203	  ISDN-NET - ISDN-Net Inc.
AS12077	  Announced by     	AS13768	  PEER1 - Peer 1 Network Inc.
AS12134	  Announced by     	AS3356	  LEVEL3 Level 3 Communications
AS12185	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS13317	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS13377	  Announced by     	AS3549	  GBLX Global Crossing Ltd.
AS13608	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS13746	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS13926	  Announced by     	AS5109	  AS-IDS-NET - Integrated Data  
Systems, LLC
AS13956	  Announced by     	AS3549	  GBLX Global Crossing Ltd.
AS14293	  Announced by     	AS6461	  MFNX MFN - Metromedia Fiber Network
AS14373	  Announced by     	AS6922	  TEXASAGENCYNET - State of Texas  
General Services Commission
AS14458	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS14539	  Announced by     	AS6517	  RELIANCEGLOBALCOM - Reliance  
Globalcom Services, Inc
AS14548	  Announced by     	AS7385	  INTEGRATELECOM - Integra Telecom,  
Inc.
AS14568	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS14575	  Announced by     	AS2828	  XO-AS15 - XO Communications
AS14584	  Announced by     	AS10910	  INTERNAP-BLK - Internap Network  
Services Corporation
AS14606	  Announced by     	AS4323	  TWTC - tw telecom holdings, inc.
AS14715	  Announced by     	AS19024	  INTERNAP-BLK5 - Internap Network  
Services Corporation
AS14764	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS14812	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS14923	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS15037	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS15053	  Announced by     	AS12180	  INTERNAP-2BLK - Internap Network  
Services Corporation
AS15115	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS15115	  Announced by     	AS10912	  INTERNAP-BLK - Internap Network  
Services Corporation
AS15132	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS15211	  Announced by     	AS6395	  LVLT-6395 - Level 3  
Communications, Inc.
AS15337	  Announced by     	AS6325	  ILLINOIS-CENTURY - Illinois  
Century Network
AS16611	  Announced by     	AS3144	  PINNACLE - Pinnacle On-Line
AS16611	  Announced by     	AS12064	  ASN-CXA-HR-12064-CBS - Cox  
Communications Inc.
AS16859	  Announced by     	AS19262	  VZGNI-TRANSIT - Verizon Internet  
Services Inc.
AS16876	  Announced by     	AS4181	  TDS-AS - TDS TELECOM
AS16927	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS17144	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS17144	  Announced by     	AS13791	  INTERNAP-BLK3 - Internap Network  
Services Corporation
AS17275	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS17275	  Announced by     	AS6461	  MFNX MFN - Metromedia Fiber Network
AS17275	  Announced by     	AS22773	  ASN-CXA-ALL-CCI-22773-RDC - Cox  
Communications Inc.
AS17283	  Announced by     	AS3549	  GBLX Global Crossing Ltd.
AS17300	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS17300	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS17300	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS18504	  Announced by     	AS4565	  MEGAPATH2-US - MegaPath Networks  
Inc.
AS18506	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS18533	  Announced by     	AS174	  COGENT Cogent/PSI
AS18641	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS18706	  Announced by     	AS3356	  LEVEL3 Level 3 Communications
AS18726	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS18726	  Announced by     	AS14742	  INTERNAP-BLOCK-4 - Internap  
Network Services Corporation
AS18860	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS18932	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS18932	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS19097	  Announced by     	AS1785	  AS-PAETEC-NET - PaeTec  
Communications, Inc.
AS19097	  Announced by     	AS13407	  CTC-BGP2 - Computer Telephone Corp
AS19132	  Announced by     	AS6140	  IMPSAT-USA - ImpSat USA, Inc.
AS19243	  Announced by     	AS2686	  AT&T Global Network Services - EMEA
AS19243	  Announced by     	AS10913	  INTERNAP-BLK - Internap Network  
Services Corporation
AS19612	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS19612	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS19713	  Announced by     	AS10367	  METRO2000 - Metro2000, Inc.
AS19851	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS19981	  Announced by     	AS80	  GE-CRD - General Electric Company
AS19999	  Announced by     	AS577	  BACOM - Bell Canada
AS19999	  Announced by     	AS15290	  ALLST-15290 - Allstream Corp.  
Corporation Allstream
AS20146	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS20156	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS20247	  Announced by     	AS19262	  VZGNI-TRANSIT - Verizon Internet  
Services Inc.
AS20323	  Announced by     	AS3300	  BT-INFONET-EUROPE BT-Infonet-Europe
AS20364	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS20380	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS20408	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS20463	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS21676	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS21732	  Announced by     	AS12181	  INTERNAP-2BLK - Internap Network  
Services Corporation
AS21846	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS22022	  Announced by     	AS3356	  LEVEL3 Level 3 Communications
AS22056	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS22219	  Announced by     	AS3356	  LEVEL3 Level 3 Communications
AS22219	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS22232	  Announced by     	AS2647	  SITA SITA
AS22232	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS22360	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS22372	  Announced by     	AS3549	  GBLX Global Crossing Ltd.
AS22372	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS22457	  Announced by     	AS6496	  ANET - ANET Internet Solutions, Inc
AS22457	  Announced by     	AS19024	  INTERNAP-BLK5 - Internap Network  
Services Corporation
AS22492	  Announced by     	AS4323	  TWTC - tw telecom holdings, inc.
AS22586	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS22721	  Announced by     	AS174	  COGENT Cogent/PSI
AS22741	  Announced by     	AS10910	  INTERNAP-BLK - Internap Network  
Services Corporation
AS22751	  Announced by     	AS22197	  APPS - Apps Communications
AS22757	  Announced by     	AS17054	  AS17054 - CONTINENTAL BROADBAND  
PENNSYLVANIA, INC.
AS22761	  Announced by     	AS7029	  WINDSTREAM - Windstream  
Communications Inc
AS22815	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS22815	  Announced by     	AS3356	  LEVEL3 Level 3 Communications
AS22846	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS22846	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS22875	  Announced by     	AS10910	  INTERNAP-BLK - Internap Network  
Services Corporation
AS22875	  Announced by     	AS13789	  INTERNAP-BLK3 - Internap Network  
Services Corporation
AS22943	  Announced by     	AS10910	  INTERNAP-BLK - Internap Network  
Services Corporation
AS23011	  Announced by     	AS12006	  EUREKANETWORKS-AS-12006 - eLink  
Communications INC.
AS23021	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS23021	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS23035	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS23108	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS23108	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS23108	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS23247	  Announced by     	AS10910	  INTERNAP-BLK - Internap Network  
Services Corporation
AS23276	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS23276	  Announced by     	AS21548	  MTO - MTO Telecom Inc.
AS23434	  Announced by     	AS16852	  LVLT-16852 - Level 3  
Communications, Inc.
AS23448	  Announced by     	AS852	  ASN852 - Telus Advanced  
Communications
AS23448	  Announced by     	AS6327	  SHAW - Shaw Communications Inc.
AS23475	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS23475	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS23480	  Announced by     	AS6298	  ASN-CXA-PH-6298-CBS - Cox  
Communications Inc.
AS23491	  Announced by     	AS6395	  LVLT-6395 - Level 3  
Communications, Inc.
AS23502	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS23918	  Announced by     	AS4716	  POWEREDCOM KDDI Corporation
AS24011	  Announced by     	AS174	  COGENT Cogent/PSI
AS24012	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS24012	  Announced by     	AS4862	  EQUANT-ASIA Equant AS for Asian  
Region covering Japan
AS24084	  Announced by     	AS3300	  BT-INFONET-EUROPE BT-Infonet-Europe
AS24084	  Announced by     	AS4755	  TATACOMM-AS TATA Communications  
formerly VSNL is Leading ISP
AS25639	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS25964	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS25992	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS26001	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS26023	  Announced by     	AS16399	  NETWORKGCI - Globalcom
AS26051	  Announced by     	AS17229	  ATT-CERFNET-BLOCK - AT&T  
Enhanced Network Services
AS26064	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS26187	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS26396	  Announced by     	AS32703	  IFN-NET - Indiana Fiber Network,  
LLC
AS26483	  Announced by     	AS3356	  LEVEL3 Level 3 Communications
AS26515	  Announced by     	AS7795	  NTELOSINC - Ntelos Inc.
AS26539	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS26581	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS26650	  Announced by     	AS3491	  BTN-ASN - Beyond The Network  
America, Inc.
AS26656	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS26656	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS26690	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS26883	  Announced by     	AS6337	  HIWAAY - HIWAAY INFORMATION  
SERVICES, INC.
AS26951	  Announced by     	AS14743	  INTERNAP-BLOCK-4 - Internap  
Network Services Corporation
AS26970	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS26970	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS26973	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS27197	  Announced by     	AS7029	  WINDSTREAM - Windstream  
Communications Inc
AS27223	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS27243	  Announced by     	AS17054	  AS17054 - CONTINENTAL BROADBAND  
PENNSYLVANIA, INC.
AS27252	  Announced by     	AS30314	  KAN-ED - Kansas Education Network
AS27301	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS27363	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS27363	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS27363	  Announced by     	AS6128	  CABLE-NET-1 - Cablevision Systems  
Corp.
AS27451	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS27451	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS27642	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS28544	  Announced by     	AS6503	  Avantel, S.A.
AS28551	  Announced by     	AS11172	  Alestra
AS28551	  Announced by     	AS22566	  MAXCOM Telecomunicaciones SA de CV
AS29703	  Announced by     	AS852	  ASN852 - Telus Advanced  
Communications
AS29703	  Announced by     	AS6539	  GT-BELL - Bell Canada
AS29755	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS29770	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS29770	  Announced by     	AS1239	  SPRINTLINK - Sprint
AS29837	  Announced by     	AS3549	  GBLX Global Crossing Ltd.
AS29994	  Announced by     	AS558	  NET2EZ - Net2EZ
AS30028	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS30273	  Announced by     	AS6128	  CABLE-NET-1 - Cablevision Systems  
Corp.
AS30273	  Announced by     	AS23329	  AS-OPENACCESS - Open Access Inc.
AS30419	  Announced by     	AS3356	  LEVEL3 Level 3 Communications
AS30707	  Announced by     	AS12181	  INTERNAP-2BLK - Internap Network  
Services Corporation
AS30711	  Announced by     	AS7132	  SBIS-AS - AT&T Internet Services
AS31966	  Announced by     	AS4265	  CERNET-ASN-BLOCK - California  
Education and Research Federation Network
AS31966	  Announced by     	AS4267	  CERNET-ASN-BLOCK - California  
Education and Research Federation Network
AS31966	  Announced by     	AS14743	  INTERNAP-BLOCK-4 - Internap  
Network Services Corporation
AS32057	  Announced by     	AS26554	  US-SIGNAL - US Signal Corporation
AS32108	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS32108	  Announced by     	AS36607	  NETONEGROUP - NET ONE GROUP, LLC
AS32326	  Announced by     	AS3549	  GBLX Global Crossing Ltd.
AS32326	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS32434	  Announced by     	AS4323	  TWTC - tw telecom holdings, inc.
AS32458	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS32567	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS32689	  Announced by     	AS13675	  FAIRPO-3 - FAIRPOINT  
COMMUNICATIONS, INC.
AS32732	  Announced by     	AS1785	  AS-PAETEC-NET - PaeTec  
Communications, Inc.
AS32822	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS32822	  Announced by     	AS3356	  LEVEL3 Level 3 Communications
AS32873	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS32873	  Announced by     	AS10912	  INTERNAP-BLK - Internap Network  
Services Corporation
AS32895	  Announced by     	AS10910	  INTERNAP-BLK - Internap Network  
Services Corporation
AS33089	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS33400	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS33445	  Announced by     	AS701	  UUNET - MCI Communications  
Services, Inc. d/b/a Verizon Business
AS33574	  Announced by     	AS209	  ASN-QWEST - Qwest Communications  
Corporation
AS33649	  Announced by     	AS7018	  ATT-INTERNET4 - AT&T WorldNet  
Services
AS38137	  Announced by     	AS17494	  BTTB-AS-AP Telecom Operator &  
Internet Service Provider as well
AS38205	  Announced by     	AS17494	  BTTB-AS-AP Telecom Operator &  
Internet Service Provider as well
AS38722	  Announced by     	AS9304	  HUTCHISON-AS-AP Hutchison Global  
Communications
AS38870	  Announced by     	AS9482	  ASN-ACON-AP Australia Connect Pty  
Ltd
AS64553	  Announced by     	AS9498	  BBIL-AP BHARTI Airtel Ltd.
AS65009	  Announced by     	AS15924	  BORUSANTELEKOM-AS Borusan  
Telekom Autonomus System
AS65031	  Announced by     	AS2588	  LATNET ISP
AS65101	  Announced by     	AS29405	  VNET-AS VNET ISP Bratislava,  
Slovakia, SK
AS65445	  Announced by     	AS27817	  Red Nacional Académica de  
Tecnología Avanzada - RENATA
AS65491	  Announced by     	AS27817	  Red Nacional Académica de  
Tecnología Avanzada - RENATA
AS65498	  Announced by     	AS27817	  Red Nacional Académica de  
Tecnología Avanzada - RENATA
AS65528	  Announced by     	AS31405	  TMD AS for T-Mobile Deutschland,  
GPRS/UMTS access and content provider

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Dec 2008 19:29:53 -0700

On Dec 1, 2008, at 4:00 PM, Geoff Huston wrote:

> any use of this address, or this AS is an instance of a hijack

A hijack, that's new..  So, publish a BOA for each professed
hijack, so that when it's picked up 24 hours later folks can
filter based on a BOA?  It'll be interested to project how
folks would automate such a BOA publication model.

> then your response seems to be saying to me that I should not do  
> anything. If that is what you are saying then it seems to be a  
> totally ineffectual course of action in my opinion.

No, you're saying you're doing this to support incremental
deployment, I'm saying that capability doesn't exist today
and will clearly only complicate things down the road - e.g.,
who's ever going to remove a BOA - sound familiar (e.g., who
ever removes a stale IRR object, which is a positive thing)?
What existing capability are you adapting to RPKI?

> My apologies - we are not allowed to talk about transit yet as its  
> not an agreed requirement coming out of RSPSEC. So if I remove "nor  
> as a transit AS" and sundry words then I trust that the point I was  
> making is amply clear.

I don't consider it "sundry", it's a very important distinction,
and suggesting that BOAs add some capability that ROAs or SIDR
can't help with along the lines of looking for potential bogon
ASNs in a is misleading at best.

> No security at all makes like enormously simpler.  At some point it  
> is necessary to understand what makes a robust security environemnt  
> even in a world of partial use and piecemeal adoptions and then work  

Right, and adding new capabilities (e.g., telling everyone via
means that are clearly not real time, and may be delayed for
a day or more, via a global RPKI, that your route has been
hijacked and should NOT be advertised by Miguel in Mexico, it
just doesn't seem like a clean way to build this architecture to
me - especially when you're asking folks to configure routers or
implement control plane state and memory based on the contents
of this RPKI.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Dec 2008 19:32:07 -0700

On Dec 1, 2008, at 4:12 PM, Sandra Murphy wrote:
>
> The issue in incremental deployment is not what the people who  
> haven't deployed it should do but what the people who DO deploy it  
> should do. What do the people who DO understand ROAs(and BOAs) do  
> when they see something unsecured - it might be legit, just not  
> produced by someone who understands ROAs(BOAs).

Right, but if the owner also published a BOA about who they
should not accept it from - what's the value add for those
who have deployed it again?  They can say, ohh, there's a ROA
for AS 1 to originate 10.0.0.0/8.  They also published a BOA
for AS2 to originate 10.0.0.0/16.  So, what's that mean to me
since I deployed it?  Accept 10.0.0.0/8 only from AS 1.  I'm
not going to put a policy in my router that says AND accept
it from anyone else, or any more specific, except AS 2.  Tracking
those BOAs is costing money (hardware, time, complexity) and
there is no added benefit.

> So it seems you are in the "and that's all" camp in interpreting  
> ROAs, right?

No, I'm in the "show-me-how-to-configure-this-in-a-router-and-
convince-me-that-all-the-complexity-and-added-infrastructure-is
worth-the-investment-when-I'm-pretty-sure-I'd-be-just-as-happy
with-an-'explicit accept'='implicit deny'-model-like-all-my-other-
security-policies" camp.

I'm certain that if more people who are supposed to deploy this
stuff were paying attention they'd be making the same arguments,
but they're not, and so we need to give heavy consideration to this.

> filters?

Maybe.

> procedure, as presented at the last meeting?

Maybe.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Dec 2008 19:43:11 -0700

On Dec 1, 2008, at 5:22 PM, Geoff Huston wrote:

> not be the case are  proposing the BOA as a form of explicitly  
> stating what is invalid without having to state what is valid.

Heh, well said.  BOAs provide a mechanism to explicit state
*some* of what is invalid, without having to state what is
valid.  Seems like a less than optimal foundation for a secure
inter-domain routing protocol, or any protocol, to me.

> some further vulnerabilities that a BOA would not create. What  
> happens if I use this ROA you've created to hijack with your prefix  
> by prepending your origin AS to my AS? Can a third party detect that  
> this is a hijack of your prefix from the origination information and  
> the ROA? I do not think so.

I'm not sure what the point is here, per BOAs, as currently
specified under the SIDR charter and your previous comment on
this specific issue, provide no such protections either.
Professing it as otherwise is misleading.

> interpretation of a ROA? draft-ieft-sidr-roa-validation? I don't  
> think so.

Yeah, I think we prolly need to revisit that as well.

> The point of hte BOA draft it that it challenges this assumption by  
> taking the position that such route aorigination authorities are  

Right, so let's automate publication of those BOAs so that
routers can be configured to drop them tomorrow, instead of
only accepting those ASNs or any bogon or hijacked prefixes
from legit sources.  And then tomorrow we can deal with the
previous 24 hours of "Bogons - whatever that entails", all
the while the prior set of bogons are half gone but all the
objects remain for security reasons, and all of this gets
really interesting during large route leaks, and possibly even
result in a DOS themselves, and operators can't even pick up
legit objects because there are some many BOAs.  And don't
forget that the state of those BOAs change daily, and perhaps
may of those were legit but I "missed picking it up by seconds".

Seems way inefficient to me...

-danny

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 1 Dec 2008 20:22:58 -0800

| > What if: when "I have been allocated 203.10.61.0/24", I 
| issue an ROA 
| > for the same with my origin AS? Doesn't that automatically 
| mean that 
| > all the advertisements of the prefix from another origin AS are 
| > automatically invalid?
| 
| 
| No. Some folk believe that this should be the case, others 
| believe that this should not be the case. Those who believe 
| that this should not be the case are  proposing the BOA as a 
| form of explicitly stating what is invalid without having to 
| state what is valid.

Why should this not be the case?

| By the way, given that you have published a ROA aithorizing 
| your origin AS to advertise the prefix, I suspect that this 
| has created some further vulnerabilities that a BOA would not 
| create. What happens if I use this ROA you've created to 
| hijack with your prefix by prepending your origin AS to my 
| AS? Can a third party detect that this is a hijack of your 
| prefix from the origination information and the ROA? I do not 
| think so.

This is a good example case for path attestation / complete AS_PATH
validation, no? When a third party tries to verify whether the
path leads back to origin AS, that should fail (whenever we get to
that part)...

| > As others have suggested, when "I have been allocated 
| 203.10.60.0/22", 
| > I issue an ROA for 203.10.60.0/22-22. That automatically means that 
| > there can't be any other advertisements for this prefix or its more 
| > specifics (unless I suballocate a more specific block and a new ROA 
| > gets added to the repository for that]. Is there any case 
| that's not 
| > handled by doing this?
| >
| 
| That's your _assumption_ of the sematics of a ROA. What 
| reference material or working group draft can you cite for 
| semantic interpretation of a ROA? 
| draft-ieft-sidr-roa-validation? I don't think so. The point 
| of hte BOA draft it that it challenges this assumption by 
| taking the position that such route aorigination authorities 
| are explicitly scoped to the authority described in the 
| object, without the implicit inclusion of any other authority 
| or denial.

So are you saying that an entity who is not owner of prefix 10/8
can issue an ROA for it and it would be present in/added to the 
RPKI repository?

- Pradosh

---

From: Geoff Huston <[email-masked]>
Date: Tue, 2 Dec 2008 15:52:24 +1100

WG Chair Hat off

> Why should this not be the case?

Because the transitive closure of ROAs in an environment of piecemeal  
deployment is non-deterministic.

> path leads back to origin AS, that should fail (whenever we get to

right - the "lets use magic" solution. I'm convinced.

> | > As others have suggested, when "I have been allocated

The best answer I can give here is please read the sidr drafts. Your  
question really makes me suspect that you have not done so.

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 1 Dec 2008 22:52:46 -0800

| > | > As others have suggested, when "I have been allocated
| > | 203.10.60.0/22",
| > | > I issue an ROA for 203.10.60.0/22-22. That automatically means
| > that
| > | > there can't be any other advertisements for this prefix or its
| > more
| > | > specifics (unless I suballocate a more specific block and a new
| > ROA
| > | > gets added to the repository for that]. Is there any case
| > | that's not
| > | > handled by doing this?
| > | >
| > |
| > | That's your _assumption_ of the sematics of a ROA. What reference 
| > | material or working group draft can you cite for semantic 
| > | interpretation of a ROA?
| > | draft-ieft-sidr-roa-validation? I don't think so. The 
| point of hte 
| > | BOA draft it that it challenges this assumption by taking the 
| > | position that such route aorigination authorities are explicitly 
| > | scoped to the authority described in the object, without the 
| > | implicit inclusion of any other authority or denial.
| >
| > So are you saying that an entity who is not owner of prefix 
| 10/8 can 
| > issue an ROA for it and it would be present in/added to the RPKI 
| > repository?
| >
| 
| The best answer I can give here is please read the sidr 
| drafts. Your question really makes me suspect that you have 
| not done so.

I have. Your response above prompted the question.
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Tue, 2 Dec 2008 19:43:50 +1100

> | > | > As others have suggested, when "I have been allocated

WG Chair Hat OFF.

Good to hear. In which case you would be well aware that a person who  
is not the current right of use holder of an address prefix cannot  
generate a valid RPKI object of any form and sign the object with an  
RPKI signature using that prefix. So I fail to understand how an an  
entity who is not owner of prefix 10/8 can issue an ROA for it that  
would be considered valid in the RPKI, and if its invalidly signed  
then whether it is in an RPKI repository publication point or not is  
irrelevant. But as we've all read the drafts we all knew that anyway.  
So I'm not sure why its worth repeating here.

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 2 Dec 2008 12:22:11 -0500 (Eastern Standard Time)

On Mon, 1 Dec 2008, Danny McPherson wrote:

>> deployed it should do but what the people who DO deploy it should do. What 
>> do the people who DO understand ROAs(and BOAs) do when they see something 
>> unsecured - it might be legit, just not produced by someone who understands 
>> ROAs(BOAs).
>

Danny, BOAs don't say "don't accept 10/8 from AS2".  They say "don't 
accept any advertisement for 10/8".

> with-an-'explicit accept'='implicit deny'-model-like-all-my-other-

I was trying to guess what you think a ROA means.  Your previous 
statements and this statement make it sound like you think a prefix holder 
will sign ROAs for every and all ASs that are allowed to advertise the 
prefix, so signing ROAs means "these ASs are allowed to announce the 
prefic -- and that's all".  Those configuring their routers use that 
semantics to decide what to configure.

If you think that a set of ROAs means "these ASs are allowed to announce 
the prefix, but not necessarily only these ASs", then router configuration 
goes differently.

We are presently working out how the meaning of these ROAs results in 
router configuration.

If you have ideas of how the configuration would happen, it would be 
valuable for us to hear them.

>> procedure, as presented at the last meeting?

I presume there's a smilie in there.  So when you figure it out, you'll 
let us know, right?  :-)

--Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 2 Dec 2008 13:02:38 -0500 (Eastern Standard Time)

On Tue, 2 Dec 2008, Geoff Huston wrote:

> No. Some folk believe that this should be the case, others believe that this 
> should not be the case. Those who believe that this should not be the case 
> are  proposing the BOA as a form of explicitly stating what is invalid 
> without having to state what is valid.

Can you explain why you think it better to say what is invalid rather than 
stating what is valid?

>
> By the way, given that you have published a ROA aithorizing your origin AS to 
> advertise the prefix, I suspect that this has created some further 
> vulnerabilities that a BOA would not create. What happens if I use this ROA 
> you've created to hijack with your prefix by prepending your origin AS to my 
> AS? Can a third party detect that this is a hijack of your prefix from the 
> origination information and the ROA? I do not think so.
>
>

We all recognize and acknowledge that the sidr work does not protect 
against those who want to append the valid origin on an invalid path. 
The sidr work protects the origin of the AS_PATH only, and does not 
provide protection of the validity of the rest of the AS_PATH.

Recognize that protection of the origination of the route is NECESSARY. 
Everything we do here is needed by any protection of the full AS_PATH 
developed some time in the future.

>> Doesn't that solve the problem you cited?

Please explain further.  It appears to me that if you take the "these ASs 
and that's all" interpretation of a set of ROAs, an AS that produces one 
ROA does prevent other ASs from advertising the prefix (and being 
believed).

> No, it does not. There are many instances of use of AS numbers what are not 
> recorded in any allocation database. See the attached list for today's set of 
> bogon ASs

Who would sign the BOAs for unallocated ASs?  (I don't know. RIRs? How 
would that work -- would such a BOA have to change with each new 
allocation?  Would there be a BOA for each unallocated AS that would be 
revoked when it was allocated?)

> That's your _assumption_ of the sematics of a ROA. What reference material or 
> working group draft can you cite for semantic interpretation of a ROA? 
> draft-ieft-sidr-roa-validation? I don't think so. The point of hte BOA draft 
> it that it challenges this assumption by taking the position that such route 
> aorigination authorities are explicitly scoped to the authority described in 
> the object, without the implicit inclusion of any other authority or denial.

We are still in the process of specifying things and what they mean, 
i.e., the drafts aren't done yet.

Actually, we are not arguing about the semantics of a single ROA as much 
as we are arguing about the semantics of a set of ROAs.

If one ROA means "this AS is allowed to advertise this prefix", does the 
complete set of ROAs mean "these ASs and maybe others are allowed to 
advertise this prefix" or "these ASs and no others are allowed to 
advertise this prefix".

Do prefix holders (who are RPKI aware) sign ROAs for every AS that might 
announce their prefix?

If so, what does that mean about interpreting ROAs?

If not, what does that mean about interpreting ROAs?

>
> AS referred to earlier, here's the list of today's bogon AS numbers, just in 
> case you thought  that this is a non-problem:
>
>

<snip>

Wow.  And the Internet still works.  Amazing.

Given the general falibility of humans, I presume there are cases where 
one AS gets its AS number wrong and uses some other (allocated) AS number? 
Is that common?  There are configuration options to check if your neighbor 
AS is using the proper AS number in its advertisement to you - but since 
it's an option, I'm guessing you can NOT check if you want.

What is the damage right now to using an unallocated AS? Mis-using an 
allocated AS?

What would be the damage in an RPKI aware router from an announcement that 
used an unallocated AS?  (Would ROAs or prefix-BOAs prevent such 
announcements?)  What about an announcement that mis-used an allocated AS?

--Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 2 Dec 2008 14:56:19 -0500 (Eastern Standard Time)

> deployment is non-deterministic.

I can't grasp this statement.  What do you mean by transitive closure of 
ROAs?  ROAs aren't a relation that could be performed transitively.  And I 
don't see the non-determinism.

Are you saying that the complete set of ROAs does not give you the 
complete set of valid advertisements?  If so, then you are using the 
"these ASs and maybe others" semantics.  Right?

> right - the "lets use magic" solution. I'm convinced.

I don't understand this statement.  But I've already noted that we're not 
working on protecting the AS_PATH beyond the origination point.  I think 
that when Pradosh said "whenever we get to that part" he was referring to 
potential future work to protect the AS_PATH beyond the origination.

> The best answer I can give here is please read the sidr drafts. Your question 
> really makes me suspect that you have not done so.

I think Pradosh was asking his question about your statement, not the 
drafts.

The 10/8 and other non-globally-routed prefixes are, according to my 
reading of the drafts, intended to be protected within one AS by a local 
RPKI structure rooted on a local trust anchor.

--Sandy