Re: [Idr] My mic comments on security

["Ali Sajassi (sajassi)" <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/idr