[I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 05 November 2020 04:53 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: i2nsf@ietf.org
Delivered-To: i2nsf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D46283A16A8; Wed, 4 Nov 2020 20:53:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, i2nsf-chairs@ietf.org, i2nsf@ietf.org, Yoav Nir <ynir.ietf@gmail.com>, ynir.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160455203643.18974.10035617605936468048@ietfa.amsl.com>
Date: Wed, 04 Nov 2020 20:53:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/LvaKdInImCpgn3e2LRIMayCMEuM>
Subject: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS and COMMENT)
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 05 Nov 2020 04:53:57 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Let's discuss whether it's appropriate to include vendor-specific functionality (e.g., linux NETKEY/XFRM marking) in a standards-track protocol/model. The ASN.1 GeneralName type is an abstract type; in order to represent it in a string we must have some discussion of how it is encoded. (A similar concern might apply to the other ASN.1 types used, such as DistinguishedName, though the latter does have a fairly well-established string presentation form, so the concern is of lesser magnitude there. That said, RFC 5280 is not a suitable reference for the DistinguishedName string presentation form.) In a similar vein, the 'id-key' identity representation is listed as type 'string' but the description lists it as an "opaque octet string". YANG strings are not directly suitable for holding binary content (which is what an opaque octet string is), so either a scheme for encoding arbitrary binary content as a string is needed, the YANG 'binary' type should be used, or this node needs to be documented as only allowing valid Unicode (IIUC, in UTF-8 encoding, though https://tools.ietf.org/html/rfc6020#section-9.4 is not as clear about this as I would like). The two 'anti-replay-window' leafs are (1) using different-width types, and (2) do not have enough of a description to indicate what content they hold, especially whe combined with a default value of 32. (I mention both locations in the COMMENT.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract We should not use unexpanded acronyms like SPD, SAD, and PAD in the abstract unless there are very well-known. Section 1 [RFC6071]. In these cases, hosts, gateways or both may act as NSFs. Consideration for the host-to-gateway scenario is out of scope. Is there anything to say about what gaps would need to be filled in order to address the host-to-gateway case (vs how much of the mechanisms defined herein could be reused)? the I2NSF Controller and the NSF. Using YANG data modelling language version 1.1 [RFC7950] and based on YANG models defined in [netconf-vpn], [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296], this document defines the required interfaces with a YANG model for configuration and state data for IKE, PAD, SPD and SAD RFCs 4301 and 7296 do not define YANG models. Is the intent to say that this is based on YANG models defined in netconf-vpn and I-D.tran-ipsecme-yang, and the data structures defined in RFC 4301 and RFC 7296? o To define the interfaces required to manage and monitor the IPsec SAs in the NSF from a I2NSF Controller. YANG data models are defined for configuration and state data for IPsec and IKEv2 management through the I2NSF NSF-Facing interface. Thus, this document does not define any new protocol. It might perhaps be worth saying that the YANG models can be used via existing protocols such as NETCONF and RESTCONF. Section 3 The following term is defined in [RFC6437]: o Flow/traffic flow. That does not seem to be used as a single term in RFC 6473; perhaps it's best to say that they are two terms that are related or have identical definition/usage. Section 4.1 flexible management of IPsec SAs in flow-based NSFs. In order to support this capability in the IKE case, a YANG data model for IKEv2, SPD and PAD configuration data, and for IKEv2 state data MUST be defined for the I2NSF NSF-Facing Interface. I think this is probably better as a descriptive "needs to" than a BCP 14 "MUST". Section 4.2 We should perhaps say something before the figure about what the I2NSF User does, in order to justify their inclusion in the figure (or otherwise introduce the figure before it appears). Section 5.1 IPsec SAs management. With the YANG data models defined in this document the I2NSF Controller can configure and conduct the rekey Does the "and conduct" apply only to the IKE-less case, or the IKE-ful one as well? If only the IKE-less case we might consider some additional notation such as "and, as needed, conduct". Section 5.2 In the IKE case, the I2NSF Controller will configure the affected NSF with the new IKEv2, SPD and PAD information. It has also to send new parameters (e.g. a new fresh PSK for authentication) to the NSFs which have IKEv2 SAs and IPsec SAs with the affected NSF. Finally, It does not seem intuitively obvious to me that the controller *always* has to send new parameters to the other NSFs (that have SAs with the affected NSF). E.g., for IKE-ful SAs that use certificate authentication, what would need to change on the other NSFs? Alternatively, IKEv2 configuration MAY be made permanent between NSFs reboots without compromising security by means of the startup Similarly, this MAY seems to require that the previous paragraph has some hedging langauge that the procedures it describes are only one possible option (with this paragraph being the other option). Section 5.3 some of the peers or both are located behind a NAT. If there is a NAT network configured between two peers, it is required to activate I am not familiar with "NAT network" as a term; is there a reference for it? the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948], Why is TLS needed? I understand that RFC 8229 talks about how it can be done, but why is that necessary here? configured between two hosts, and apply the required policies to both NSFs besides activating the usage of UDP or TCP/TLS encapsulation of (TLS again) Section 6 In order to support the IKE and IKE-less cases we have modeled the different parameters and values that must be configured to manage The use of the first person is uncommon in RFCs; phasing like "models are provided for the different parameters and values [...]" is more common. Section 6.1 We have a 'spd' tree in the IKE-ful model, so it's a bit surprising that we don't match the treatment of the IKE-less model and say that the SPD model has mainly been extracted from [parts of] RFC 4301. (side note?) The tree diagram apparently doesn't have a good way of showing the "when" relationship between (e.g.) auth-method and the sibling nodes (eap-method, pre-shared, etc.), which confused me briefly. Using string names instead of YANG references for correlating the PAD entries is rather surprising to me. to be secured (local/remote subnet and ports, etc.) and how must be protected (AH/ESP, tunnel/transport, cryptographic algorithms, etc.); I think that AH support was present in a previous version of the document but has since been removed, so we should not mention AH here. Section 6.2 o Each IPsec policy (spd-entry) contains one traffic selector, instead of a list of them. The reason is that we have observed actual kernel implementations only admit a single traffic selector per IPsec policy. It's not entirely clear that we need to cripple the overall model just because some implementations would not support the full functionality. My understanding is that having many traffic selectors for a single policy (or SA, which has similar text later in this section) can be quite useful in some cases. o Combined algorithms have been removed because encryption algorithms MAY include authenticated encryption with associated data (AEAD). A reference here would be helpful (IIUC, the "MAY" here is in effect quoting the external document, and not a new requirement). (Likewise for the corresponding SAD-model item.) The notifications model has been defined using as reference the PF_KEYv2 standard in [RFC2367]. RFC 2367 is only an Informational document, so calling it a "standard" (as opposed to a "protocol" or "specification" may not be the best choice. | | +--rw protocol-parameters? ipsec-protocol-parameters Isn't this type nsfikec:ipsec-protocol-parameters? absence of an IKE software in the NSF: traffic direction to apply the IPsec policy, and a value to link an IPsec policy with its associated IPsec SAs. [...] Maybe "a 'requid' value to link [...]" since it is otherwise a little hard to find by searching? Section 8 On the one hand, it is important to note that there MUST exist a security association between the I2NSF Controller and the NSFs to protect the critical information (cryptographic keys, configuration parameter, etc.) exchanged between these entities. We should probably state explicitly that the nature of and means to create that SA is out of scope for this specification (i.e., it's part of device provisioning or onboarding). this information. Although we can assume this attack is not likely to happen due to the assumed security measurements to protect the I2NSF Controller, it still deserves some analysis in the hypothetical case that the attack occurs. The impact is different depending on I don't think this sentence actually adds any value; whether or not the attack is likely, the potential consequences are significant enough that we have to document it. Section 8.1 Alternatively, the NSF could generate the private key and export only the public key to the I2NSF Controller. (Again, the mechanisms by which to do this are outside the scope of this specification. We do have some text like this for the following bullet regarding certificates, which could easily be repurposed for use here.) Section 10.2 Many of these entries don't really contain sufficient information to unambiguously locate the intended reference document. E.g., [libreswan], [netconf-vpn], [ONF-SDN-Architecture], [SDNSecServ], [SDNSecurity], [strongswan]. For many of them it seems like it would be quite straightforward to include URLs and/or publisher information, e.g., https://ieeexplore.ieee.org/document/6702553 and https://datatracker.ietf.org/meeting/87/materials/slides-87-sdnrg-2 seem fairly likely to remain stable references. We use RFC 3948 as reference for the UDP encapsulation facility, so it probably should be a normative reference; likewise for RFC 8229 and TCP(/TLS) encapsulation. Appendix A typedef ipsec-protocol-parameters { type enumeration { enum esp { description "IPsec ESP protocol."; } } description "Only the Encapsulation Security Protocol (ESP) is supported but it could be extended in the future."; I assume that the usual caveats about extension via identity vs enum are well-understood by the WG (i.e., a full revision of the module would be needed to enable use of a new value; augmentation would not suffice). (This potentially applies to many of the enumerated types in this document, but I will only note it this one time.) description "IPsec traffic direction is defined in two directions: inbound and outbound. From a NSF perspective inbound means the traffic that enters the NSF and outbound is the traffic that is sent from the NSF."; This is perhaps not the greastest wording, since in the gateway case any given traffic both enters and is sent from the NSF. I think it is probably tolerable, since we refer specifically to the IPsec traffic, but might be worth further thought. description "IPsec protection can be applied to specific IP traffic and layer 4 traffic (TCP, UDP, SCTP, etc.) or ANY protocol in the IP packet payload. We specify the IP protocol number with an uint8 or ANY defining an enumerate with value 256 to indicate the protocol number. NOTE: In case of IPv6, the protocol in the IP packet payload is specified in the Next Header field of the IPv6 packet."; [There are perhaps some complications around this description when extension headers are in use.] leaf bytes { type uint32; default 0; description "If the IPsec SA processes the number of bytes expressed in this leaf, the IPsec SA expires and should be rekeyed. The value 0 implies infinite."; 32 bits for a byte lifetime is perhaps overly restrictive; some encryption schemes do not have cryptographic need to rekey that frequently, so a 64-bit counter would be more appropriate for them. is a waste of resources. If the IPsec SA is idle during this number of seconds the IPsec SA should be removed. The value 0 implies infinite."; } reference "Section 4.4.2.1 in RFC 4301."; I don't see any mention of "idle" in RFC 4301. leaf bypass-dscp { type boolean; default true; description "If DSCP (Differentiated Services Code Point) values in the inner header have to be used to select one IPsec SA among several that match the traffic selectors for an outbound packet"; This doesn't really give me a clear picture of what action to take when it has value 'true' (vs 'false'). list local-ports { key "start end"; uses port-range; description "List of local ports. When the inner protocol is ICMP this 16 bit value represents code and type. If this list is not defined it is assumed that start and end are 0 by default (any port)."; Shouldn't these extra semantics be attached to the port-range grouping itself? Also, the repurposing of start/end for ICMP code/type is quite unconventional. leaf anti-replay-window { type uint64; default 32; description "A 64-bit counter used to determine whether an inbound ESP packet is a replay."; reference "Section 4.4.2.1 in RFC 4301."; Is this the counter or the bit-map or the size of the bit-map? I don't think a uint64 combined with default 32 makes sense. leaf seq-overflow { type boolean; default false; I think we may want to give a stronger indication that setting this to 'true' is strongly discouraged. leaf id { type uint8; description "The index of list with the different encryption algorithms and its key-length (if required)."; I'm not sure what this id is indexing into and how it would indicate key length. Is the idea that this is a sequential index for the very 'list encryption' that it is contained in? If so, I think we would need to write more specifics about its semantics and how it is assigned. Appendix B "This module contains IPsec IKE case model for the SDN-based IPsec flow protection service. An NSF will implement this module. Why do we have the last sentence? IIUC we do not mandate implementation of the IKE case, since the IKE-less case is seen as making this more accessible for lower-resourced NSFs. enum on-demand { description "IKE/IPsec configuration is loaded into IKE implementation. The IPsec policies are transferred to the NSF's kernel but the IPsec SAs are not established immediately. The IKE implementation will negotiate the IPsec SAs when the NSF's kernel requests it (i.e. through an ACQUIRE notification)."; I'm not sure I understand the intended semantics of the ACQUIRE notification, here -- the sadb-acquire notification is part of this YANG module, which would typically imply that it is send from the NSF to the I2NSF Controller. I'm not sure where the NSF's kernel is, in that path. (We also haven't really talked about "NSF kernel"s previously, though we did have significant discussion of kernel IPsec/IKE implementations.) typedef pfs-group{ "pfs-group" (and the "pfs-groups" nodes of this type) calls to mind "perfect forward secrecy", but the guidance from SAAG is moving towards dropping the "perfect" part since it is a bit misleading and its meaning is not terribly well-defined. list pad-entry { [...] leaf name { [...] choice identity { I guess I would have expected some discussion somewhere (possibly up in §6.1) about why there is both a 'name' and an 'identity'. (I might surmise that it is to allow differently-named-and-configured SAs to the same remotem peer, but that is just supposition if there's no text in the document about it.) leaf dnx509 { type string; I assume from the 'string' type and the example that we use the presentation form and not (e.g.) the DER encoded form. This is probably worth stating explicitly. leaf eap-type { type uint8; mandatory true; description "EAP method type. This information provides the particular EAP method to be used. Depending on the EAP method, pre-shared keys or certificates may be used."; A reference to where the actual method type values are obtained (e.g., https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4) seems in order. I note that there is a range allocatable via "Specification Required" in that registry that is not representable in a uint8. container pre-shared { when "../auth-method[.='pre-shared' or .='eap']"; This seems a little unfortunate, as I don't think that it is appropriate to require ("mandatory true") the pre-shared secret leaf to be present, universally, for all EAP methods.o container digital-signature { when "../auth-method[.='digital-signature' or .='eap']"; Similarly here, for the mandatory 'public key' choice -- if I am reading this correctly the YANG would require us to have both pre-shared *and* public-key values present for the 'eap' auth-method. leaf ds-algorithm { type uint8; default 1; My understanding is that algorithm 14 (the generic "digital signature") is currently preferred as the default algorithm, since it is not tied to a particular public key type. See https://tools.ietf.org/html/rfc8247#section-3.1 for discussion of why it is expected to be the way of the future. signature algorithm. For example, an RSA key is represented as RSAPublicKey as defined in RFC 8017, and an Elliptic Curve Cryptography (ECC) key is represented using the 'publicKey' described in RFC 5915."; This is perhaps a bit under-specified without a clear procedure for going from a digital signature algorithm codepoint to the specification of the public key encoding. That said, I'm not sure that there is a very good thing to say here, and even the RFC 7427 generic "Digital Signature" type is effectively still deferring to the ASN.1 AlgorithmIdentifier. (Similarly for the 'private-key', of course.) leaf cert-data { type binary; description "X.509 certificate data - PEM4. If raw-public-key is defined this leaf is empty."; If the leaf it of type binary we don't need the (ASCII) PEM encoding. (Also, why the '4' in "PEM4"?) leaf crl-uri { type inet:uri; description "X.509 CRL certificate URI. If it is not defined the default value is empty."; An RFC 5280 reference would probably be appropriate here as well. leaf oscp-uri { type inet:uri; description "OCSP URI. If it is not defined the default value is empty."; and maybe 2560 or 5280 here. leaf-list authalg { type nsfikec:integrity-algorithm-type; default 12; ordered-by user; description "Authentication algorithm for establishing Using "authentication algorithm" in the description here (and "authalg" as the node name) seems needlessly confusing, since these are the IKEv2 integrity algorithms, and there is a separate thing that is the IKE authentication methods. list encalg { key id; min-elements 1; ordered-by user; leaf id { type uint8; description "The index of the list with the different encryption algorithms and its key-length (if required). E.g. AES-CBC, 128 bits"; As was the case for esp-algorithms/encryption, I'm not sure what this id is indexing into and how it would indicate key length. Is the idea that this is a sequential index for the very 'list encryption' that it is contained in? If so, I think we would need to write more specifics about its semantics and how it is assigned. leaf half-open-ike-sa-timer { type uint32; default 0; description "Set the half-open IKE SA timeout duration."; What are the units? Does 0 really mean 0 (vs infinity)? container child-sa-info { leaf-list pfs-groups { ["pfs" again, just noting the location; no new comment other than the one above] leaf current-rekey-time { type uint64; units "seconds"; description "Seconds before IKE SA MUST be rekeyed."; } leaf current-reauth-time { type uint64; units "seconds"; description "Seconds before IKE SA MUST be re-authenticated."; I don't think either of these strictly speaking need to be RFC 2119 "MUST"s. container number-ike-sas { In general it seems like these counters could be gauge64's instead of uint64's. Appendix C container ipsec-sa-config { [...] leaf spi { type uint32 { range "0..max"; } I would have expected a clear indication of whether this value is for sending or receiving. leaf seq-number-counter { Why is this leaf writable? leaf anti-replay-window { type uint32; default 32; description "A 32-bit counter and a bit-map (or equivalent) used to determine whether an inbound ESP packet is a replay. If set to 0 no anti-replay First, in the common module the anti-replay-window was a uint64, but here it's uint32. Second, my confusion/comment from the common module seem to also apply here. leaf replay-window { type uint64; description "Current state of the replay window."; Probably a little bit more description and/or reference is in order here. leaf packet-dropped { type uint64; IIUC this could be a counter64. leaf failed { type uint32; description "Number of packets detected out of the replay window."; How is this different from 'packet-dropped' (and why does it only need to be a 32-bit counter)? Also, would a 'counter32' (or 'counter64') type be appropriate? notification sadb-acquire { if-feature ikeless-notification; description "An IPsec SA is required. The traffic-selector container contains information about the IP packet that triggers the acquire notification."; If I understand correctly, the scenario here is that an inbound packet arrives at (or is generated by) the NSF and it is determined that the packet needs IPsec protection to proceed. Some guidance on whether we should use exact-address match to determine the source and destination prefixes or some heuristic to select a less-specific prefix seems like it would be in order. (Or is this all supposed to be specified in the corresponding SPD entry?) container lifetime-current { description "IPsec SA current lifetime. If soft-lifetime-expired is true this container is set with the lifetime information about current soft lifetime."; I'm not 100% sure I understand what goes in this field -- intuitively, though, it seems like what would be most useful to the I2NSF Controller would be the time before the *hard* lifetime expires (since we already know that the soft lifetime has expired by virtue of this being a sadb-expire notification with soft-lifetime-expired set to true). notification sadb-seq-overflow { if-feature ikeless-notification; description "Sequence overflow notification."; leaf ipsec-sa-name { type string; mandatory true; description "It contains the SAD entry name (unique) of the IPsec SA that is about to have sequence number overflow and rollover is not permitted. It is assumed the I2NSF Controller will have a copy of the IPsec SA information (except the cryptographic material and state data) indexed by this name (unique identifier) so the it can know all the information (crypto algorithms, etc.) about the IPsec SA that has expired in order to perform a rekey of the IPsec SA."; } There seems to be internal disagreement here ("about to have ... overflow" vs "that has expired") -- it seems more useful for this to be the "about to" behavior, but in that case we should give some guidance about how to measure "about to". Appendix D This example shows a XML configuration file sent by the I2NSF Controller to establish a IPsec Security Association between two NSFs (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP, authentication based on X.509 certificates and applying the IKE case. Maybe note that some (base64) values have been simplified and/or truncated for brevity? ("base64encodedvalue==" is not a valid base64 encoding of a DER-encoded X.509 certificate, for example) <!--AUTH_HMAC_SHA1_160--> <authalg>7</authalg> Perhaps a non-SHA1 example would age better (even though HMAC-SHA1 is not known to be weak at this point). <local-ports> <start>0</start> <end>0</end> </local-ports> <remote-ports> <start>0</start> <end>0</end> </remote-ports> These are the default values and could be omitted, if I understand correctly. Appendix E I would prefer if the examples did not show seq-overflow as true. <inner-protocol>any</inner-protocol> Is this encoded as "any" as shown, or as 256? Appendix G.1.2 * The I2NSF Controller chooses two random values as SPIs: for example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers MUST NOT be in conflict with any IPsec SA in NSF A or NSF B. Is this restriction for the respective SPI<X>/NSF<X> pairs, or for the full matrix of combinations? (Similarly in G.2) Appendix G.2 If step 1 is successful but some of the operations in step 2 fails (e.g. the NSF A reports an error when the I2NSF Controller is trying to install the new outbound IPsec SA), the I2NSF Controller MUST perform a rollback operation by deleting any new outbound SA that had been successfully installed during step 2 and by deleting the inbound SAs created in step 1. I think it's important that the two rollbacks are done in the order listed here. NITS Section 1 resources through software. The SDN paradigm relocates the control of network resources to a centralized entity, namely SDN Controller. "the SDN Controller". For example, Software-Defined WANs (SD-WANs). [...] incomplete sentence (no verb). can be established using IPsec. The management of IPsec SAs in data centers using a centralized entity is a scenario where the current specification maybe applicable. s/maybe/may be/ I2NSF NSF-Facing interface. In this document we define a service allowing the I2NSF Controller to carry out the key management procedures. More specifically, we define YANG data models for I2NSF I'm not sure that "service" is the best word, here. NSF-Facing interface that allow the I2NSF Controller to configure and monitor IPsec-enabled flow-based NSFs. missing article ("the" or "a") before "I2NSF NSF-Facing interface". (Also, it's weird that "Facing" is capitalized but "interface" is not.) IPsec architecture [RFC4301] defines clear separation between the more articles: "The IPsec architecture", "a clear separation" which allows to centralize the key management procedures in the I2NSF s/to centralize/centralizing/ charge of provisioning the NSF with the required information in the SPD, PAD (e.g. IKE credential) and IKE protocol itself (e.g. parameters for the IKE_SA_INIT negotiation). comma after "e.g." (twice) "credentials" plural There's amismatch between "in the [databases] and "in IKE protocol itself" -- it should more properly be "for the IKE protocol itself", which makes the list non-parallel, so it would be "in the SPD and PAD (...), and for the IKE protocol itself". required parameters to create valid entries in the SPD and the SAD into the NSF. Therefore, the NSF will have only support for "into" is not right; maybe "in" or "of". s/have only/only have/ o To describe the architecture for the I2NSF-based IPsec management, s/the I2NSF-based/I2NSF-based/ Section 4 As mentioned in Section 1, two cases are considered, depending on whether the NSF implements IKEv2 or not: IKE case and IKE-less case. more articles: "the" for both cases parameters (e.g. cryptographic algorithms for establishing an IKEv2 comma after "e.g." information about the end points information (through the I2NSF redundant "information"s Section 4.2 o Cryptographic algorithm/s selection. Just "algorithm" works fine for both the singular and plural case. Section 5 IKEv2/IPsec implementation, hosts can easily install it. As downside, the NSF needs more resources to hold IKEv2 such as memory "As a downside" "to use IKEv2" Alternatively, IKE-less case benefits the deployment in resource- "the IKE-less case" centralized controller (like the I2NSF Controller) is aware about s/about/of/ provided and discussed (e.g. hierarchical controllers; having multiple replicated controllers, dedicated high-speed management networks, etc). In the context of I2SNF-based IPsec management, one I think s/;/,/ to be consistent about the list separator within a single list. waiting for notifications (e.g. a notification sadb-acquire when a comma after "e.g." Section 5.1 the old one (if a IPsec SA lifetime has not been defined). This rekeying process starts when the I2NSF Controller receives a sadb- expire notification or it decides so, based on lifetime state data s/or it decides so/or on the I2NSF Controller's initiative/ Section 5.2 with the new IKEv2, SPD and PAD information. It has also to send new s/has also/also has/ Section 5.3 some of the peers or both are located behind a NAT. If there is a NAT network configured between two peers, it is required to activate the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948], The "it is required" could be misread to have "it" mean "the NAT network"; rewording the second clause to be "UDP or TCP/TLS encapsulation for ESP packets ([RFC3948]) is required" would help with that. [RFC8229]). Note that the usage of IPsec transport mode when NAT is required MUST NOT be used in this specification. "usage" and "used" seem redundant. Section 5.4 NSF registration refers to the process of facilitating the I2NSF Controller information about a valid NSF such as certificate, IP s/facilitating/providing/ or similar address, etc. This information is incorporated in a list of NSFs under its control full stop at end of sentence. capabilities of this NSF, such as what is the cryptographic suite supported, authentication method, the support of the IKE case and/or s/is/are/, s/suite/suites/ Section 6.1 configure the Peer Authentication Database with authentication information about local and remote peers. More precisely, it "authentication information about local peers" reads a bit oddly. authentication method and credentials that will use a particular peer. s/that will use a particular peer/that a particular peer will use/ Section 6.2 The data model consists of a unique "ipsec-ikeless" container which, in turn, is integrated by two additional containers: "spd" and "sad". "integrated by" is probably not the right term here; "composed of" might be better. The "spd" container consists of a list of entries that conform the s/conform/form/ (or similar), I think. IPsec SAs. The "sad" container is a list of entries that conform the (ditto) Security Association Database. In general, each entry allows to specify both configuration information (SPI, traffic selectors, s/to specify/specifying/ Section 8.3 to be used for the authentication (e.g. to impersonate a NSF), comma after "e.g." (occurs several times in this section). changing to a allow policy), and in general changing the IKE SA s/a/an/ example, encryption/key contains a ESP encryption key value and s/a ESP/an ESP/ encryption/iv contains a initialization vector value. s/a initialization/an initialization/ Similarly, integrity/key has ESP integrity key value. Those s/has/has an/ Appendix A "The encryption algorithm is specified with a 16-bit number extracted from IANA Registry. The acceptable missing article for "IANA Registry" (so probably "the", since only one registry is listed). (similarly for integrity-algorithm-type) "The integrity algorithm is specified with a 16-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; s/encryption/integrity/, right? enum none { description "NOT ESP encapsulation."; "Not" probably doesn't need to be capitalized. description "Types of ESP encapsulation when Network Address Translation (NAT) is present between two NSFs."; Perhaps s/is/may be/, as it doesn't seem like an intrinsic requirement for the use of encapsulation. description "When the lifetime of an IPsec SA expires an action needs to be performed over the IPsec SA that "over" doesn't seem like the right word; perhaps "for"? description "This group of nodes allows to define the type of encapsulation in case NAT traversal is required and port information."; s/and/and includes/ description "When a NSF stores an IPsec SA, it consumes system resources. In an idle NSF this Maybe s/In an idle NSF/For an idle SA/? enum clear { description "Disable the DF (Don't Fragment) bit from the outer header. This is the s/from/in/ container traffic-selector { description "Packets are selected for processing actions based on the IP and inner protocol header information, selectors, matched against entries in the SPD."; The grammar here doesn't make sense, to the extent that I can't really even guess the intended meaning. It makes the most sense if I just end the sentence after "inner protocol header information". Perhaps the remaining bit was intended to be a separate statement that "selectors are matched against" something? description "True if this IPsec SA is using extended sequence numbers. True 64 bit counter, False 32 bit."; How about (for the second sentence): "If true, the 64-bit extended sequence number counter is used; if false, the normal 32-bit sequence number counter is used"? "Configuration of ESP authentication based on the specified integrity algorithm. With AEAD algorithms, the integrity node is not used."; s/AEAD algorithms/AEAD encryption algorithms/ Appendix B description "IKE authentication protocol version specified in the Peer Authorization Database (PAD). It is defined as enumerate to allow new IKE versions in the s/enumerate/enumerated/ enum digital-signature { description "Select digital signature method."; s/method/as the authentication method/ to match the others. container ipsec-ike { description "IKE configuration for a NSF. It includes PAD parameters, IKE connections information and state s/connections/connection/ "Configuration of Peer Authorization Database (PAD). The PAD contains information about IKE s/Peer/the Peer/. peer (local and remote). Therefore, the Security s/peer/peers/ Controller also stores authentication information for this NSF and can include several entries for the local NSF not only remote peers. Storing local and remote comma before "not only". information makes possible to specify that this s/makes possible/makes it possible/ NSF with identity A will use some particular authentication with remote NSF with identity B and what are the authentication mechanisms allowed to B."; s/allowed/allowed for communication/ description "Specifies the identity as a single four (4) octet."; "four-octet value". (The current text says that it is a single byte with value 0x4, which is not a very useful identifier.) "Specifies the identity as a Fully-QualifiedDomain Name space in "Qualified Domain". case rfc822-address-string { (I'm still a little confused why email address identifiers are useful enough to be in the core spec, but I think I am behind on the email thread so maybe it is answered there.) description "Specifies the identity as a ASN.1 X.500 Distinguished s/a/an/ "ID_NULL identification used when IKE identification payload "The ID_NULL identification method is used when the IKE identification payload [...]". "This container allows the Security Controller to configure the authentication method (pre-shared key, eap, digitial-signature, null) that will use a particular peer and the "will be used with" credentials, which will depend on the "credentials to use" "If the I2NSF Controller knows that the NSF already owns a private key associated to this public key (the NSF generated the pair public key/private key out of band), it will only configure I think this is better with "e.g.," at the start of the parenthetical. "IKE peer connection information. This list contains the IKE connection for this peer with other peers. This will be translated in real time by IKE Security Associations established with these nodes."; Is "translated" the right word here? leaf autostartup { type autostartup-type; default add; description "By-default: Only add configuration without starting the security association."; This seems to be describing the default behavior, not the function of the leaf overall. leaf version { type auth-protocol-type; default ikev2; description "IKE version. Only version 2 is supported so far."; "so far" is perhaps a bit colloquail for RFC style. "Time in seconds between each IKE SA rekey.The value 0 means infinite."; Space at the sentence break. "If non-zero, perfect forward secrecy is required when requesting new IPsec SA. The non-zero value is the required group number. [...] How about: % If non-zero, forward secrecy is required when a new IPsec SA is being % created. The (non-zero) value indicates the group number to use for % the key exchange process used to achieve forward secrecy. "Soft IPsec SA lifetime soft. redundant "soft"s. description "True if this IPsec SA is using extended sequence numbers. True 64 bit counter, false 32 bit."; [same comment as previously] description "ESP encryption IV value. If this leaf is not defined the IV is not defined (e.g. encryption is NULL)"; } Maybe say how the IV length is determined? IPsec Encapsulation Security Payload (ESP). This container allows to configure integrity algorithm when no AEAD s/allows to configure/allows configuration of/ s/algorithm/algorithms/ the key is not defined (e.g. comma after "e.g.". "Packets detected out of the replay window and dropped because they are replay packets."; s/they are/they are assumed to be/ description "List of SAD entries that conforms the SAD."; s/conforms/forms/ again, I think.
- [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2… Benjamin Kaduk via Datatracker
- Re: [I2nsf] Benjamin Kaduk's Discuss on draft-iet… Rafa Marin-Lopez
- Re: [I2nsf] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [I2nsf] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [I2nsf] Benjamin Kaduk's Discuss on draft-iet… Rafa Marin-Lopez