Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
Paul Wouters <paul@nohats.ca> Mon, 22 April 2019 16:19 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEF7120132; Mon, 22 Apr 2019 09:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 d9DpN2G1IYaH; Mon, 22 Apr 2019 09:19:18 -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 72FB0120129; Mon, 22 Apr 2019 09:19:18 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44nsGW2rvZzDwT; Mon, 22 Apr 2019 18:19:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1555949955; bh=YwRRkY/Q/vugV36ZA0jj067EbqG4MV0ujC7guPRwj40=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pRZ1PMD2GGqGUbJUjzJNuzqihmwApAA1/fVHpDe4YmxpTuXtYjnXs7Zd9gvzbB5wL hxZ9ShW4pQoY1njPmlCSw5Qq8UUI0FIOf1TRlkwCe/e3hF8m2j7HfeSPfuqs9r9Xy9 /qCQKUx52OF3AER6KLfY6ULVkrnOGD3kC1cR5Nw0=
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 SM4KZyGyWAGO; Mon, 22 Apr 2019 18:19:12 +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; Mon, 22 Apr 2019 18:19:11 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7E2F539A627; Mon, 22 Apr 2019 12:19:10 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7E2F539A627
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 732C640D358A; Mon, 22 Apr 2019 12:19:10 -0400 (EDT)
Date: Mon, 22 Apr 2019 12:19:10 -0400
From: Paul Wouters <paul@nohats.ca>
To: Linda Dunbar <linda.dunbar@huawei.com>
cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, "ipsec@ietf.org WG" <ipsec@ietf.org>
In-Reply-To: <DBBD75C3-9FB3-473F-A627-062DB3F5C32D@um.es>
Message-ID: <alpine.LRH.2.21.1904210811200.1903@bofh.nohats.ca>
References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <DBBD75C3-9FB3-473F-A627-062DB3F5C32D@um.es>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-8859-15"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/KfoXrFwOTQdE6K0tR00lRpFWWRU>
Subject: Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2019 16:19:22 -0000
Linda Dunbar <linda.dunbar@huawei.com> wrote: > This email starts a four weeks Working Group Last Call > on draft-ietf-i2nsf-sdn-ipsec-flow-protection-04. > This poll runs until May 15, 2019. > If you are listed as an Author or a Contributor of this Document please respond to this email and > indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress > without answers from all the Authors and Contributors. I'm not sure if I should consider mylsef a Contributors, but regardless I have no IPR on any of this. The Security Controller is in charge of managing and applying SPD and PAD entries (deriving and delivering IKE Credentials such as a pre-shared key, certificates, etc.), and applying other IKE configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF for the IKE negotiation. This text is a little confusing as IKE manages and applies the SPD/PAD entries, but the SC is not the one running IKE. Proposed new text: The Security Controller is in charge of managing and applying IPsec connection information (determing which nodes need to start an IKE/IPsec session, deriving and delivering IKE Credentials such as a pre-shared key, certificates, etc.), and applying other IKE configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF for the IKE negotiation. IKE case MAY be easier to deploy than IKE-less case because current gateways typically have an IKEv2/IPsec implementation. Why is that MAY in capitals? Also, based on the paragraph it seems you really are saying the IKE case is easier to deploy, unless your nodes lack the resources to run IKEv2. The main reason is that the Security Controller is not able to observe any session keys generated for the IPsec SAs because IKEv2 is in charge of negotiating the IPsec SAs. I think you mean "because the nodes, not the Security Controller, is generating the session keys". I would not use the word IKEv2, because it is unclear if that IKEv2 would be running on the SG or the node. For IKE case, the rekeying process is carried out by IKEv2, following the information defined in the SPD and SAD. That is not the whole story though? Isn't is the Security Controller that decides when to terminate a connection? I guess it is implied here that we are talking about connections that are instructed by the SG to stay up long enough to need rekeying? Section 5.3.1 talks about a bundle of two inbound SA's. That is a little confusing as traditionally we talk about the bundle being an inbound and outbound SA from the perspective of one of the endpoints. I understand you are doing this so you can talk about installing inbound on both ends first. Perhaps talk initially about the inbound and outbound bundle, then state you are handing out what is the inbound sa from the point of view of each endpoint first ? It is worth noting that if the IPsec implementation can itself detect traffic on the new IPsec SA, and it can delete the old IPsec SA itself without instruction from the Security Controller, then this step 3 is not required. Technically, they can never know this because IKEv2 allows installing multiple IPsec SA's with the exact same policies. We are for example doing this for performance increases by creating multiple IPsec SA's, (identical policies, different keys) to get one IPsec SA bound per CPU on the endpoint. I would recommend to leave this up only to the Security Controller, eg: The IPsec implementation cannot detect whether a new identical IPsec SA is an additional (identical) IPsec SA or a replacement IPsec SA. It should only delete the (seemingly) old IPsec SA when the Security Controller instructs the node to do so. It can also instruct the affected NSF to send IKEv2 INITIAL_CONTACT. I think this is something the IKEv2 implementation would determine on its own. I would remove the sentence or change it to say the node can determine it needs to send INITIAL_CONTACT. Also, this removes the need for the SC to have to relay this option to the IKEv2 NSF. In IKE-less case, if the Security Controller detects that a NSF has lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs of the non-failed nodes established with the failed node (step 1). This prevents the non-failed nodes from leaking plaintext. Wouldn't doing that before installing a new IPsec SA not actually _cause_ leaking plaintext? Unless the non-failed nodes, upon receiving the delete would put in an SPD policy that would catch packets and trigger an acquire. I see the use of ah-algorithms. I thought we were going to remove all mention of AH and perhaps tell people to use ESP NULL encryption? +--rw security-protocol? ic:ipsec-protocol What does this stand for? There is no "IPsec protocol" in the sense that we do not have an IANA protocol entry for "IPsec" (only for ESP) SHOULD NEVER -> MUST NOT If PSK authentication is used in IKEv2, the Security Controller SHOULD remove the PSK immediately after generating and distributing it Why is that SHOULD not a MUST? Can you give an example of an exception? If raw public keys are used, the Security Controller SHOULD remove the associated private key immediately after generating and distributing them to the NSFs. Again, why is this SHOULD not a MUST? What is the exception? In the IKE-less case, the controller sends the IPsec SA information to the SAD that includes the keys for integrity and encryption (when ESP is used). That key material are symmetric keys to protect data traffic. Change to: In the IKE-less case, the controller sends the IPsec SA information to the SAD that includes the private session keys required for integrity and encryption. The general recommendation is that the Security Controller SHOULD NEVER stores the keys Again, use RFC 2119 terms, so change SHOULD NEVER to MUST NOT. (or SHOULD NOT, but then you again need to say what the exception would be) Moreover, the NSFs MUST NOT allow the reading of these values once they have been applied by the Security Controller (i.e. write only operations). These are not really "applied by the Security Controller". Perhaps you meant "obtained" instead of "applied" ? In other words, it may have access to the key material used in the distributed IPsec SAs and observe the traffic between peers. change to: In other words, the attack might be able to observe the IPsec traffic and decrypt, or even modify and re-encrypt the traffic between peers. In any case, some escenarios with special secure environments (e.g. physically isolated data centers) make this type of attack difficult. I would not make this claim and just delete this setence (and the "Morever," part of the next sentence. enum ah { description "AH Protocol"; } another occurance of AH ? typedef ipsec-upper-layer-proto { type enumeration { enum TCP { description "TCP traffic"; } enum UDP { description "UDP traffic"; } enum SCTP { description "SCTP traffic";} enum DCCP { description "DCCP traffic";} enum ICMP { description "ICMP traffic";} enum IPv6-ICMP { description "IPv6-ICMP traffic";} enum GRE {description "GRE traffic";} } description "Next layer proto on top of IP"; } I don't understand ipsec-upper-layer-proto? If this is encapsulation protocol, then there is only TCP and UDP. If this is the protocol of the encrypted data, then there are a lot more protocols. The document also nowhere explains the term "upper layer protocol" I think you mean what I would call the "inner protocol" so that it is every number from the IANA protocol registry. typedef pfs-group { type enumeration { enum NONE {description "NONE";} enum 768-bit-MODP {description "768-bit MODP Group";} enum 1024-bit-MODP {description "1024-bit MODP Group";} enum 1536-bit-MODP {description "1536-bit MODP Group";} enum 2048-bit-MODP {description "2048-bit MODP Group";} enum 3072-bit-MODP {description "3072-bit MODP Group";} enum 4096-bit-MODP {description "4096-bit MODP Group";} enum 6144-bit-MODP {description "6144-bit MODP Group";} enum 8192-bit-MODP {description "8192-bit MODP Group";} } description "PFS group for IPsec rekey"; } This is the only entry still enumerating (partially!) an IANA registry. leaf-list ike-sa-authalg { type ic:integrity-algorithm-t; description "Auth algorigthm for IKE SA";} Typo in algorigthm leaf-list ike-sa-encalg { type ic:encryption-algorithm-t; description "Auth algorigthm for IKE SAs";} Same typo, but it should also not be "Auth" but "Encryption or AEAD algorithm". description "Configure the IKEv2 software"; Maybe call it "Configuration of the IKEv2 implementation" ? (more of these "Configure" vs "Configuration" terms follow) leaf pad-entry-id { type uint64; description "SAD index. ";} did you mean "PAD index" ? Whether to use IKEv2 fragmentation as Whether or not to enable IKEv2 fragmentation (enable because the other end can not have support, it is just a suggestion, not a demand) container ike-sa-state { container uptime { description "IKE service uptime"; Did you mean "IKE connection uptime" ? To me ike-sa-state means an IKE state, not IKE service state? leaf nat-any {type boolean; description "YES, if both local and remote endpoints are behind a NAT";} I could call this nat-both instead of nat-any, nat-any suggests it could be "0 or more" Seconds before IKE SA gets rekeyed -> Seconds before IKE SA must be rekeyed (same for next auth item) description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301"; Use "Configuration of IPsec Security Association (SA). Section 4.4.2.1 in RFC 4301" To ensure it is clear this is not about an IKE SA. Same on the next line for "for a particular SA" leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should prevent transmission of additional packets on the SA, or whether rollover is permitted."; } What is the source of this? I thought sequence numbers were never allowed to overflow? leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } Why cap at 1024? That could be too low for 100gbps connections. leaf spd-entry-id {type uint64; description "This value links the SA with the SPD entry";} Again, use "IPsec SA" leaf security-protocol { type ic:ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; } If we killed AH, remove from here. leaf mode { type ic:ipsec-mode; description "SA Mode"; } "IPsec SA". Should it say "tunnel/transport" ? leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";} That should be: "inside the replay window" typedef sadb-msg-satype { type enumeration { enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; } enum sadb_satype_ah { description "SADB_SATYPE_AH"; } enum sadb_satype_esp { description "SADB_SATYPE_ESP"; } enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; } enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; } enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; } enum sadb_satype_mip { description "SADB_SATYPE_MIP"; } enum sadb_satype_max { description "SADB_SATYPE_MAX"; } } description "PF_KEY Security Association types"; } Is this enumerating an IANA registry? I think it might be from xfrm.h but I don't know any of those except the first three. description "Configure integrity for IPSec Authentication Header (AH)"; "Configuration of integrity algorithm for IPSec Authentication Header (AH) description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)"; "Configuration of encryption or AEAD algorithm for IPSec Authentication Header (ESP)" description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)"; See above, but also I would not use "authentication" here, but "integrity", as it is really the same thing as the AH value except for ESP. So either call both authentication or call both integrity - i strongly prefer integrity to avoid confusing with IKE authentication. /* With AEAD algorithms, the integrity node is not used */ So it can either be fully ommited, or it can contain the integrity value for None. Perhaps relfect that in the comment? There are some implementations that do not handle both, so there might be a need to configure "None" as the integrity algorithm for an AEAD. I now spotted the entry for AEAD, so now I am a little confused. If the above encryption is not used for that, and we have a special entry for aead, than the above comment is wrong, because then with AEAD algorithms, encryption and integrity is not used but combined-enc-intr. I would be more inclined to keep this more in line with IKEv2, where AEAD's are just encryption algorithms. So remove the combined-enc-intr leaf. notification sadb_expire { description "A IPsec SA expiration (soft or hard)"; uses base-grouping; leaf spi { type ic:ipsec-spi; description "Security Parameter Index";} leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; } leaf encryption-algorithm { type ic:encryption-algorithm-t; description "encryption algorithm of the expired SA"; } leaf authentication-algorithm { type ic:integrity-algorithm-t; description "authentication algorithm of the expired SA"; } So if you keep AEAD as a seperate entry, you also need a leaf here for it. I see IPcomp is not used anywhere. I agree with that but I'm not sure if there is WG conensus for that. Some IoT people think compression is super important. nits: These appear a few times: "in IKE case" -> in the IKE case" "in IKE-less case" -> in the IKE-less case" making IKEv2 configuration -> making the IKEv2 configuration Note that the usage of TRANSPORT mode when NAT is required is forbidden in this specification. We normally don't use words like "forbidden". We usually write that like: Transport mode MUST NOT be used when a NAT is present between two NSF's. and not the IKE-less. -> and not the IKE-less case. In order to support IKE case and IKE-less case -> In order to support the IKE and IKE-less cases I see the use of "IKE case" and the use of "IKE-case". Pick one and stick to that? minimu -> minimum it may access to these values. -> it might have access to the key material" It is acting as initiator in this connection -> It is acting as initiator for this connection IKEless -> IKE-less "A SPD entry has expired" -> "An SPD entry has expired" "A IPsec SA is required " -> "An IPsec SA is required" "A IPsec SA expiration (soft or hard)" -> "An IPsec SA expiration (soft or hard)" "Security Parameter Index" -> "Security Parameter Index (SPI)" Paul
- [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sd… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Fernando Pereñíguez García
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Paul Wouters
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- [I2nsf] 答复: WGLC and IPR poll for draft-ietf-i2ns… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Tero Kivinen
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Tero Kivinen
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez