[IPsec] Review of draft-hujun-idr-bgp-ipsec-00

Paul Wouters <paul@nohats.ca> Wed, 24 July 2019 15:39 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679BB1202AE; Wed, 24 Jul 2019 08:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 oMKKK_cPMR74; Wed, 24 Jul 2019 08:39:33 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 3A72D120386; Wed, 24 Jul 2019 08:39:32 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45tzzk13NLzDK8; Wed, 24 Jul 2019 17:39:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1563982770; bh=MfvO0d4ysyg3eacVguzoPFEu2k0xLSc18gXbAu8le0c=; h=Date:From:To:cc:Subject; b=MgdG6c+p//vG4xHWKKU41bdwLUy1irC4IY5+nuuSH/ecbzEWiDyOYUcAS6kFjcORj K1AKez8r5+i0JwiAtLRaNhHsS2eK1Cq2c+T4JZYEM1asOH1MhAbsqwVZyQC1pVhqqH vXfHRkxnX89/veZ87diaQZAwRaG0GaApmKoHuBTw=
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 GnH26DSaDZur; Wed, 24 Jul 2019 17:39:28 +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; Wed, 24 Jul 2019 17:39:27 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id DAFAB353F94; Wed, 24 Jul 2019 11:39:26 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DAFAB353F94
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CDA6E40A6FFE; Wed, 24 Jul 2019 11:39:26 -0400 (EDT)
Date: Wed, 24 Jul 2019 11:39:22 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: idr@ietf.org
cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Message-ID: <alpine.LRH.2.21.1907241129270.29226@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/6zyQF9CWwXiX9d-Lx7aFUowmjoE>
Subject: [IPsec] Review of draft-hujun-idr-bgp-ipsec-00
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 15:39:36 -0000

Hi,

Note that I am an IPsec person and not a routing expert.

The document's idea looks fine to me. It is using BGP messages
to provision IKEv2 so that IPsec tunnels can be setup to protect
packets as best as possible. That's great :)

And unlike most proposals the IPsec WG sees, this document does not try
to replace IKEv2 with its own smarter Key Exchange protocol, so that's
a double plus :)

Thanks for reaching out to the ipsec WG, we really appreciate the chance
to read drafts that use IPsec to give advise.


Below are some of my comments and questions I have:



- Configuring large number of tunnels is error prone and not scalable
   * Only true to some extend
   * See AutoVPN, DMVPM, NHRP+IKE
   * Still, this provisioning system seems to fit your eco system. It's as simple as it can be and
     does not seem to introduce any new complexity or risks.

- What is "color"?

- Section 3, step 4:

        When a router need to forward a packet along a path is determined
        by a BGP UPDATE which has a tunnel encapsulation attribute that
        contains one or more IPsec TLV, and router decides use IPsec
        based on local policy,

Required vs Optional IPsec issue. If only one end has "required" and the
other end has "optional" then unencrypted packets will be dropped. Seeing
IPsec tunnel TLV should probably mean it is mandatory to setup a tunnel?

It can be done as "optional" but then the IPsec/kernel mechanisms cannot
trigger an IKE/IPsec negotiation and this protocol needs to be
responsible for not just configuring IKEv2/IPsec but also for bringing
up the tunnels when needed.


- Section 3, step 6:

   - signaling IPsec configuration

Call it IPsec provisioning ?

- Examples are using less prefered and slower algorithms
   * Change AES-CBC-256 with SHA-384. to AES-GCM-256 or CHACHA20_POLY1305
   * Change NULL-SHA256 to NULL-AES-GMAC

- 1/128 and 2/128 ?

       For 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled
       Unicast), these NLRI has embedded label, which cause the payload
       packet can't be encapsulated in ESP packet,

I don't understand why 1/128 or 2/128 are special ?

Open questions:

- If the IKEv2 protocol fails, what happens with packets? Release in clear or drop?
   Is this something the BGP should configure/provision ? If not, it should state
   which of the two is expected

- If a router R1 and R2 have an ipsec tunnel for some traffic, and R1 crashes/reboots,
   how do things recover? R2 will send packets and might not know something is wrong, unless
   it is configured for liveness. What happens when R1 comes back up? If all BGP routes
   are taken away via another mechanism, then I guess R2 would simply delete its tunnel.

- Performance: if routes are large (eg 0/128) then very few tunnels would cover lots of
   routes. In general, having more parallel smaller CHILD SA's outperforms a single or two
   CHILD SA's by far. This could introduce performance issues.

- Some IPsec options not mentioned could prevent a tunnel from being setup, such as
   whether to use Extended Sequence Numbers (ESN), or Perfect Forward Secrecry (PFS).
   Some of these could be locked down in the document (PFS=yes) but things like ESN
   really depend on the bandwidth of the tunnel.

- Maybe some advise on replay-window size would be good. Larger is better but takes more
   memory. Matters mostly for highspeed links.


Paul