Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-01.txt

On Tue, 2 Dec 2008, Geoff Huston wrote:

> WG Chair Hat off
>
> On 02/12/2008, at 3:22 PM, Pradosh Mohapatra (pmohapat) wrote:
>
>> | > 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?
>> 
>
> Because the transitive closure of ROAs in an environment of piecemeal 
> 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?

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

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

>
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr