Subject: [Idr] My mic comments on security

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Jul 2019 10:44:59 -0400 (EDT)

Note I had some questions in my previous post, that related to
draft-hujun-idr-bgp-ipsec-00 but also applies to some of the
other proposed solutions.

At the mic I had the following questions/comments:

- IPsecGW's vs Routes

Depending on the amount of IPsec hosts versus the amount of routes (aka
IPsec SA's), there are two different models that might apply better.

1) A host to host IPsec connection in transport mode, using GRE or
    similar to add/remote routes without needing to update IPsec state
2) A host to host IPsec connection un tunnel mode, which a single IPsec
    SA per route object.

There are likely scenarios where either one will perform better.

- Optional vs Mandatory

My question was whether an indication for IPsec is a commitment to
require it or a suggestion to use it. That will cause some
implementation differences. For example, kernel ACQUIRES can only
be generated when the policy is mandatory - that is plaintext packets
will be dropped until an IPsec tunnel is up.

- MTU issues

By adding another layer of encapsulation with IPsec, the MTU is slightly
reduced. I did not find text about this in the drafts. Should the
administrator or implementation do something to counter the slightly
smaller usable MTU or is it expected that each flow handles this itself
in the normal path mtu discovery?

- Round Trip Time

One can setup a childless IKEv2 SA (two roundtrips) between hosts in
anticipation of routes. Then the first route that would need an IPsec
tunnel only requires one roundtrip instead of two round trips.

This might not matter at the scale things happen, but often in a mesh
of nodes doing crypto, the majority of nodes do not talk to each other
and this work might be overkill for theoretical saving of 1 RTT upon
route object change.

- Multicast IPsec

While it was supported in IKEv1 (which you should not use), work for
this is still in progress for IKEv2. If you need this support, it would
be good to let the authors of draft-yeung-g-ikev2 know that they have
some new potential customers and please proceed with the work.
https://tools.ietf.org/html/draft-yeung-g-ikev2-16

- Session resumption

I'm not sure if this can be applicable but using session resumption
instead of deleting and starting from scratch for a new IKE SA
would save precious CPU time.

- Tunnel inactivity

Please do not start using liveness/DPD at the once per second time
frame. There are other methods to detect tunnel inactivity, such
as using a PFKEY/NETLINK API call that installs a soft-idle timer
within the kernel.

Please note I'm not on this list. If you wish to get my attention,
feel free to CC: to messages to the idr list.

Paul

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 25 Jul 2019 21:50:49 +0000

Hi Paul,

Thanks for your  comments and discussions at the mic yesterday and summarizing them below. Please refer to my reply in line marked with "Ali>"

On 7/25/19, 7:46 AM, "Idr on behalf of Paul Wouters" <[email-masked] on behalf of [email-masked]> wrote:

    
    - IPsecGW's vs Routes

    
    
Ali> There are use cases for both. As I was explaining yesterday, there are different level of granularity and there can very well be simultaneous IPsec SA for these different level of granularity. For example an edge box supporting 100 tenants can have a single IPsec SA for 90 of these tenants but for other 10 tenants, there can be a need for a separate IP-sec SA per tenant.

    - Optional vs Mandatory

Ali> This is a matter of local policy but I agree that a default behavior should be specified. So, the default behavior in case of IPsec should be conservative and if the tunnel is not available, then drop as opposed to send it in clear. However, if a coarser tunnel is available (e.g., in the example above, there is a IPsec tunnel per box but the tenant IPsec become unavailable), then I think the default behavior should be use the coarser tunnel temporally (for a default duration of time).
    
    - MTU issues

Ali> Yes, MTU size should be captured in our documents.

    - Round Trip Time

Ali> This optimization doesn't apply to BGP-based signaling and in case of IKE as you pointed out it doesn't make a dent to O(N^2) number of messages needed when full-mesh of IKE sessions needed among N nodes.
    
    - Multicast IPsec

Ali>  Yes, besides IKEv2, we also need to handle multicast for IPsec SA using BGP-based signaling. 
    
    - Session resumption

Ali>  We will factor that in for BGP-based signaling.

    - Tunnel inactivity

Ali> Sure, we will factor that in as well. 

Regards,
Ali

    Paul
    
    _______________________________________________
    Idr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/idr

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 26 Jul 2019 02:20:23 +0000

Hi Paul,
I just replied to your other email regarding my draft;
My comments for this are in line below as [Hu Jun]

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Paul Wouters
Sent: Thursday, July 25, 2019 7:45 AM
To: [email-masked]
Subject: [Idr] My mic comments on security

Note I had some questions in my previous post, that related to
draft-hujun-idr-bgp-ipsec-00 but also applies to some of the other proposed solutions.

- IPsecGW's vs Routes

Depending on the amount of IPsec hosts versus the amount of routes (aka IPsec SA's), there are two different models that might apply better.

1) A host to host IPsec connection in transport mode, using GRE or
    similar to add/remote routes without needing to update IPsec state
2) A host to host IPsec connection un tunnel mode, which a single IPsec
    SA per route object.
[Hu Jun] yes, there are use case for both; however using IPsec transport mode does raise a interesting point, currently my draft doesn't include transport mode; using transport with another tunnel type like GRE is kind special, since it is not tunnel stack/nest, I think currently there is no existing mechanism in the framework of draft-ietf-idr-tunnel-encaps to support transport mode; we need to define a new one; I could include this in next revision of my draft

- Optional vs Mandatory

My question was whether an indication for IPsec is a commitment to require it or a suggestion to use it. That will cause some implementation differences. For example, kernel ACQUIRES can only be generated when the policy is mandatory - that is plaintext packets will be dropped until an IPsec tunnel is up.
[Hu Jun] as I replied in the other email, this depends on if there is other tunnel type TLV in the same BGP update, if yes, then based on local policy user could chose another type; but if user want to enforce of using IPsec, then just only include IPsec tunnel TLV 

- MTU issues

By adding another layer of encapsulation with IPsec, the MTU is slightly reduced. I did not find text about this in the drafts. Should the administrator or implementation do something to counter the slightly smaller usable MTU or is it expected that each flow handles this itself in the normal path mtu discovery?
[Hu Jun] this is a general understood issue whenever tunnel is involved, but I agree some text in draft-ietf-idr-tunnel-encaps won't hurt 

- Round Trip Time

One can setup a childless IKEv2 SA (two roundtrips) between hosts in anticipation of routes. Then the first route that would need an IPsec tunnel only requires one roundtrip instead of two round trips.

This might not matter at the scale things happen, but often in a mesh of nodes doing crypto, the majority of nodes do not talk to each other and this work might be overkill for theoretical saving of 1 RTT upon route object change.
[Hu Jun] this could be local decision 

- Multicast IPsec

While it was supported in IKEv1 (which you should not use), work for this is still in progress for IKEv2. If you need this support, it would be good to let the authors of draft-yeung-g-ikev2 know that they have some new potential customers and please proceed with the work.
https://tools.ietf.org/html/draft-yeung-g-ikev2-16
[Hu Jun] multicast is important for Ipsec, we need group key for IKEv2, will send a email to the authors 

- Session resumption

I'm not sure if this can be applicable but using session resumption instead of deleting and starting from scratch for a new IKE SA would save precious CPU time.
[Hu Jun] agree

- Tunnel inactivity

Please do not start using liveness/DPD at the once per second time frame. There are other methods to detect tunnel inactivity, such as using a PFKEY/NETLINK API call that installs a soft-idle timer within the kernel.

[Hu Jun] another faster, and commonly implemented mechanism would be DPD; just run DPD over Ipsec 

Please note I'm not on this list. If you wish to get my attention, feel free to CC: to messages to the idr list.

Paul