Re: [Rift] Status update on security interop testing between RIFT-Juniper and RIFT-Python

[Tony Przygienda <[e-mail]>]

splendid & as usual thanks for the work Bruno ;-)  Zero protocol
interop-problems result speaks for itself as to quality of the spec I guess
[albeit to be honest we had a chat about the nonces, I'll update folks @
IETF] ;-) For me as matter of interest if any security person cares to
chime in; how important is HMAC-SHA-256 vs. SHA-256 ? I looked @ trade-offs
on SHA-224 ... SHA-512 and looks like SHA-256 was about the sweet-spot in
size/security/library support on all kind of systems, that's why I went for
it in first iteration.

I know that I changed yaml file keywords but I realized that we'll have a
clash in the future with key/value implementation in RIFT itself if we call
security-keys just "keys" so it was better eating crow now ...

The per-interface vs. node model on outer key is largely convienence. I
prefer to an outer configuration system/model like YANG or NETCONF to
support that kind of inheritance hierarchy from experience since it
complicates very quickly protocol implementation itself otherwise given
possible semantic contradictions and so on ...

--- tony


On Wed, Jul 17, 2019 at 5:41 AM Bruno Rijsman <[e-mail]>
wrote:

> Status update on security interop testing between RIFT-Juniper and
> RIFT-Python:
>
> The outer keys are now interoperating fine.
>
> (A) As expected, the adjacency between RIFT-Juniper and RIFT-Python comes
> up to state 3way, when
>
>   (A1) authentication is disabled or
>
>   (A2) authentication is enabled with the same active keys or
>
>   (A3) authentication is enabled with different active keys and
> corresponding accept keys.
>
> (B) As expected, the adjacency between RIFT-Juniper and RIFT-Python does
> not come up to state 3way, when
>
>   (B1) Authentication is enabled on one side but not the other side
>
>   (B2) Authentication is enabled with different active keys and without
> corresponding accept keys
>
> Challenges along the way:
>
>   (C1) Juniper uses SHA-256(key + payload) whereas RIFT-Python uses
> HMAC-SHA-256(key, payload).  Solution: add support for SHA-256(key +
> payload) to RIFT-Python (in addition to HMAC-SHA-256).
>
>   (C2) RIFT-Juniper used different YAML configuration keywords than
> RIFT-Python.  Solution: change RIFT-Python to use the same configuration
> keywords.
>
>   (C3) RIFT-Juniper only support configuration of outer keys on a
> per-interface basis, whereas RIFT-Python support configuring the outer keys
> on a per-node and per-interface basis with an inheritance rule.  Solution:
> for interop testing, only use per-interface configuration.
>
>   (C4) RIFT-Juniper only supports SHA-256, whereas RIFT-Python also
> supports other key lengths (e.g. SHA-224, SHA-384, and more).  Solution:
> limit interop testing to SHA-256.
>
> All four of these issues are implementation issues, and none of these
> issues require any changes to the draft.
>
> Next step: finish interop testing for the origin keys. (I plan to do this
> Thursday  morning, Netherlands time)
>
> — Bruno
>
>