In looking at the BGP security requirements document,
http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-10.txt
I find these points (for instance):
4.2. Incremental deployment
"Any proposed solution MUST support an incremental
deployment which will provide some benefit for those who
participate."
"In an environment where both secured and non-secured systems are
interoperating a mechanism MUST exist for secured systems to
identify whether an originator intended the information to be
secured."
This language is very strong guidance that we need both partial
deployment
technology, and mechanisms to allow the ORIGINATOR to say if its
covered or not.
In that sense, a BOA is a strong statement by the prefix owner they
intend all
more specifics to be covered by explicit security, ie casual more
specifics without
ROA are being actively dis-allowed. I do not see methods using the ROA
alone which
can convey this, with the same purpose or precision.
The ROA validation draft:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-01.txt
has:
3. Applying Validation Outcomes to BGP Route Selection
(second para)
In the case of partial deployment of ROAs there are a very limited
set of circumstances where the outcome of ROA validation can be used
as grounds to reject all consideration of the route object as an
invalid advertisement. While the presence of a valid ROA that
matches the advertisement is a strong indication that an
advertisement matches the authority provided by the prefix holder to
advertise the prefix into the routing system, the absence of a ROA or
the invalidity of a covering ROA does not provide a conclusive
indication that the advertisement has been undertaken without the
address holder's permission, unless the object is described in a BOA.
I still believe this. I think the BOA substantively adds information
into the
system about routing security, and I think it is *completely* on-
charter for us given
the bgpsecrec draft guidance.
-G
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
