Subject: [sidr] Comment on draft-ietf-sidr-origin-validation-signaling-01

From: Danny McPherson <[email-masked]>
Date: Mon, 14 Nov 2011 21:12:13 -0500

In general, I don't like the idea of using an extcomm community to convey 
a prefixes validation state, I think we should deal with this problem natively 
(e.g., as BGPSEC inter-domain) if we're going to address the problem, in
particular if we're not going to address the AS Confederations problem.

Furthermore, I don't like the deployment considerations, in particular because 
of "privilege escalation attacks" which could easily occur through misconfiguration 
across multiple attribute mapping functions, or simply because the extcomm was
received from an BGP peer that isn't "upgraded to support the extensions 
defined in this document":

   "In deployment scenarios where not all the speakers in an autonomous
   system are upgraded to support the extensions defined in this
   document, it is necessary to define policies that match on the origin
   validation extended community and set another BGP attribute
   [I-D.ietf-sidr-pfx-validate] that influences the best path selection
   the same way as what would have been enabled by an implementation of
   this extension."

Finally, this should certainly a normative reference in the pfx-validate draft.

-danny

---

From: Pradosh Mohapatra <[email-masked]>
Date: Tue, 15 Nov 2011 15:39:35 -0800

Hi Danny,

Thanks for the comments.

> particular if we're not going to address the AS Confederations  

Can you describe specific concerns you have with using extended  
community?
It does work with confederations.

>   the same way as what would have been enabled by an implementation of

Do you have alternatives in mind for incremental deployment case?

> Finally, this should certainly a normative reference in the pfx- 

Ack.

- Pradosh

---

From: Danny McPherson <[email-masked]>
Date: Tue, 15 Nov 2011 19:56:29 -0500

On Nov 15, 2011, at 6:39 PM, Pradosh Mohapatra wrote:

> Can you describe specific concerns you have with using extended community?

Confederation in this context was referring to the _current inability 
of BGPSEC to natively accommodate AS confederations, or IBGP 
in general, for that matter, where Member-ASes commonly apply
'policy' at Member-ASBRs and no implicit transitive trust relationship
would exist.

While I don't want to overly conflate this function with that issue, it 
does intersect in that Opaque Extended Communities already assume 
a transitive trust relationship and in a world where the value of an Opaque 
Extended Community would be used to convey the validation state of a 
prefix an IBGP speaker has no way to validate the semantic integrity of 
the string.  Its essentially what I have today, and into the future secure
routing should enable me to verify this.

> Do you have alternatives in mind for incremental deployment case?

I'm not sure what you mean by "incremental deployment" here, are
you referring to the case where it gets enabled and deployed but 
no IBGP speaker applies policy based on the validation state until 
all IBGP speakers support prefix origin validation capability as defined 
in the document?  I suspect this is what S3.1 is implicitly conveying.

I'm not convinced incremental deployment of the validation state 
processing capability within IBGP should be supported.  The current 
Deployment Considerations section makes me uneasy in that it's 
essentially saying "if you don't support this Opaque value and 
decision algorithm modification as prescribed in S.3 then you should 
develop static policy maps that influences the best path selection *the 
same way* as what would have been enabled by an implementation
of this extension." -- i.e., that may not even be feasible in some 
operating environments and the complexity it presents is likely 
conducive to misconfiguration that introduce forwarding loops in
the network.

Does that make sense?

-danny