Re: [sidr] Signed vs unsgned and bgp best path decision

[Christopher Morrow <[e-mail]>]

On Fri, Mar 23, 2012 at 6:59 AM, Robert Raszuk <[e-mail]> wrote:
>
>>> When compared to what is today I don't think folks are mandated by any
>>> RFC
>>> to make a choice between two attributes which carry the same metric to
>>> decide which one should win on a per AS basis.
>>
>>
>> they are not, and in the future the 'mandate' is I believe a 'SHOULD',
>> not a 'MUST' so not really a 'mandate', but a 'suggestion', eh?
>>
>> It seems that the intent of the effort here is really just to provide
>> an informational blob to the operators which they can use as they see
>> fit... much like other optional transitive attributes today.
>
>
> Ok that sounds very reasonable indeed.

progress!

> However number of folks have stated that bgpsec protocol proposal calls for
> replacing AS-PATH and AS4_PATH attributes with BGPSEC_Path_Sig attribute. In
> particular this text from /draft-ietf-sidr-bgpsec-protocol-02 sort of
> suggests that:
>
>   The other option is that the BGPSEC speaker

'other option'

>   discards anything in the AS_PATH attribute and reconstructs the

I believe this means: "You could just ignore AS_PATH and reconstruct
the content there from ..."
(or that's how I read the clipping)

>   AS_PATH from the data in the BGPSEC_Path_Signatures attribute.  I
>   believe that there are no interoperability problems if the choice
>   between these two options is left up to the BGPSEC speaker.

probably in this last sentence they mean "bgpsec listener" (since this
is on the receiver, not the sender?)

> Also it says in the same section 5:
>
>   One option the

'option'

>   BGPSEC speaker checks the AS_PATH attribute against the information
>   in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the
>   two do not match.
>
> That means that if AS_PATH for example contains AS_SET that someone doing
> BGP multipath (across non identical paths) has correctly inserted into
> AS_PATH or as mentioned before did replace-as the update will be dropped as
> BGPSEC just can not handle those ....

sure. 'option' I don't think if there were an AS_SET in the update
coming from the BGPSEC speaking peer there would be sig parts to worry
about (since the inclusion of AS_SET means you can't secure the
path...So, I suppose if this condition exists the path is invalid by
default? and likely spoof/bad/malicious?)

>
>
> Meta question:
>
> Can optional attribute result in such drastic actions (nothing to do with
> operator's choice of local behavior) against mandatory attribute(s) ?

I think you created a situation which is actually in violation of the
standard... or which would be seen as a malicious update and which
should be dropped, so I'm not sure your meta-question follows properly
here?

-chris