On 16/11/2010, at 10:27 AM, Sriram, Kotikalapudi wrote:
> This comment applies to draft-ietf-sidr-roa-validation
> and also to draft-ietf-sidr-pfx-validate-00.
>
> One additional question that I feel the origin validation algorithms need to
> consider is
> as follows. Should there be a fourth Validation state added to the existing
> three?
> 1. Valid
> 2. Valid-i (Valid - imperfect; AS matches but max-length exceeded) --
> proposed new state
> 3. Unknown (or Not Found)
> 4. Invalid
>
> The rationale for the proposed additional state "Valid-i" is as follows.
> Let us say a prefix owner has prefix 10.1.0.0/20 and also own AS1.
> He has a ROA registered: {10.1.0.0/20, AS1, maxlength = 22},
> and has announced 10.1.0.0/20 with origin AS = AS1.
> An adversary has AS2, and announces 10.1.0.0/23 with origin AS = AS2.
> During partial deployment, the adversary's announcement gets
> accepted in routing tables because potentially the /23 could be a
> suballocation
> to a customer with AS2 that does not have a ROA yet.
In draft-ietf-sidr-roa-validation the table on page 4 indicates quite
clearly that the intent of the {10.1.0.0/20, AS1, maxlength = 22}
includes the intent that relying parties should treat more specifics
of this route has having a validity state of "invalid"
> The legitimate prefix owner detects that there is a hijack attempt,
> and then announces 10.1.0.0/23 with origin AS = AS1
> in order to recover quickly at least some of the traffic.
Again the draft indicates quite clearly that with this additional route
advertisement BOTH advertisements (origin AS2 and AS3) would have a validity
state of "invalid".
> But both the hijack update of the adversary as well as the recovery
> update of the legitimate prefix owner for 10.1.0.0/23 will be marked as
> "Invalid".
agreed.
> The legitimate prefix owner has no advantage over the hijacker!
> I think this is not desirable. The origin AS in the recovery update
> matches that in the ROA, except that the legitimate owner
> has momentarily exceeded the maxlength in order to recover his hijacked
> subprefix.
> If we introduce the additional validation state "Valid-i" as
> described above, then this undue disadvantage for the legitimate
> owner can be mitigated.
> Routers will give higher preference for "Valid-i" over "Invalid"
> and thus mitigate the problem stated above.
> The same principles will apply if the legitimate prefix owner
> wants to recover his traffic by announcing even more specific /24s.
>
If folk chose to accept routes with a validity state of "invalid"
then one has to ask oneself: why bother with this entire exercise?
If AS1 wants to bias a relying party who accepts routes with an
"invalid" validity state, then surely the response would be to issue
a new ROA with maxlength 23 when advertising the more specific route
(i.e. a ROA with {10.1.0.0/20, AS1, maxlength = 23}).
Of course the downside of this form of response is that a naughty
party can generate a bogus route for the /23 and fake the origin
to be AS1.
But also of course all we are talking about so far is origination
validation, and the story about securing BGP routes is totally
incomplete without also having a mechanism to undertake AS_PATH
validation. Origin validation alone cannot address attacks that
lie about Path, and to my mind trying to address one form of
attack with a different form of provision of validation credentials
is yet again an instance of trying to jam round pegs into square holes.
Having explored such byways of additional validity states in earlier
iterations of this draft (see -00, for example), and receiving at the
time robust negative comment from WG members at the time as to the
wisdom and feasibility of such an approach, it is my impression that
most WG members with an active interest in this topic see no value
in adding further complexity to the ROA semantics beyond what is in
the current iteration of this draft. Having spent some time thinking
about this myself in revising this document in response to such
earlier comments, its a position with which I now personally favour
as well.
thanks,
Geoff
>
> Sriram
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> Geoff Huston
>> Sent: Wednesday, November 10, 2010 9:12 PM
>> To: [email protected] wg
>> Cc: [email protected]
>> Subject: [sidr] WG Last Call Request for draft-ietf-sidr-roa-validation-10
>>
>> Hi,
>>
>> We've revised this draft as per the informal poll of the WG in today's SIDR
>> meeting
>> regarding the text concerning a "origin AS" when the AS_PATH contain as
>> AS_SET path
>> element.
>>
>> We request the chairs to conduct a WG Last Call for this draft.
>>
>> thanks
>>
>> Geoff & George
>>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
