[Idr] My mic comments on security

Paul Wouters <paul@nohats.ca> Thu, 25 July 2019 14:46 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311AB12006D for <idr@ietfa.amsl.com>; Thu, 25 Jul 2019 07:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEypzXM4PVEM for <idr@ietfa.amsl.com>; Thu, 25 Jul 2019 07:46:17 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21741201C9 for <idr@ietf.org>; Thu, 25 Jul 2019 07:45:04 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45vZkR0GdfzKvx for <idr@ietf.org>; Thu, 25 Jul 2019 16:45:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1564065903; bh=4HVuQ8onTir+4+KInQgx2Uv6+Hue8JZDef5Dy1WgmDo=; h=Date:From:To:Subject; b=H6JSGKlF2our9e4ul+OBG8po1l/OJ9Dkt6O22e4wBt7XkU9XKK7VpuZPdTgNiq4px VWSg2aIJD3wdgmV3WeHvtacC1EE5QXokT4nSdsaPuek9vPnzkTOkDmtXxITzLl9AXM 8RdeAtuMajlah0HyBn4ccuzAgLPMSm8a5+hrEA0k=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id e1p2cKlinEfZ for <idr@ietf.org>; Thu, 25 Jul 2019 16:45:01 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <idr@ietf.org>; Thu, 25 Jul 2019 16:45:00 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6B77E394973; Thu, 25 Jul 2019 10:44:59 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6B77E394973
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 62BD740A6FFE for <idr@ietf.org>; Thu, 25 Jul 2019 10:44:59 -0400 (EDT)
Date: Thu, 25 Jul 2019 10:44:59 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: idr@ietf.org
Message-ID: <alpine.LRH.2.21.1907251026480.23797@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Ytf0mlAajaPDLS18zFpFAvMuKmA>
Subject: [Idr] My mic comments on security
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 14:46:20 -0000

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