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

[John Scudder <[e-mail]>]

Brian,

Danny is talking about pfx-validate, which is not the same as BGPSEC.

--John

On Nov 13, 2011, at 1:48 AM, Brian Dickson wrote:

> 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
>> 
>> 
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr