Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03

[Brian Dickson <[e-mail]>]

I think the current design of BGPsec as memorialized (love that word) in the
draft-ietf-sidr-bgpsec-protocol would need to be tweaked to handle this.

I also believe that the result of the proposed tweak, will be a cleaner design
which is easier to implement and verify, as well as not incurring significant
operational cost in terms of signatures.

Local origination SHOULD occur within an AS on a permanent
basis, and only the announcements from the actual originating router need
to have unique signatures, regardless of whether they are iBGP or eBGP.

(Crypto geeks might suggest adding a random "nonce" to make the signature
a little harder to crack, since very little on the signature material
will change
over time - but that is another discussion.)

Here is the tweak:

                      Sequence of Octets to be Signed
                 +---------------------------------------+
                 | Expire Time (8 octets)                |
                 +---------------------------------------+
                 | Origin AS Number (4 octets)           |
                 +---------------------------------------+
                 | Algorithm Suite Identifier  (1 octet) |
                 +---------------------------------------+
                 | NLRI Length  (1 octet)                |
                 +---------------------------------------+
                 | NLRI Prefix  (variable)               |
                 +---------------------------------------+

The "Target AS" and "pCount" need to be added, meaning the minimum
number of signatures
changes to "one origin" and "one propagation" signature.

For iBGP within the originating AS, the signature would be "Target AS
== origin AS", and "pCount == 0".

For eBGP, it would be what you expect, "Target AS == neighbor", "pCount > 0".

I think that's all that is needed, and the rest of the validation
logic in the -protocol doc remain good,
the -ops-reqs doc allows validation for local AS, and pfx-validate also works.

Any detail or logic errors in the above can be attributed to not
enough caffeine... The gist of the above
should be solid enough, though.

Brian

On Sat, Nov 12, 2011 at 11:54 AM, Danny McPherson <[e-mail]> wrote:
>
> My read of the current draft suggests that if there's a route generated by
> the
> local AS in BGP it could never have a "Valid" state, and by definition
> would
> either posses a "Not found" or "Invalid" state -- even though the local
> AS may well have a "ROA" and reside in the mapping table as well(!).
> I do not believe the current text is Section 5 is sufficient to address this
> case,
> specifically with either this:
> "Considering invalid routes for BGP decision process is
> a pure local policy matter and should be done with utmost care."
> or this:
> "In some cases (particularly when the selection algorithm is
> influenced by the adjustment of a route property that is not
> propagated into IBGP) it could be necessary for routing
> correctness to propagate the validation state to the IBGP
> peer. This can be accomplished on the sending side by setting
> a community or extended community based on the validation
> state, and on the receiving side by matching the (extended)
> community and setting the validation state."
> I could think of a number of way to address this, but for there to exist
> the
> possibility that an internally generated prefix (for which a ROA may well
> exists)
> could NEVER have a "Valid" state needs to be corrected.
> Also, S 4:  s/to rest of the network/to the rest of the network/
> Thanks,
> -danny
>
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>
>