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

From: Bruno Rijsman <[email-masked]>
Date: Wed, 17 Jul 2019 14:41:11 +0200

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

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 17 Jul 2019 05:57:26 -0700

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 <[email-masked]>
wrote:

>   (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.
>

---

From: Bruno Rijsman <[email-masked]>
Date: Fri, 19 Jul 2019 12:52:08 +0200

I am happy to report that I have successfully completed interop testing of RIFT security between RIFT-Juniper and RIFT-Python [1].

In my earlier e-mail I had already reported that interoperability was achieved for the outer security envelope.

Now, interoperability for origin security envelope is also working. As before, interop testing included both positive and negative test cases. This completes the interop testing of RIFT security.

We did not find any issues that require changes in the draft. (There was only one very minor implementation issue which was quickly fixed.)

For an updated feature guide of security in RIFT-Python see [2] (many enhancements were added during interop testing).

Much has changed since I wrote the "RIFT Security Review" document [3] and, as a result, it is now out of date. I will update it to reflect the changes in the draft since May and the recent experiences from interop testing. I hope to post the updated version before the RIFT meeting at the IETF-105 in Montreal.

[1] https://github.com/brunorijsman/rift-python <https://github.com/brunorijsman/rift-python>

[2] http://bit.ly/rift-python-security-feature-guide <http://bit.ly/rift-python-security-feature-guide>

[3] http://bit.ly/rift-security-review <http://bit.ly/rift-security-review>

— Bruno

PS: The interoperability tests are fully automated using the “interop.py” script in the RIFT-Python repository. The results can easily be reproduced by anyone with access to the RIFT-Python code (which is publicly available in GitHub), the RIFT-Juniper executable, and an AWS instance or physical Ubuntu server.

> On Jul 17, 2019, at 2:41 PM, Bruno Rijsman <[email-masked]> wrote:
>

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 19 Jul 2019 09:01:22 -0400

Bruno, <thumbs direction="up"/> and as usual thanks for the work. If you
manage some material, great, otherwise I strip 2 viewgraphs when giving
update to the group

with that we have 2 working interop'ed implementation of the spec

BTW, the juniper binary is not on the free download yet (0.10.* is without
sec envelope) but I'll be prep'ing 0.11 download Bruno was using in the
next 2 weeks here (as I mentioned previously, with much more material
around it included than previously given we're pretty much done with the
spec and schemas) ...

thanks, see you all in CA

-- tony

On Fri, Jul 19, 2019 at 6:52 AM Bruno Rijsman <[email-masked]>
wrote:

> I am happy to report that I have successfully completed interop testing of
> RIFT security between RIFT-Juniper and RIFT-Python [1].
>
> In my earlier e-mail I had already reported that interoperability was
> achieved for the outer security envelope.
>
> Now, interoperability for origin security envelope is also working. As
> before, interop testing included both positive and negative test cases.
> This completes the interop testing of RIFT security.
>
> We did not find any issues that require changes in the draft. (There was
> only one very minor implementation issue which was quickly fixed.)
>
> For an updated feature guide of security in RIFT-Python see [2] (many
> enhancements were added during interop testing).
>
> Much has changed since I wrote the "RIFT Security Review" document [3]
> and, as a result, it is now out of date. I will update it to reflect the
> changes in the draft since May and the recent experiences from interop
> testing. I hope to post the updated version before the RIFT meeting at the
> IETF-105 in Montreal.
>
> [1] https://github.com/brunorijsman/rift-python
>
> [2] http://bit.ly/rift-python-security-feature-guide
>
> [3] http://bit.ly/rift-security-review
>
> — Bruno
>
> PS: The interoperability tests are fully automated using the “interop.py”
> script in the RIFT-Python repository. The results can easily be reproduced
> by anyone with access to the RIFT-Python code (which is publicly available
> in GitHub), the RIFT-Juniper executable, and an AWS instance or physical
> Ubuntu server.
>
>

---

From: Bruno Rijsman <[email-masked]>
Date: Fri, 19 Jul 2019 15:03:48 +0200

Hi Tony,

I will have an “open source update" slide deck for you to present. Already a work in progress. I will be ready before the RIFT WG meeting. I will attend remotely.

— Bruno

> On Jul 19, 2019, at 3:01 PM, Tony Przygienda <[email-masked]> wrote:
> 
> Bruno, <thumbs direction="up"/> and as usual thanks for the work. If you manage some material, great, otherwise I strip 2 viewgraphs when giving update to the group 
> 
> BTW, the juniper binary is not on the free download yet (0.10.* is without sec envelope) but I'll be prep'ing 0.11 download Bruno was using in the next 2 weeks here (as I mentioned previously, with much more material around it included than previously given we're pretty much done with the spec and schemas) ... 
> 
> On Fri, Jul 19, 2019 at 6:52 AM Bruno Rijsman <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 17, 2019, at 2:41 PM, Bruno Rijsman <[email-masked] <mailto:[email-masked]>> wrote:
>>