Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker

[Ruediger Volk <[e-mail]>]

  > Howdy WG folk!
  > The authors of: draft-ietf-sidrops-validating-bgp-speaker
  > are thinking their draft is ready to move forward, there hasn't been
  > significant conversation about this document since the last meeting in
  > Montreal... so:

I believe this looked much more innocent (just the document name?)
at the adoption call (and slipped under my radar - like too many things).

This draft is not acceptable for a number (>1) of reasons.
The primary being: it introduces security problems by
carrying security information over uncontrolled paths
without securing authenticity.
By choosing extended community as the container for the unauthenticated information the problem is made worse,
because for a long time we cannot assume that operator will
have methods operational for controlling propagation of that unauthenticated security information; and the draft does 
not seem to propose or consider any methods and practices 
for controlling and limiting propagation - except .

To illustrate the class of problem I give an example:
I'm operating AS64510. Anybody connected to the global BGP 
can inject routes with the proposed extended community
or (using special hacked BGP) the extended community
to routes it propagates indicating whatever validation state
suits their purpose and indicate that high reputation AS64510
is source of the validation state.
Now AS64510 does not even has a way diagnosing presence or removing
of that fake information; note: for handling extended communities
vendors actually have to spin code - even to support generic
policy primitives such as delete or match (as a decision criterium).

The security considerations are certainly seriously incomplete.
Explicit and prominent note of transitive propagation of
unauthenticated security information MUST be added
(even a reference to general BGP security analysis that
warns about missing authencation and authenticity of BGP routes
and attributes is missing!).

Some consideration of the trust relations involved with signaling
the extended community or using it as a relying party in 
local policy would be needed.
>From that point of view it looks strange that no mention of
the relying party controlling which source over which path
it trusts.

While searching through the document for the security handling
I came across quite some spots that looked like somewhat fuzzy
in terminology or otherwise lacking - not ready for publication.

In some protocol proposals it is a good idea to clearly identify
the functions of implementations that need configuration,
and whether the default should be ON or OFF.
Here it quite definitely ought to be default OFF!

I believe the draft should be declared dead;
perhaps after a final spin that inserts a security warning..
Discussion of requirements and reasonable approaches 
to reduce operational burden of origin validation
may be needed.  However this draft not help for that!

The basic signal flow idea of this draft could be handled easily
in already available/deployed router software with user 
configured policy with much better control;
someone desperate could be using it in a months time ./.
waiting more than a year for new router software version.
+ we should help the vendors to focus on fixing and completing
the standard RPKI OV functionality (think clarify-ov)
and avoid diverting energy and attention to another new feature.

Different approaches to outsourcing of the security function
may be more secure and much easier to configure.
Documenting a solution obviously would be helpful to some
and could help to avoid some bad security designs. 

Ruediger Volk