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 protected] on behalf of [email protected]> wrote: 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. 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 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. 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 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? Ali> Yes, MTU size should be captured in our documents. - 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. 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 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 Ali> Yes, besides IKEv2, we also need to handle multicast for IPsec SA using BGP-based signaling. - 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. Ali> We will factor that in for BGP-based signaling. - 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. Ali> Sure, we will factor that in as well. Regards, Ali 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 [email protected] https://www.ietf.org/mailman/listinfo/idr _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
