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

[Pradosh Mohapatra <[e-mail]>]

Hi Danny,

Thanks for the comments.

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

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

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

Do you have alternatives in mind for incremental deployment case?

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

Ack.

- Pradosh