Re: [Idr] My mic comments on security

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 <idr-bounces@ietf.org> On Behalf Of Paul Wouters
Sent: Thursday, July 25, 2019 7:45 AM
To: idr@ietf.org
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.

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

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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr