Stephen,
Please see responses inline below.
>>[Sriram] Signer's ASN is indeed included in the signed data.
>> In Figure 8, "Secure_Path Segment : N" corresponds
>> to the signing AS (current AS) and that is where the
>> signer's ASN is included along with its pCount and Flags.
>Hmm. That's the target ASN of the previous signer though.
Semantically the "Secure_Path Segment: N" shown in the
data to be hashed in Figure 8, contains the current
signer's ASN, although logically it is equal to
the target ASN of the previous signer.
>I thought there were cases where they could differ? But
>if not, then you probably need to state that as a rule
>for checking signatures, is that there already? (Happy to
>check later, but don't have time right now.)
They had differed in one situation but that was
before we put in a fix for the confederation boundary,
and that fix is in the second paragraph of Section 4.3
of version-21. So now we are good. Yes, now
a signer's ASN always equals the target ASN
used in the hashed data by the previous signer.
So in the signature validation, the verifier always
plugs in its own ASN as the target ASN for validation
of the most recently added signature. Without that the
validation of that signature will fail.
That rule is built in into the validation process (page 26):
"For the first segment to be processed (the most
recently added segment (i.e. N = K) given that there are K hops
in the Secure_Path), the 'Target AS Number' is AS(K+1), the AS
number of the BGPsec speaker validating the update message."
>>> - 5.2, I think you need to say something to the effect
>>> that every Secure_Path MUST have a signature with an
>>> algorithm that is supported. As I read the text, the
>>> algorithm as stated here could be read to not require
>>> that. E.g. the para before the bullets on p25 could be
>>> read to mean "drop all stuff involving unsupported algs
>>> and then continue to process the rest of the stuff."
>>>
>> [Sriram] Seems like a bit of a pathological case.
>> Could happen only if the sender behavior was incorrect.
>Yes, but 5.2 is verifier behaviour and ought not
>assume a correct signer, so I do think the alg
>presented here needs to cover such things.
Please see response below.
>> Sender is not required to know which algorithms a peer supports
>> but sender's expected behavior is this: MUST include a Signature_Block
> for the "current" algorithm (which every BGPsec speaker
>> MUST support through the transition period),
>Where does it say that the current/next thing applies
>to the entire world of BGPsec? I didn't read it that
>way as it happens, but rather that the current/next
>could involve different algorithms at different nodes
>at the same time.
>
>So e.g. I read it to be allowed that a migration from
>rsa/sha256 then to ecdsa then to eddsa could occur
>with some non-updated nodes still signing with rsa/sha256
>whilst some shiny new nodes are doing ecdsa and eddsa and
>others are in between.
>
>I do agree that a global current/next pair of algs
>is nicer, if that is what's wanted. But I don't recall
>the text saying that. (Again happy to check later, but
>no time right now;-)
The text does describe it in terms of
"a global current/new pair of algs" in Section 6.1 (p. 28, v-21):
"To this end, a mandatory algorithm suites document exists which
specifies a mandatory-to-use 'current' algorithm suite for use by all
BGPsec speakers [I-D.ietf-sidr-bgpsec-algs].
It is anticipated that, in the future, the mandatory algorithm suites
document will be updated to specify a transition from the 'current'
algorithm suite to a 'new' algorithm suite. During the period of
transition (likely a small number of years), all BGPsec update
messages SHOULD simultaneously use both the 'current' algorithm suite
and the 'new' algorithm suite. (Note that Section 3 and Section 4
specify how the BGPsec_Path attribute can contain signatures, in
parallel, for two algorithm suites.) Once the transition is
complete, use of the old 'current' algorithm will be deprecated, use
of the 'new' algorithm will be mandatory, …."
Thank you.
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
