[Idr] My mic comments on security

[Paul Wouters <[e-mail]>]

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