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

From: Geoff Huston <[email-masked]>
Date: Wed, 12 Nov 2008 10:32:57 +1100

WG Co-Chair hat _OFF_

Sandy,

The authors of these two drafts now believe that all SIDR WG comments  
have been integrated into these documents, and there are no further  
outstanding comments to be addressed.

Accordingly, we would like to request that you conduct a WG Last Call  
for these documents in order to ensure that the WG is now comfortable  
with these documents and all comments have been made, and to assess  
whether the WG is now ready to move these two documents to the IESG  
for IESG review.

regards,

   Geoff

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Nov 2008 17:41:15 -0600

> have been integrated into these documents

only withdrawal of the bogons draft would address my comments

randy

---

From: George Michaelson <[email-masked]>
Date: Wed, 12 Nov 2008 10:38:10 +1000

> only withdrawal of the bogons draft would address my comments

I believe the BOA draft documents a structure which is going to be  
very useful in the partial deployment world of the RPKI, especially,  
partial deployments of origination attestation.

Its going to allow relying parties to tell the difference between a  
bogon, and an as-yet un-attested route object. Thats documented in the  
validation draft.

The BOA is closely modelled on the ROA. Its logical structure,  
associated certification processes, CMS representation, are all close  
analogues. I fail to see a structural criticism which is valid, which  
does not also go to the ROA, which you seem (from other comments) to  
accept as a useful structure.

-George

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Nov 2008 18:40:42 -0600

George Michaelson wrote:
> I believe the BOA draft documents a structure which is going to be very
> useful in the partial deployment world of the RPKI, especially, partial
> deployments of origination attestation.
> 

i believe you believe all that.  this does not alter one iota that the
new draft does not address my comment.

the security model of the boa is seriously flawed.  it mixes a negative
model with the existing positive one.  this will vastly complicate
things and to little utility.

randy

---

From: Geoff Huston <[email-masked]>
Date: Wed, 12 Nov 2008 12:02:07 +1100

On 12/11/2008, at 11:40 AM, Randy Bush wrote:

>> very

WG Chair hat off

So to head away from generalities, what parts of either draft are the  
issue here? The BOA draft is essentially a mirror of the ROA draft so  
I assume that the BOA draft is in and of itself. The interpretation  
and use of the BOA and ROA are described in the ROA Validation draft.  
What parts of that draft present such vast complications?

I would also be interested to learn whether this is a common concern  
or not and also interested to learn what other meaningful options  
relying parties have in a world of partial deployment, because, as it  
stands without BOAs, a world of ROAs and the absence of ROAS is pretty  
much completely useless in terms of relying parties being able to  
detect a routing lie.

---

From: Terry Manderson <[email-masked]>
Date: Wed, 12 Nov 2008 11:10:24 +1000

Hi Randy,

> things and to little utility.

As I see it the BOA draft introduces and allows for the reality of  
several shades of routing intent, as exists on the internet today and  
will also exist in the future, but adds a strong level of  
predictability. Certainly it does add an additional function that you  
could argue as complexity - however I see benefits of the BOA as we  
have cases that don't fall into a singularly positive stance (and  
logically what is not positive - is negative).

Progressing through the world of a partial deployment (thinking that  
is the only level of deployment we will probably ever see) there are  
states of, 'must route', 'must not route' and the horrible greyness of  
local relying party' policy mixed with various resources that compound  
the corner cases.

We know 'must route' is well understood, and using a singularly  
positive stance that implies everything else is negative or black, or  
grey-ish as mixed with local policy.

Having the BOA provides for the 'must not route', eg reserved  
resources, unallocated resources, and prefixes that a publishing  
entity simply does not want routed on the internet (a way to enforce  
their own policy transcending configuration errors). So even when  
mixed with local policy it also provides for a clean line of fairly  
universal and well known bogon behaviours that can't go stale.

What it further allows, is the greyness of global anycast prefixes  
(somewhat known as problem resources in RPKI) like 6to4, and AS23456  
(AS-TRANS). Here the prefix can fall nicely into a grey area by not  
having a ROA, and not having a BOA. The concerns of local policy  
become much simpler on weather to accept this route or not regardless  
of who announces the resource.

Terry

---

From: George Michaelson <[email-masked]>
Date: Fri, 14 Nov 2008 14:20:10 +1000

In looking at the BGP security requirements document,

http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-10.txt

I find these points (for instance):

4.2.  Incremental deployment

"Any proposed solution MUST support an incremental
   deployment which will provide some benefit for those who  
participate."

"In an environment where both secured and non-secured systems are
      interoperating a mechanism MUST exist for secured systems to
      identify whether an originator intended the information to be
      secured."

This language is very strong guidance that we need both partial  
deployment
technology, and mechanisms to allow the ORIGINATOR to say if its  
covered or not.

In that sense, a BOA is a strong statement by the prefix owner they  
intend all
more specifics to be covered by explicit security, ie casual more  
specifics without
ROA are being actively dis-allowed. I do not see methods using the ROA  
alone which
can convey this, with the same purpose or precision.

The ROA validation draft:

http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-01.txt

has:

3.  Applying Validation Outcomes to BGP Route Selection

(second para)

   In the case of partial deployment of ROAs there are a very limited
   set of circumstances where the outcome of ROA validation can be used
   as grounds to reject all consideration of the route object as an
   invalid advertisement.  While the presence of a valid ROA that
   matches the advertisement is a strong indication that an
   advertisement matches the authority provided by the prefix holder to
   advertise the prefix into the routing system, the absence of a ROA or
   the invalidity of a covering ROA does not provide a conclusive
   indication that the advertisement has been undertaken without the
   address holder's permission, unless the object is described in a BOA.

I still believe this. I think the BOA substantively adds information  
into the
system about routing security, and I think it is *completely* on- 
charter for us given
the bgpsecrec draft guidance.

-G

---

From: Andy Newton <[email-masked]>
Date: Fri, 14 Nov 2008 05:58:35 -0500

George,

I do not follow your argument.  Yes, I understand using the BOA to restrict
everything and using more specific ROAs to specify valid IP space.  What I
don't understand is how that helps partial deployment.  In fact, doesn't
this make necessary full deployment?  If a major provider blankets their
space with a BOA, then all the downstreams MUST be covered by ROAs.  Or did
I miss something?

And who is to be in the business of publishing trusted BOAs for bogons?
Seems to me that it would be fraught with peril if they screw it up.

I am not convinced that this is necessary.  But then, it is early and the
coffee hasn't kicked in.

-andy

---

From: Geoff Huston <[email-masked]>
Date: Sat, 15 Nov 2008 07:07:46 +1100

WG Chair hat off

> space with a BOA, then all the downstreams MUST be covered by ROAs.   

The problem with a model of using only ROAs is that while the presence  
of a ROA that matches a route advertisement can provide the relying  
party some level of reassurance that accepting the route matches the  
intentions of the originator, the absence of a corresponding ROA for a  
route object tells the relying party absolutely nothing. The only way  
the absence of a ROA can be interpreted by a relying party is by  
forcing the relying party to make an assumption about the state of ROA  
use.

One possible answer is that relying parties simply assume that ROAs  
are universally used and any and every route object that does not  
match a currently valid ROA is discarded. I trust you would agree that  
this would be an unwise assumption for a relying party yo make. In a  
world of incremental deployment where only a few prefix holders are  
generating ROAs this assumption would effectively cause a relying  
party to reject all of the (valid) routing table with the exception of  
the set of objects covered by ROAs.  Not good. Even in a world of  
comprehensive deployment this would be an unwise move. Because prefix  
holders essentially publish their own signed objects in a repository  
of their choosing, relying parties, if they wish to avoid using the  
services of RPKI aggregators or middle-agents will need to access wach  
and every repository in order to collect the ROAs and the necessary  
certificate material that is required to validate each ROA. But what  
if the ROA for a prefix is contained in a repository that is located  
at an address that is described in the ROA. i.e. you can't get the ROA  
until you treat the corresponding route object as valid, and you can;t  
treat it as valid until you have the ROA.

The other option is that the relying party assumes that ROAs are not  
universally deployed, and that implies that a relying party must  
assume that there exists valid route objects for which there is no  
corresponding ROA.  In a world of partial deployment where a relying  
party has no idea whether the absence of a ROA indicates an attempted  
routing hijack of the simple absence of a ROA, then the relying party  
really is no better off than if there were no ROAs whatsoever!

So how could this situation be improved for relying parties?

A good example for me in thinking about this has been the YouTube  
hijack at the start of this year. A salient question I asked myslef  
was: what mechanisms could YouTube have used to alert relying parties  
to the unauthorised advertisement of more specifics from a different  
origin AS?

ROAs alone are not a good answer here, in that a ROA does not say what  
is bogus. The only way that ROAs can do this is when a relying party  
is justified in assuming that _absolutely everything_ is covered by a  
ROA. In a world of incremental deployment this assumption does not  
hold, and therefore the absence of a ROA conveys no information at all.

In this case BOAs can assist. Lets say that MeTube has published a ROA  
to allow 10.1.0.0/16, max length=16 to be advertised from origin AS 1,  
and a relying party sees an advertisement for 10.1.1.0/24 originating  
from AS 2 (a hijack attempt). In this case the relying party has no  
grounds to assume that the /24 advertisement is bogus, and will accept  
the advertisement and the hijack will be effective. But what if MeTube  
also published a BOA for 10.1.0.0/16 at the same time as the ROA. Now  
as a ROA "trumps" a BOA then any advertisement for 10.1.0.0/16 with an  
origination of AS 1 will be regarded as valid by a relying party,  
while any other use of 10.1.0.0/16 or any more specific will be  
regarded as bogus.

So, as far as I can tell, BOAs are a simple and effective mechanism to  
allow relying parties to detect attempts at origination hijack even in  
a world of partial use of origination attestations - i.e. they meet  
the criteria of the RPSEC document relating to incremental deployment,  
as referenced in George's message, without relying on comprehensive  
ROA deployment.

Andy, your example is somewhat different, because you posit the  
existence of some intermediate IR that has issued portable address  
space to clients of the service and allows the clients of this space  
to independently announce their address space. In this example your  
comment was that if the IR blankets the space with a BOA then that  
forces the clients to use ROAs to have their independent routes  
treated as valid, if I have got this right. Yes, that would be the  
case, and if the IR did not want that outcome then the IR should not  
issue a BOA in the first place. On the other hand if the IR, being a  
major provider, had a policy that all space allocated by the IR was  
NOT portable address space, then the BOA would be a means to announce  
that provider-dependent routing policy to all others in the inter- 
domain routing cloud.

What I don't see in this example is the leap from this case to the  
conclusion that the potential for prefix holder to publish BOAs  
necessarily implies that prefix holders are _all_ forced to publish  
ROAS, i.e. I don't see how you get to the assertion that "this make[s]  
necessary full deployment" (Where I interpret "full deployment" as the  
situation each and every prefix holder that authorizes routes in to  
the inter-domain routing space is required to publish a ROA.)

> Seems to me that it would be fraught with peril if they screw it up.

Only the certified holder of an address block can generate a BOA. So I  
suppose the answer to your question would depend on your preferred  
interpretation of what is a "bogon".

>  But then, it is early and the
> coffee hasn't kicked in.
>

ditto.

    Geoff

---

From: Andy Newton <[email-masked]>
Date: Sun, 16 Nov 2008 13:23:06 -0500

> WG Chair hat off

Minneapolis hat soon to be on!  Brrrrrr.....

> really is no better off than if there were no ROAs whatsoever!

This reminds me of the +all/-all,~all SPF wars, where die-hards insisted on
-all but nearly everybody did ~all.

There are likely to be 3 types of route objects:
- those covered by ROAs
- those covered by BOAs (and perhaps a wider BOA)
- those covered by neither

Given that incremental deployment means the Internet will start out with
route objects covered by neither, policy will have to determine what to do
when a route object is not covered by a ROA (the bad situation you mention
above).  BOAs do not get us out of this.

> interpretation of what is a "bogon".

Clear as mud!  But this just re-enforces what I just said.  There will be
route objects not covered by either a BOA or a ROA.

That being said, I'm not gonna fall on my sword over this.  In the end, BOAs
may likely end up like SPF -all, ignored.

-andy

---

From: Randy Bush <[email-masked]>
Date: Sun, 16 Nov 2008 12:32:37 -0600

> - those covered by neither

and the more painful case, when they are covered by both.

iana issues a boa for 0/0

i announce 0/0 to a bunch of my downstreams

in case any of them do validation, i have to issue a roa for 0/0

where do i publish it?

randy

---

From: Geoff Huston <[email-masked]>
Date: Mon, 17 Nov 2008 05:50:44 +1100

WG Chair hat off

> above).  BOAs do not get us out of this.

You may want to read through draft-ietf-sidr-roa-validation. The draft  
has details of this  - section 2 of the document goes through the case.

> route objects not covered by either a BOA or a ROA.

of course - but the objective here is incremental capabilities that  
increase the levels of assurance that is available to relying parties  
to allow them to make reasonable decisions about what they can reject  
and how they can apply relative preference to route objects.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Mon, 17 Nov 2008 05:53:38 +1100

WG Chair hat off

> iana issues a boa for 0/0

This appears to be a very fanciful notion to me.

> in case any of them do validation, i have to issue a roa for 0/0

wherever you want - assuming that some relying party has chosen to use  
the certificate you issue as a TA.

---

From: Randy Bush <[email-masked]>
Date: Sun, 16 Nov 2008 13:49:28 -0600

> This appears to be a very fanciful notion to me.

it was iana's first intent, and, from an ops pov, dead obvious.  see rfc
3330.

> the certificate you issue as a TA.

i just don't think i want to be authoritative for 0/0.  and i do not
think we want a hundred or two roas for 0/0 in the public rpki.

boas are not a path that is prudent to follow.

randy

---

From: Geoff Huston <[email-masked]>
Date: Mon, 17 Nov 2008 07:14:10 +1100

WG Chair Hat OFF

> it was iana's first intent, and, from an ops pov, dead obvious.  see  

Either your copy of RFC3330 is different from my copy of RFC3330, or  
you are putting an interpretation on the white spaces in that document  
that entirely unobvious and opaque to me. I can't see IANA claiming in  
RFC3330 that 0/0 is a bogon. Do you want me to send you my copy of  
RFC3330 to check that we are referring to the same document here?

> i just don't think i want to be authoritative for 0/0.

the choice of TAs is a relying party choice - You can do whatever you  
want and unless I am prepared to nominate your assertions as something  
I, as a relying party, am prepared to trust, then whatever you chose  
to do is your problem.

>  and i do not

I think you may have a basic misunderstanding of the trust model for  
this PKI - your use of the term "in the public RPKI" conjoined with "a  
hundred or two roas for 0/0" is a somewhat fanciful conjunction,  
unless of course you are advocating that relying parties use a  
universal acceptance policy for nominated TAs, in which case the  
entire concept of a "public RPKI" is a complete waste of time.

> boas are not a path that is prudent to follow.

So you are claiming. Others have different views and have backed them  
up with documents and reasoning to support their views.

---

From: Danny McPherson <[email-masked]>
Date: Sun, 16 Nov 2008 16:28:09 -0700

On Nov 14, 2008, at 1:07 PM, Geoff Huston wrote:
> was: what mechanisms could YouTube have used to alert relying  
> parties to the unauthorised advertisement of more specifics from a  
> different origin AS?
>
> ROAs alone are not a good answer here, in that a ROA does not say  
> what is bogus.

But does the existence of a ROA, with origin authorization not
make this implicit enough?

> The only way that ROAs can do this is when a relying party is  
> justified in assuming that _absolutely everything_ is covered by a  
> In this case BOAs can assist. Lets say that MeTube has published a  
> ROA to allow 10.1.0.0/16, max length=16 to be advertised from origin  
> AS 1, and a relying party sees an advertisement for 10.1.1.0/24  
> originating from AS 2 (a hijack attempt). In this case the relying  
> party has no grounds to assume that the /24 advertisement is bogus,  
> and will accept the advertisement and the hijack will be effective.  
> But what if MeTube also published a BOA for 10.1.0.0/16 at the same  
> time as the ROA. Now as a ROA "trumps" a BOA then any advertisement  
> for 10.1.0.0/16 with an origination of AS 1 will be regarded as  
> valid by a relying party, while any other use of 10.1.0.0/16 or any  
> more specific will be regarded as bogus.

So wouldn't this mean that in the current model everyone would publish
ROAs and BOAs?  Do we really want that?  Perhaps I'm missing something
here?

-danny

---

From: Geoff Huston <[email-masked]>
Date: Mon, 17 Nov 2008 11:25:40 +1100

WG chair hat off

> make this implicit enough?

I assume you are referring to the situation where, for example, a ROA  
exists for 10.1.0.0/16 origin AS 1, and NO ROA exists for 10.1.0.0/16  
origin AS2, and you are seeing a route object for 10.1.0.0/16 with  
origin AS 2, yes?

The problem is that as a relying party you can't tell whether the  
problem is with the retrieval of ROA objects or whether the route  
object is bogus. i.e. what if the ROA for 10.1.0.0/16 origin AS 2 was  
published a few seconds ago, whereas your local cache of ROA objects  
was last refreshed a day ago.  i.e. everything you have at hand is  
valid, the manifests are good, and you are seeing something that is  
not oin a locally held ROA, _but_ it is still valid.

If there was also a BOA published for 10.1.0.0/16 then as a relying  
party you now have grounds to believe that anything not described in a  
valid ROA can be regarded as an invalid object. In this case there is  
still the issue of time lag, and if the prefix holder had intended to  
authorize 10.1.0.0/16 using AS 2 as an origination in addition to AS1  
then it would be incumbent on the prefix holder to generate and  
publish the new ROA well in advance of the advertisement of the new  
route.

Of course there is also the other case where AS 1 insists on a ROA as  
a precondition for originating the route, and AS 2 does not, and the  
prefix holder performs only what is required and no more. In this case  
both routes are valid, but only one as a ROA. In tis case the problem  
is not one of  timing at the relying party side, and will not be  
resolved by bring the relying party into sync with the authority  
publisher.

>> ROA to allow 10.1.0.0/16, max length=16 to be advertised from  
>> origin AS 1, and a relying party sees an advertisement for  
>> 10.1.1.0/24 originating from AS 2 (a hijack attempt). In this case  
>> the relying party has no grounds to assume that the /24  
>> advertisement is bogus, and will accept the advertisement and the  
>> hijack will be effective. But what if MeTube also published a BOA  
>> for 10.1.0.0/16 at the same time as the ROA. Now as a ROA "trumps"  
>> a BOA then any advertisement for 10.1.0.0/16 with an origination of  
>> AS 1 will be regarded as valid by a relying party, while any other  
>> use of 10.1.0.0/16 or any more specific will be regarded as bogus.
>

Well if relying parties could safely assume that _everyone_ was  
publishing ROAs then there would be no need for BOAs as the absence of  
a positive authority in the form of a ROA could be reliably inferred  
to be unauthorized. But in a world where that assumption does not  
hold, and where there is incremental partial deployment of publication  
of these origination credentials, when relying parties cannot assume  
that the absence of a positive authority means anything at all. All it  
means is that if the route object matches the ROA then its been  
authorized by the prefix holder. But if there is no matching ROA then  
the relying party cannot assume anything at all.

The problem here is similar to the problem of filter generation: There  
is a qualitative difference in these two statements:

"I give my authority for AS 1 to advertise a route object for  
10.1.0.0/16"

"I give my authority for AS1 and only AS1 to advertise a route object  
for 10.1.0.0/16"

If you want the second statement, then we either need to change the  
ROA to offer closure ("i.e. include "any only") or introduce a new  
object that allows the authorizing party to state the "and only" part  
explicitly). I contend that leaving this part of the authority as  
something implicit that relying parties may or may not choose to infer  
from the authority is a compromised model, imho.

So the BOA is a way of implementing the RPSEC requirement of being  
able to support environments of incremental deployment, where it is not
assured that everyone is publishing these authorities. Now if you are  
of the view that the requirement of devising mechanisms to support  
incremental piecemeal deployment is daft or unnecessary, then perhaps  
this is a debate that in the IETF context should be held in the  
context of the RPSEC WG, as the SIDR requirement here is one that was  
gather up from the earlier RPSEC work and generate mechanisms that met  
those requirements as stated in the RPSEC documents.

regards,

Geoff

---

From: [email-masked]
Date: Mon, 17 Nov 2008 18:39:48 -0500

Geoff Huston wrote:
> "I give my authority for AS1 and only AS1 to advertise a route  
> object for 10.1.0.0/16"

Does the ROA format already permit this or would it require a modification?
If you allow this, what about a subprefix,say, 10.1.0.0/24?
Would that be precluded from having a ROA with a different AS?

Sriram

Quoting "Geoff Huston" <[email-masked]>:

>>> hijack at the start of this year. A salient question I asked  
>>> myslef was: what mechanisms could YouTube have used to alert  
>>> relying parties to the unauthorised advertisement of more  
>>> specifics from a different origin AS?
>>>
> I assume you are referring to the situation where, for example, a  
> ROA exists for 10.1.0.0/16 origin AS 1, and NO ROA exists for  
> 10.1.0.0/16 origin AS2, and you are seeing a route object for  
> 10.1.0.0/16 with origin AS 2, yes?
>
> object is bogus. i.e. what if the ROA for 10.1.0.0/16 origin AS 2  
> was published a few seconds ago, whereas your local cache of ROA  
> objects was last refreshed a day ago.  i.e. everything you have at  
> hand is valid, the manifests are good, and you are seeing something  
> that is not oin a locally held ROA, _but_ it is still valid.
>
> party you now have grounds to believe that anything not described in  
> a valid ROA can be regarded as an invalid object. In this case there  
> is still the issue of time lag, and if the prefix holder had  
> intended to authorize 10.1.0.0/16 using AS 2 as an origination in  
> addition to AS1 then it would be incumbent on the prefix holder to  
> generate and publish the new ROA well in advance of the  
> advertisement of the new route.
>
> Of course there is also the other case where AS 1 insists on a ROA  
> as a precondition for originating the route, and AS 2 does not, and  
> the prefix holder performs only what is required and no more. In  
> this case both routes are valid, but only one as a ROA. In tis case  
> the problem is not one of  timing at the relying party side, and  
> will not be resolved by bring the relying party into sync with the  
> authority publisher.
>
>>
>>
>>> a BOA then any advertisement for 10.1.0.0/16 with an origination  
>>> of AS 1 will be regarded as valid by a relying party, while any  
>>> other use of 10.1.0.0/16 or any more specific will be regarded as  
>>> bogus.
>>
> publishing ROAs then there would be no need for BOAs as the absence  
> of a positive authority in the form of a ROA could be reliably  
> inferred to be unauthorized. But in a world where that assumption  
> does not hold, and where there is incremental partial deployment of  
> publication of these origination credentials, when relying parties  
> cannot assume that the absence of a positive authority means  
> anything at all. All it means is that if the route object matches  
> the ROA then its been authorized by the prefix holder. But if there  
> is no matching ROA then the relying party cannot assume anything at  
> all.
>
> The problem here is similar to the problem of filter generation:  
> There is a qualitative difference in these two statements:
>
> "I give my authority for AS 1 to advertise a route object for 10.1.0.0/16"
>
> "I give my authority for AS1 and only AS1 to advertise a route  
> object for 10.1.0.0/16"
>
> object that allows the authorizing party to state the "and only"  
> part explicitly). I contend that leaving this part of the authority  
> as something implicit that relying parties may or may not choose to  
> infer from the authority is a compromised model, imho.
>
> assured that everyone is publishing these authorities. Now if you  
> are of the view that the requirement of devising mechanisms to  
> support incremental piecemeal deployment is daft or unnecessary,  
> then perhaps this is a debate that in the IETF context should be  
> held in the context of the RPSEC WG, as the SIDR requirement here is  
> one that was gather up from the earlier RPSEC work and generate  
> mechanisms that met those requirements as stated in the RPSEC  
> documents.
>
>
> regards,
>
> Geoff
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 18 Nov 2008 11:44:55 +1100

WG Chair Hat _off_

On 18/11/2008, at 10:39 AM, [email-masked] wrote:

> Does the ROA format already permit this

It is my understanding that the ROA, as defined today, does NOT permit  
this - i.e. the presence of a ROA does not in and of itself do the  
negation of the ROA. i.e. a ROA does not explicitly state "and  
everything else is invalid"

> or would it require a modification?

I believe it requires a modification - either a modification to the  
ROA to say "and invalidate all others" or via a BOA to state "and  
invalidate all others"

> If you allow this, what about a subprefix,say, 10.1.0.0/24?

I assume that you are talking about a ROA for 10.0.0.0/8 with a  
maximum length=8. Again I would say that the ROA as it stands does not  
invalidate other route objects.

> Would that be precluded from having a ROA with a different AS?

Again my interpretation is that a ROA is a positive assertion and not  
a negative assertion about all other possible route objects. If you  
want to extend this then the choices are either to extend the  
semantics of the ROA, either implicitly or explicitly, or introduce a  
new object, other the AS0 concept, or the explicit negation concept of  
the BOA draft. The BOA concept makes this negations explicit.

    Geoff

---

From: Andy Newton <[email-masked]>
Date: Tue, 18 Nov 2008 11:26:54 -0500

> the BOA draft. The BOA concept makes this negations explicit.

This all makes sense, and the BOA seems to be straightforward way of
implementing a negative assertion.

After Steve Kent's description of ROAs flowing from the top and being
constantly reshaped based on allocations, I'd like to withdraw my objection
to BOAs.  It would seem they are necessary.

-andy

---

From: [email-masked]
Date: Tue, 18 Nov 2008 11:45:43 -0500

Thanks.
"ROA as only a positive assertion" as you have stated is good.
If we do modify ROA format to include "ASx and only ASx" to advertise
a route object for a prefix, it appears correctly acceptable that
I as the owner of 10.0.0.0/8 can still issue these two ROAs:

ROA#1: Prefix = 10.0.0.0/8; origin = AS1 and only AS1; maxlength = 12
ROA#2: Prefix = 10.1.0.0/16; origin = AS2 and only AS2; maxlength = 24

ROA users have to be careful in their implementation
not to "disregard" the second ROA based on the first.
If they go with "ROA as only a positive assertion"
then there should be no problem in the implementation.

Sriram

Quoting "Geoff Huston" <[email-masked]>:

> It is my understanding that the ROA, as defined today, does NOT  
> permit this - i.e. the presence of a ROA does not in and of itself  
> do the negation of the ROA. i.e. a ROA does not explicitly state  
> "and everything else is invalid"
>
>
> maximum length=8. Again I would say that the ROA as it stands does  
> not invalidate other route objects.
>
>>
> Again my interpretation is that a ROA is a positive assertion and  
> not a negative assertion about all other possible route objects. If  
> you want to extend this then the choices are either to extend the  
> semantics of the ROA, either implicitly or explicitly, or introduce  
> a new object, other the AS0 concept, or the explicit negation  
> concept of the BOA draft. The BOA concept makes this negations  
> explicit.
>
>
>    Geoff
>
>
>

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Nov 2008 05:50:31 +1100

WG CHair Hat Off

Yes, I agree that there are some potential issues in correct  
interpretation if there are combinations of ROAs where there is  
implicit negation associated with the ROA. This should be basic 3  
dimensional set work (prefix, AS, yes/no) and I think that the result  
is always deterministic for any collection of ROAs, but that does not  
make it always trivial to construct a desired origination policy. But  
as ROAs are only a positive assertion then this is probably a moot  
point.

    Geoff

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Nov 2008 12:54:59 -0600

> interpretation if there are combinations of ROAs where there is implicit
> negation associated with the ROA. This should be basic 3 dimensional set
> work (prefix, AS, yes/no) and I think that the result is always
> deterministic for any collection of ROAs, but that does not make it
> always trivial to construct a desired origination policy. But as ROAs
> are only a positive assertion then this is probably a moot point.

roas with magic as numbers vs boas is syntactic sugar.  the semantic
problem you mention applies to both.

randy

---

From: George Michaelson <[email-masked]>
Date: Tue, 18 Nov 2008 13:55:21 -0600

On 18/11/2008, at 12:54 PM, Randy Bush wrote:

>> implicit

I do not accept that ROA to AS0 and BOA is just syntactic sugar. They  
are substantially different in their logic, and semantic intent.

A BOA is a positive assertion by the resource holder of the exact  
behaviors in respect of their prefix and a purported origin AS that  
they DO NOT wish to see expressed.

Of course they can be used to simply do a negation of things not seen  
in the ROA, but they have far more expressive capability and can say  
things, materially useful to achieve the range of origination policies  
used by network operators at the present time.

We drew on the ROA *syntax* precisely to seek a syntactic similarity,  
to ease coding, We chose CMS deliberately for consistency with other  
signed object construction.

Please do not allow that syntactic similarity to the ROA to hide the  
quite clear SEMANTIC DIFFERENCE which we hold in the BOA.

I still stand by the BOA draft. I think it adds useful tools into  
routing security for operators.

-George

---

From: Danny McPherson <[email-masked]>
Date: Sat, 22 Nov 2008 22:37:32 -0700

> 10.1.0.0/16 with origin AS 2, yes?

Or perhaps 10.1.0.0/24, sure..

> that is not oin a locally held ROA, _but_ it is still valid.

This is one of the reasons timing issues need to be considered,
and one of the many reasons people stopped using explicit prefix
filters.  The route would be announced, the prefix was dropped,
the filters were updated to support the announcement, but the
route wouldn't be accepted unless the session was reset or a
route re-announcement was triggered.  You can imagine how painful
this can be across multiple AS hops.

> advertisement of the new route.

So clearly, the same case holds true for the BOA.  If a BOA was
just removed from the repository a few seconds ago but as a relying
party I don't update my "accept policies" because of a problem with
the retrieval of the BOA, it's just perturbing the issue.  This could
be especially problematic during natural disasters or other similar
events where a publisher of a BOA can't update a repository or it
can't be accessed by a relying party, and therefore, route changes
that are common during those events can't happen.

> will not be resolved by bring the relying party into sync with the  

Yes, I think there are lots of issues of this nature, issues which
BOAs only exacerbate.

> mechanisms that met those requirements as stated in the RPSEC  

I'm not entirely convinced of this yet...

Also, Sam had a query about BOAs including AS numbers, and I think
that's a good point.  Is the goal for an issue to say AS n can announce
prefix x, but no one else, that would take one ROA and two
BOAs, right? Why wouldn't that just be done implicitly with a ROA?

-danny

---

From: Geoff Huston <[email-masked]>
Date: Sun, 23 Nov 2008 20:40:40 +1100

WG Chair Hat _OFF_

Thanks for your comments Danny. I'll interleave some further responses  
across this.

> this can be across multiple AS hops.

Entirely true, but I'm not sure where this part of the thread is  
leading in terms of the SIDR work in particular.

>> party you now have grounds to believe that anything not described  
>> in a valid ROA can be regarded as an invalid object. In this case  
>> there is still the issue of time lag, and if the prefix holder had  

yes - part of the underlying consideration is the manner in which the  
validation information is propagated in relation to the route object -  
in this model the validation information is in terms of the contents  
of rpki publication point repositories, as distinct from attaching the  
validation information to the route update itself. This is what is  
referred to in the roa-validation draft as a distinction between  
"decoupled" validation, as compared to "linked" validation. There are  
relative timing issues in the decoupled model, of course.
> Yes, I think there are lots of issues of this nature, issues which

I don't see the reasoning which leads to your observation that BOAs  
_exacerbate_ the issue. There are much the same as the issues with  
ROAs but I don;t see the case that makes the situation worse because  
of the addition of these negative attestations in the form of BOAs.  
Perhaps an example or two may help me (and possibly others) understand  
precisely what you mean by "exacerbate" ?

>> held in the context of the RPSEC WG, as the SIDR requirement here  
>> is one that was gather up from the earlier RPSEC work and generate  

fair enough - what might help? worked examples? other perspectives?
> BOAs, right? Why wouldn't that just be done implicitly with a ROA?

The inclusion of the AS number had just a little to do with  
origination and probably more to do with the AS path - the semantic  
intent of the inclusion of the AS number in a BOA was to say "I'm the  
holder of this AS number and I'm not using it in routing at all. If  
you see a BGP update with this AS number anywhere in the AS Path then  
that's a lie!"

regards,

Geoff

---

From: Danny McPherson <[email-masked]>
Date: Sun, 23 Nov 2008 10:02:51 -0700

On Nov 23, 2008, at 2:40 AM, Geoff Huston wrote:

> Perhaps an example or two may help me (and possibly others)  
> understand precisely what you mean by "exacerbate" ?

To follow your previous example, you've now got 2x or more
objects and if you can't access one, or you miss publication
of one by seconds, you're increasing your vulnerability
surface.

> intent of the inclusion of the AS number in a BOA was to say "I'm  
> the holder of this AS number and I'm not using it in routing at all.  
> If you see a BGP update with this AS number anywhere in the AS Path  
> then that's a lie!"

But this requires full enumeration of the AS number
space with each BOA, at least two ranges spanning all
but the AS(s) listed in the ROA(s).

This seems like a bad idea to me, as a matter of security
policy expecting folks to explicitly fully enumerate what
they will not accept, or what others should not accept,
rather than letting it be an implicit "deny everything
else".

-danny

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Nov 2008 10:13:46 +1100

WG Chair Hat Off

>> the holder of this AS number and I'm not using it in routing at  
>> all. If you see a BGP update with this AS number anywhere in the AS  
>> Path then that's a lie!"
>

I'm confused here Danny - are you explicitly advocating that a ROA  
should explicitly carry the semantics of "deny all else"?

Is that is the case, then from such a perspective of a ROA having a  
"deny all else" interpretation, how should incremental use / piecemeal  
deployment of ROAs be handled? Does a ROA for 10.0.0.0/8 Origin AS1  
explicitly deny all other non-ROA advertisements of any prefix that is  
equal to, or a more specific of 10.0.0./8 using any other origin AS  
other than AS1? I'm not sure that this would be your intention, but it  
seem to me that this logically follows from a "deny everything else"  
semantic interpretation applied to a ROA.

regards,

   Geoff

---

From: Danny McPherson <[email-masked]>
Date: Mon, 24 Nov 2008 16:29:22 -0700

> "deny all else" interpretation, how should incremental use /  
> piecemeal deployment of ROAs be handled? Does a ROA for 10.0.0.0/8  
> Origin AS1 explicitly deny all other non-ROA advertisements of any  
> prefix that is equal to, or a more specific of 10.0.0./8 using any  
> other origin AS other than AS1? I'm not sure that this would be your  
> intention, but it seem to me that this logically follows from a  
> "deny everything else" semantic interpretation applied to a ROA.

No, I'm saying that if a ROA is published indicating *who* is
authorized to originate a route do I really need to fully
enumerate everyone that is NOT authorized?  Part of your case
for BOAs was in case an object couldn't be accessed - increasing
the size of the database at least 3x by adding BOAs doesn't seem
entirely amenable to supporting that motivation.

In an incremental deployment model an attestation as to the
authorized originator of a route accommodates the incremental
deployment model - if there's no ROA do what you want with
it - depref, tag, discard, whatever you want.

-danny

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Nov 2008 10:50:48 +1100

WG chair hat off

On 25/11/2008, at 10:29 AM, Danny McPherson wrote:

>> other origin AS other than AS1? I'm not sure that this would be  
>> your intention, but it seem to me that this logically follows from  
>> a "deny everything else" semantic interpretation applied to a ROA.
>

So if I understand you correctly you are advocating that a ROA has an  
explicit semantic intention of "deny everything else"

could you explain the precise semantics of a ROA for 10.0.0.0/8  
maxlength = 9, origin AS1 as if would apply to an advertisement of  
10.1.1.0/24 origin AS1 without any ROA, and to an advertisement of  
10.1.1.0/24 origin AS2 without any ROA?

> it - depref, tag, discard, whatever you want.

but hang on - you are not saying that Danny in your previous paragraph  
- you are saying that in a deny everything else, the presence of a ROA  
implicitly denies a class of other routes. I'm very confused about  
what you are saying here as you seem to me to be saying two different  
things at once.

  regards,

    Geoff

---

From: Danny McPherson <[email-masked]>
Date: Mon, 24 Nov 2008 17:11:56 -0700

On Nov 24, 2008, at 4:50 PM, Geoff Huston wrote:
>
> So if I understand you correctly you are advocating that a ROA has  
> an explicit semantic intention of "deny everything else"
>
> but hang on - you are not saying that Danny in your previous  
> paragraph - you are saying that in a deny everything else, the  
> presence of a ROA implicitly denies a class of other routes. I'm  
> very confused about what you are saying here as you seem to me to be  
> saying two different things at once.

In an incremental deployment model non-existence of a ROA should
mean an operator can do whatever they deem necessary.  If it were
me, and there was a ROA for 10.0.0.0/8 origin AS 1, and I implemented
filtering (whatever that means) based on ROAs, and no other ROA
exists for anything equal to or longer than that 10.0.0.0/8 origin
AS 1, AS 1 would be the only AS from which I would accept that prefix
- I wouldn't accept ANY more-specifics from AS 1, and I certainly
wouldn't accept any route equal to or longer than 10.0.0.0/8 from
anyone else.

That'd be my incentive as an operator.  A ROA exists, I trust it,
and I trust no one else.  Then de-aggregation of that prefix or
route hijacks don't affect me for that prefix.  If you don't have
a ROA for your prefix, I can't filter on it, from you or anyone
else.  You want me to only accept it from you, see that it and any
associated ROAs exists and that'll be the only place I accept those
prefixes, with the explicit specified origin AS.  That's my peers
incentive as an operator.

So, by your interpretation, yes.  But that's me, and that's how I'd
configure my routers, and each operator can configure their routing
policy how they like in this regard.

Requiring full enumeration of who not to accept what from is only
going to induce lots of unnecessary overhead, in both policy
specification and policy application, AND certainly, churn, frequency,
and number of objects that need to be maintained in the system.

-danny

---

From: George Michaelson <[email-masked]>
Date: Mon, 24 Nov 2008 18:12:37 -0600

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.

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

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.

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

-George

---

From: Robert Loomans <[email-masked]>
Date: Tue, 25 Nov 2008 10:27:05 +1000

> rather than letting it be an implicit "deny everything

I think there is a lack of clarity in the BOA draft as to what the list
of ASs actually is saying:

My understanding is that the list of ASs and the list of IP prefixes is
independent (ie, logical OR), and unlike with ROAs, only the holder of
an AS can sign a BOA with that AS in it.

That is, if AS5 and 10.0.0.0/8 appear in a BOA, it means that neither
AS5 *nor* prefixes 10.0.0.0/8 and more specific should *ever* appear in
routing, together or separately.

Geoff, George, Terry, is my understanding correct?

Rob

-- 
Robert Loomans                                  Email: [email-masked]
Senior Software Engineer, APNIC                 Phone:   +61 7 3858 3100
http://www.apnic.net                              Fax:   +61 7 3858 3199
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Nov 2008 11:51:38 +1100

wG Chair Hat Off

On 25/11/2008, at 11:27 AM, Robert Loomans wrote:

>>> the

yes, that understanding is correct.

   Geoff

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Nov 2008 10:45:35 +0900

Geoff Huston wrote:
> Does a ROA for 10.0.0.0/8 Origin AS1 explicitly deny all other
> non-ROA advertisements of any prefix that is equal to, or a more
> specific of 10.0.0./8 using any other origin AS other than AS1?

almost.  there might also be a roa for 10/8-33 to as42.  and we're
ignoring max prefix len here.

but the owner of the prefix has spoken formally.  things are no longer
ambiguous.  end.

randy

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Nov 2008 20:28:46 +1100

wg chair hat off

> policy how they like in this regard.

So what I think you are saying here Danny is that:

- there should no standard for the interpretation of ROAs and its up  
to each relying party to figure out what they want to do - i.e. you  
are in effect advocating that the WG that the WG has erred in taking  
on the roa-validation draft and that the WG should abandon the roa- 
validation draft completely.

- you want to configure your environment such that you, as a relying  
party, want to interpret a ROA as including the semantics of denial of  
all other possible route objects, irrespective of the intended  
semantics of the ROA publisher.

- you do not want to use a BOA in your environment, and you want to  
stop anyone else from using as BOA in terms of a BOA as defined by an  
IETF standards document in any case.

Obviously I disagree with this approach, in that if the semantics of  
route attestations are in the eye of the beholder this entire effort  
is a complete waste of everyone's time. If the intentions of the  
creator of the object can be variably interpreted by relying parties  
then what you don't have as a result is a secure system. I'm not sure  
what you would call the outcome, but "secure" would not be a part of  
it as far as I can figure out. I'm not sure where this line of  
reasoning you are using here Danny is headed, and I really can't  
understand how it fits into the overall architecture being developed  
in SIDR.

Geoff

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Nov 2008 20:23:58 +0900

> - there should no standard for the interpretation of ROAs and its up to
> each relying party to figure out what they want to do 
> ...
and a lot of other argument by extreme

perhaps you could look at draft-pmohapat-sidr-pfx-validate-00.txt.  i do
not buy it entirely, and have sent edits to the authors.  but how the
roa fits into bgp decision making is pretty simple.

randy

---

From: Danny McPherson <[email-masked]>
Date: Tue, 25 Nov 2008 07:34:35 -0700

On Nov 25, 2008, at 2:28 AM, Geoff Huston wrote:

> stop anyone else from using as BOA in terms of a BOA as defined by  
> an IETF standards document in any case.

For you to come to the list of conclusions above simply because
I don't like the idea of BOAs is quite a leap.  I'd prefer you not
speculate what you believe to be my position, and instead, address
the issue which lead to this discussion - convince me of the
positive value of BOAs, which I've yet to realize.

Perhaps if you'd outline a couple use cases of BOAs I'd better
understand how this is useful and provides more net benefits than
offshoots?

Thanks!

-danny

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 25 Nov 2008 16:12:20 -0500 (Eastern Standard Time)

On Wed, 12 Nov 2008, Geoff Huston wrote:

> WG Co-Chair hat _OFF_
>
> Sandy,
>
> The authors of these two drafts now believe that all SIDR WG comments have 
> been integrated into these documents, and there are no further outstanding 
> comments to be addressed.
>
> Accordingly, we would like to request that you conduct a WG Last Call for 
> these documents in order to ensure that the WG is now comfortable with these 
> documents and all comments have been made, and to assess whether the WG is 
> now ready to move these two documents to the IESG for IESG review.
>

It is clear from the ensuing discussion that we are not close enough to 
consensus in this matter to conduct a last call.

We do need to work out the issues being raised before we can reasonably 
conduct a last call.

--Sandy

---

From: Terry Manderson <[email-masked]>
Date: Wed, 26 Nov 2008 09:21:32 +1000

Hey Danny,

> understand how this is useful and provides more net benefits than

There are several use cases that come to mind, but only one I can  
anonymise and present with the organisation's permission.

Lets say XYZ Bank has a significant address holding, due to their  
engineering design they actually use globally routable unique  
addresses for all of their internal infrastructure as it makes their  
redundancy and fail-over mechanisms clean. This "infrastructure" set  
of addresses is never meant to be seen in global routing tables. (yes  
even though they have firewalls and all types of black-boxes  
protecting it). In partial deployment the BOA gives the XYZ Bank the  
higher level _policy_ power which goes beyond router configuration to  
say "our infrastructure prefixes are not to be accepted and certainly  
not routed" irrespective of any router config fumbles.

I guess in someway this might be similar to a large cable provider  
that could use a specific IPv6 range for managing their SOHO units.  
Equally those prefixes aren't intended to ever see the light of a DFZ.  
So they also might issue a BOA to that effect.

If a BOA is not available to them, the interpretation of just a ROA  
for the intended routable address space is that the prefix for the ROA  
IS accepted, but the other prefixes MAY be accepted, based on local  
(theirs and third party) router config. There is no high level  
statement to the effect of 'ONLY route prefix x/y' until full  
deployment.

I'll do my best to get permission to discuss other examples that cover  
BOA use in a full deployment environment.

Cheers
Terry

---

From: Geoff Huston <[email-masked]>
Date: Wed, 26 Nov 2008 12:39:07 +1100

WG Chair Hat OFF

> positive value of BOAs, which I've yet to realize.

One way to reach understanding in a dialogue Danny is for one party to  
to reiterate their understanding of what was said by the other, to  
check that there is some level of mutual appreciation of what is being  
said. You failed to quote above, and perhaps failed to appreciate,  
that this remark of mine that you have quoted was prefaced by the  
comment:

"So what I think you are saying here Danny is that:"

Evidently I was mistaken in my understanding of what you were saying  
Danny, and I apologise if this process of reiteration has caused you  
any personal offense or triggered some personal sensitivity, but,  
frankly, if we keep on talking past each other then nothing useful  
will result in any case. So I still believe that there is some merit  
in attempting to understand the argument that is being advanced here.  
So I do want to understand your position, and yes, in so doing I find  
it helpful to reiterate back what I understand you to be saying here,  
and yes, you may interpret that as speculation on my part, and I trust  
you will continue to correct such speculation until you are happy that  
I am accurately phrasing your arguments here. If that process is not  
acceptable to you then I'm not sure where we go from here, as I  
evidently still really don't understand the argument you are advancing  
at all.

> understand how this is useful and provides more net benefits than

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.

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.

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.

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.

regards,

    Geoff

---

From: Geoff Huston <[email-masked]>
Date: Wed, 26 Nov 2008 13:06:09 +1100

On 26/11/2008, at 8:12 AM, Sandra Murphy wrote:

>> The authors of these two drafts now believe that all SIDR WG  
>> comments have been integrated into these documents, and there are  
>> no further outstanding comments to be addressed.
>>
>> Accordingly, we would like to request that you conduct a WG Last  
>> Call for these documents in order to ensure that the WG is now  
>> comfortable with these documents and all comments have been made,  
>> and to assess whether the WG is now ready to move these two  
>> documents to the IESG for IESG review.
>>
>
> It is clear from the ensuing discussion that we are not close enough  
> to consensus in this matter to conduct a last call.
>
> We do need to work out the issues being raised before we can  
> reasonably conduct a last call.
>
> --Sandy
>

WG Co-Chair hat OFF

Thanks for your response Sandy.

To the extent that this request for a WGLC on these documents has  
provoked reading of these drafts and discussion of the issues in the  
WG, this has been a very useful exercise so far. I trust that the  
deferral of this call is not seen as an excuse by interested folk to  
defer the WG discussion as well, as the debate so far has, I think,  
managed to expose some substantive issues relating to the semantics of  
these objects that I feel remain as yet unresolved in terms of  
achieving consensus, rough or otherwise.

regards,

    Geoff

---

From: Andy Newton <[email-masked]>
Date: Tue, 25 Nov 2008 21:25:33 -0500

Perhaps these should be considered for informative text in an I-D.

-andy

---

From: Andrew Partan <[email-masked]>
Date: Tue, 25 Nov 2008 22:56:05 -0500

> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my intention  

How far down do you have to generate the BOAs?
Do you have to generate BOAS for the 4 /24s and the 8 /25s and the ... ?
Or do the two /23s cover all the possible more specifics?

Andrew Partan

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Nov 2008 13:07:28 +0900

> Perhaps these should be considered for informative text in an I-D.

i think we are missing something more basic, a clear, simple, concise,
terse, and rigorous definition of the semantics of a roa.

then, and only then, can we start to discuss the need/use of a boa.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Nov 2008 13:43:54 +0900

1, 2, and 4 are uninteresting to me, not worth the additional complexity.

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

ROA 203.10.60.0/22-22

the owner of the prefix has spoken.  that is what may be announced and
that is all that may be announced.

as nw once said "i did not leave that out because i ran out of ink."

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Nov 2008 13:46:32 +0900

> engineering design they actually use globally routable unique addresses
> for all of their internal infrastructure as it makes their redundancy
> and fail-over mechanisms clean. 

so they are not harmed if, during transition, others fat finger it into
the dfz.  next.

if they really care, issue a roa for it to their real provider, to a
private asn, to asn 0, or whatever.  no one cares, least of all the owner.

randy

---

From: Terry Manderson <[email-masked]>
Date: Wed, 26 Nov 2008 15:28:37 +1000

On 26/11/2008, at 2:46 PM, Randy Bush wrote:

>> addresses

I wouldn't say they are 'not harmed'. What they consider harm, is  
clearly different to a network purist sense.

> private asn, to asn 0, or whatever.  no one cares, least of all the  

They certainly care. The issue I see with either a AS0 or private AS  
use is that it isn't allocated in the resource allocation hierarchy,  
unless all RIRs are issued with AS0 and AS64512 through to AS65535 by  
IANA, and then the RIRs subsequently simultaneously issued to all RIR  
members. Knowing that ROA's can only be issued based on the AS and IP  
resources allocated by the parent. This just seems wrong to me.

I made the comment at the mic that this type of de-attestation is  
contrary to the allocation hierarchy function as it stands - I guess  
people missed the underlying issue I was getting at focusing only on  
the label.

Terry

---

From: George Michaelson <[email-masked]>
Date: Wed, 26 Nov 2008 16:08:52 +1000

On 26/11/2008, at 2:43 PM, Randy Bush wrote:

>> more

In the context of BOA, you complained Randy, that a BOA compelled  
people lower, more specific to issue ROA to override the BOA. you  
complained, that they are unnecessarily brought into the process and  
cannot exist as non-secured routing people, unless they do this. You  
complained about the compulsion element.

But, your statement above COMPELS any more specific, to issue a valid  
ROA, to prove their routes are acceptable. It has exactly the same  
property. Exactly.

Whereas, with a BOA, you can choose to formally disclaim, or not  
disclaim, more specifics. The  choice is left with the relying party,  
*unless* a BOA is issued.

-george

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Nov 2008 15:20:03 +0900

George Michaelson wrote:
> In the context of BOA, you complained Randy, that a BOA compelled people
> lower, more specific to issue ROA to override the BOA. you complained,
> that they are unnecessarily brought into the process and cannot exist as
> non-secured routing people, unless they do this. You complained about
> the compulsion element.
> 
> ROA, to prove their routes are acceptable.

if the owner wanted to allow longer prefix(es) to be announced, they
could have issued roa(s) for the longer prefix(es).

yes, once you have secured a prefix, longer matches must also be
secured.  this is a good thing.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Nov 2008 15:22:05 +0900

> Knowing that ROA's can only be issued based on the AS and IP resources
> allocated by the parent.

whoops!  no.  the asn in the roa is not signed or otherwise authorized.

if the prefix owner chooses to issue a road for P to A, that does not
mean A must announce it or A agrees.

randy

---

From: George Michaelson <[email-masked]>
Date: Wed, 26 Nov 2008 16:23:42 +1000

> then, and only then, can we start to discuss the need/use of a boa.

from the roa draft:

2.1.3.2. eContent

   The content of a ROA identifies a single AS that has been authorized
   by the address space holder to originate routes and a list of one or
   more IP address prefixes that will be advertised.  If the address
   space holder needs to authorize multiple ASes to advertise the same
   set of address prefixes, the holder issues multiple ROAs, one per AS
   number.

and

4. Security Considerations

....   The purpose of a ROA is to convey authorization for an AS to
   originate a route to the prefix(es) in the ROA.

these are basic, clear, simple, concise, terse, and rigorous  
definition of the semantics of a roa.

-George

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Nov 2008 15:26:24 +0900

> these are basic, clear, simple, concise, terse, and rigorous definition
> of the semantics of a roa.

and incomplete.  for example, this does not deal with netmask and max
len issues.

randy

---

From: George Michaelson <[email-masked]>
Date: Wed, 26 Nov 2008 16:30:55 +1000

On 26/11/2008, at 4:26 PM, Randy Bush wrote: (quoting ggm, who quotes  
the roa draft)

> and incomplete.  for example, this does not deal with netmask and max

As Yakov Rekhter might say in IDR "please send text"

ie, if you dislike these words, please instead of just knocking down,  
can you help construct?

noting netmask, maxlen, which clearly removed the 'rigorous' -what  
else is wrong with the text?

-George

---

From: Terry Manderson <[email-masked]>
Date: Wed, 26 Nov 2008 16:44:34 +1000

> whoops!  no.  the asn in the roa is not signed or otherwise  

..sigh.. I'm _sure_ I read in one of the many documents that an ASN  
had to be in a signed state somewhere.

(off looking...)

Terry

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Nov 2008 15:53:57 +0900

> ie, if you dislike these words, please instead of just knocking down,

see wrestling with pigs.  and this is my last go on this for today.

> noting netmask, maxlen, which clearly removed the 'rigorous' -what else
> is wrong with the text?

it does not even say that if there is a roa specifying that A may
announce P, that, in the absence of a roa saying that B may also
announce P, an announcement of P by B should be rejected.

it should. the owner stated their intent.  if they had intended B to
announce, they could and should have said so.  they did not run out of
ink or lack the pen.

in fact, it strangely says the opposite,

"While the presence of a valid ROA that matches the advertisement is a
strong indication that an advertisement matches the authority provided
by the prefix holder to advertise the prefix into the routing system,
the absence of a ROA or the invalidity of a covering ROA does not
provide a conclusive indication that the advertisement has been
undertaken without the address holder's permission ..."

to me that is a whole lot of broken words merely in order to justify boas.

randy

---

From: Terry Manderson <[email-masked]>
Date: Wed, 26 Nov 2008 20:21:20 +1000

On 26/11/2008, at 3:28 PM, Terry Manderson wrote:
>  The issue I see with either a AS0 or private AS use is that it  
> isn't allocated in the resource allocation hierarchy, unless all  
> RIRs are issued with AS0 and AS64512 through to AS65535 by IANA, and  
> then the RIRs subsequently simultaneously issued to all RIR members.  
> Knowing that ROA's can only be issued based on the AS and IP  
> resources allocated by the parent.

I'll walk back from this politely.. Indeed there is nothing in the  
RPKI drafts which requires that any ASN be in a signed or certified  
state.

(I must have been smoking something really good at the time ;-)

Terry

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 26 Nov 2008 11:38:48 -0500 (Eastern Standard Time)

I've seen use cases developed into an i-d in other working groups, but 
that involves a lot of effort to ensure the list is complete and 
consistent.  I mention two, Geoff has added four more.  It would take time 
to be complete - do we want to take the time?

One aspect of the use cases is new operational practices that may arise 
from different approaches.  (For example: if I'm worried that my customers 
may be impacted if they do not sign ROAs, perhaps I automatically do it 
for all customers as part of allocation.  But then we'd have to look 
carefully about moving out-sourced-CA services from me to my customer at 
some point.  This is NOT NOT NOT a definite suggestion, just an example of 
my belief that operational practices will be induced by any solution.)

--Sandy

---

From: George Michaelson <[email-masked]>
Date: Thu, 27 Nov 2008 10:17:56 +1000

> see wrestling with pigs.  and this is my last go on this for today.

I find this comment offensive, and if the intention was to belittle  
me, then it has certainly succeeded.

> announce P, an announcement of P by B should be rejected.

So, although previously you have said that you do not wish downstream  
players to be brought into this process involuntarily, and you have  
also stated that we should respect current ISP/Operator practice,  
which includes holders of aggregate/covering blocks announcing that  
block, but permitting specific prefixes to be multihomed and announced  
as more specifics, you now say that in this emerging reality, if a ROA  
exists for the superblock then a consequence is that *ALL*  
announcements for more specifics *MUST* be covered by a ROA, even  
during the partial deployment scenario.

IE you are now a 'maximalist' and believe that the act of a superior  
delegate LIR/ISP issuing a ROA requires all downstream participants  
with routing rights in that block, to become full-blown players in RPKI?

Can I just confirm that on-record Randy?

> to me that is a whole lot of broken words merely in order to justify  

Randy, the text *I* posted to you, came from the ---> R.O.A. <---  
draft, which is authored by Steve Kent and others. It has *NO*  
reference to BOA, none at all.

If you wish to critique the formalisms over a ROA, the canonical text  
is in the ROA draft, and if you wish to discuss the ROA draft, and its  
definitional language, then I think you should discuss the ROA draft.

Not the BOA draft, which of course, is a different draft. Nor this  
draft you cite in fact.

What you quoted was the validation draft. This does not define the  
ROA. It is a draft where we discuss validation of routing, as it says  
in the title:

	Validation of Route Origination in BGP using the Resource Certificate  
PKI

-George