Subject: [sidr] WG Last Call Request for draft-ietf-sidr-roa-validation-10

From: Geoff Huston <[email-masked]>
Date: Thu, 11 Nov 2010 13:12:02 +1100

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

On 11/11/2010, at 1:07 PM, IETF I-D Submission Tool wrote:

> 
> A new version of I-D, draft-ietf-sidr-roa-validation-10.txt has been successfully submitted by Geoff Huston and posted to the IETF repository.
> 
> Filename:	 draft-ietf-sidr-roa-validation
> Revision:	 10
> Title:		 Validation of Route Origination using the Resource Certificate PKI and ROAs
> Creation_date:	 2010-11-11
> WG ID:		 sidr
> Number_of_pages: 10
> 
> Abstract:
> This document defines the semantics of a Route Origin Authorization
> (ROA) in terms of the context of an application of the Resource
> Public Key Infrastructure to validate the origination of routes
> advertised in the Border Gateway Protocol.
> 
> 
> 
> The IETF Secretariat.
> 
> 

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 15 Nov 2010 18:27:36 -0500

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

Sriram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Geoff Huston
> Sent: Wednesday, November 10, 2010 9:12 PM
> To: [email-masked] wg
> Cc: [email-masked]
> 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.
>

---

From: Geoff Huston <[email-masked]>
Date: Wed, 17 Nov 2010 15:01:41 +1100

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

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

> update of the legitimate prefix owner for 10.1.0.0/23 will be marked as "Invalid".

agreed.

> 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

---

From: Rob Austein <[email-masked]>
Date: Thu, 18 Nov 2010 12:20:52 +0100

> earlier comments, its a position with which I now personally favour 

Strongly agree.  Please keep this simple.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 22 Nov 2010 18:59:23 -0500

I would support the LC on draft-ietf-sidr-roa-validation-10 
if it had informational status,
i.e., be advanced for publication as an Informational RFC.

I would take the same position on draft-ietf-sidr-pfx-validate-00
after it is revised further to reflect recent new comments on the list.
(I do have another concern that the two documents overlap 
substantially in core content even though they present it differently, 
but that is a different issue.)

My reasons for supporting the documents as Informational RFCs
(as opposed to Normative RFCs): 
These documents offer algorithms that are meant to 
be used internally in routers, the outcome of which are used 
for local decision within an AS to assist path selection, and the 
origin validation outcomes are not communicated to other ASes in eBGP. 
ISPs together with their vendors may use ROA information 
in path selection with modified or other enhanced algorithms 
for origin validation as they find suitable.
So the relying parties (RPs) may use these documents as guides but 
may not like to be bound to them as a normative IETF standard or RFC.

One may argue that we need to have agreed upon semantics
about how ROAs will be interpreted in origin validation. 
In final full deployment state, the validation states are Valid or Invalid;
those two validation states are unambiguously agreed upon 
interpretations (in the full deployment state).
But during partial deployment, there is ambiguity anyway.
Some routers will accept "Unknown"; some may not.
Some routers may accept "Invalid" if there is no other 
update with higher validation state; some may reject them outright, and so on.
Some RPs may like to treat prefix-length violations less punitively 
if the origin AS is matched (during partial deployment). 
Some ISP routers may assign "Valid" state to customers' prefixes even when 
they do not have ROAs just because the {prefix, Origin AS} associations 
are well known for their own customers.
Partial deployment period may be quite prolonged.
This is where the RP may need to have the flexibility.

I feel that the documents (published as Information RFCs) would be
excellent for providing general agreed upon understanding
about the possible origin validation approaches based on ROAs 
but should not strictly bind the relying parties to the recommendations
(especially, under partial deployment scenarios).

Sriram

---

From: Geoff Huston <[email-masked]>
Date: Tue, 23 Nov 2010 14:46:42 +1100

> i.e., be advanced for publication as an Informational RFC.

That was indeed the intention: please note line 3 of the document:

Secure Inter-Domain Routing (SIDR)                             G. Huston
Internet-Draft                                             G. Michaelson
Intended status: Informational                                     APNIC
Expires: May 15, 2011                                  November 11, 2010

thanks,

   Geoff

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Nov 2010 12:33:23 -0500

I'm not sure I agree with this document being Informational.  ROAs  
need to have some well-defined authorization semantic.  Just like  
information in BGP itself, ROAs communicate information between  
domains, so the creators and consumers of ROAs need to know what  
authorization is being communicated.  In other words, what needs to be  
standard is a validate(roa[], route) routine that says whether a given  
set of ROAs authorize, deny, or ignore a given route.

Sriram is correct that AS-internal stuff should be Informational.  The  
AS-internal stuff we're talking about here is what an AS does with the  
output of the validate(), basically a "deployment considerations"  
document.

In terms of the documents in hand: As I read it, -roa-validation would  
be a good basis for the Standards Track document I describe above if  
we just remove Section 3, which talks about what you do with  
validation outputs.  -pfx-validate seems like a good candidate for the  
Informational document.  As a path forward, it would make sense to me  
to focus -roa-validation on the specific validation semantics of a set  
of ROAs (advancing it as Standards Track) and to focus -pfx-validate  
on what an AS can do with these validation results (as Informational).

Finally, one specific note on -roa-validation and -roa-format.  Before  
I wrote this email, to make sure I understood things correctly, I  
wrote a test implementation of the validation algorithm [1].  My  
comment as an implementor is that the documents don't make it very  
clear how to implement the algorithm described in Section 2 of -roa- 
validation.  For instance, it's not obvious that the length of the  
prefix is specified implicitly as the length of the IPAddress BIT  
STRING.  In general, it would be helpful if Section 2 of the -roa- 
validation document were more specific, phrasing things in terms of  
the data elements in hand instead of more abstract concepts like  
"covering aggregate" (which the developer has to interpret as   
"shorter prefix, same bits").

Sorry to enter the discussion so late, but I hope this is helpful,
--Richard

[1] <http://geopriv.dreamhosters.com/roaver.cpp>

On Nov 22, 2010, at 10:46 PM, Geoff Huston wrote:

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