Re: [I2nsf] Erik Kline's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS and COMMENT)
Rafa Marin-Lopez <rafa@um.es> Tue, 03 November 2020 12:06 UTC
Return-Path: <rafa@um.es>
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 C23423A08E7; Tue, 3 Nov 2020 04:06:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es
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 xFSZCfoZioOd; Tue, 3 Nov 2020 04:06:10 -0800 (PST)
Received: from mx02.puc.rediris.es (outbound6sev.lav.puc.rediris.es [130.206.19.181]) (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 D9A863A0954; Tue, 3 Nov 2020 04:05:41 -0800 (PST)
Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by mx02.puc.rediris.es with ESMTP id 0A3C5dC3016816-0A3C5dC4016816; Tue, 3 Nov 2020 13:05:39 +0100
Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 070842031A; Tue, 3 Nov 2020 13:05:39 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon41.um.es
Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CYdFbs4LBKdO; Tue, 3 Nov 2020 13:05:38 +0100 (CET)
Received: from [192.168.1.40] (73.red-2-138-85.dynamicip.rima-tde.net [2.138.85.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 02776201C3; Tue, 3 Nov 2020 13:05:33 +0100 (CET)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <D5914851-E384-40F1-8EC4-DA11DC6B78E3@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FFC23A41-3220-42A6-83A1-5C7418DB871E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 03 Nov 2020 13:05:32 +0100
In-Reply-To: <160430252793.9780.17181822196174022649@ietfa.amsl.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, The IESG <iesg@ietf.org>, i2nsf@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, Yoav Nir <ynir.ietf@gmail.com>, i2nsf-chairs@ietf.org
To: Erik Kline <ek.ietf@gmail.com>
References: <160430252793.9780.17181822196174022649@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-FEAS-SPF: spf-result=pass, ip=155.54.212.167, helo=xenon41.um.es, mailFrom=rafa@um.es
Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.167 as permitted sender) smtp.mailfrom=rafa@um.es
X-FE-Policy-ID: 2:15:0:SYSTEM
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=g583MgtvaPIeeMRJJU7tu5H1gN3EtFsNDEjJOZaGv/Q=; b=ljiEIFAFxd75r0gloRMg4rtzmpwzAHdQnFwRjDcUD1MLo8rouI2BXBvl0mZC+vAfTm4H0I7dzvZm DRa/dYd13LpL+My4Dtn+rnSR7xpIQU5twQnEIjujW4p2m82Q8iFUWs2+cqtzLpjL00e/Nc+jQeTK gZGt7H0oD/ZnwyrKexmNGVrsXImr+vt8rOsLAajTOGWIV/X7VRERcuppMf4qsQLvmnAM+vRUpYBm ekAC+rAr4hTx1hugNcSBmPQ8Lc3WUTZUj9X/uoIHhLNE9auHfebigPohyg0uQwDrC/Q3IOGYWsKu y8j1ihCb1A453XTI1uqQu/Agnx/zjs/ng4qyGA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/66JG9Isj7QHRF1OC3isWlAngpWg>
Subject: Re: [I2nsf] Erik Kline'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
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: Tue, 03 Nov 2020 12:06:14 -0000
Dear Erik: First of all, thank you very much for your comments. Please see ours inline. > El 2 nov 2020, a las 8:35, Erik Kline via Datatracker <noreply@ietf.org> escribió: > > Erik Kline 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: > ---------------------------------------------------------------------- > > general ] > > * Similar to df-bit and ecn, should there be a tunnel-grouping leaf that > controls how inner DSCP marking should be reflected on the outer IPsec > header? (RFC 2983 suggests using multiple tunnels instead and warns about > the danger of packet reordering as a result of variable DSCP marking (as > well as the potential information leak as a security issue), so maybe this > isn't important. First of all, we would like to highlight that in order to model IPsec SPD and SAD we have used mainly the RFC 4301, in particular, section 4.4.1 for SPD and section 4.4.2 for SAD. The corresponding Appendix C has been used as help. Regarding the tunnel-grouping, we already had: +--rw tunnel | | +--rw local inet:ip-address | | +--rw remote inet:ip-address | | +--rw df-bit? enumeration | | +--rw bypass-dscp? boolean | | +--rw dscp-mapping* inet:dscp | | +--rw ecn? boolean In fact, ASN1 in RFC 4301 (Appendix C) also refers to this information. For example bypass-dscp controls how DSCP is reflected on the outer IPsec header (see more comments below related to your question about bypass-dscp). > > Separately, what about a setting to explicitly configure the DSCP mark on > the outer header for all encap'd packets? Yes, that is reasonable (see our comments below). > > [ appendix A ] > > * I'm unclear on what bypass-dscp=true means. Does it mean that the DSCP > value is *not* part of the traffic selector? After your comment, we agree that this is a bit confusing. This value has been extracted from RFC 4301. More specifically: SPD entry: - Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs Same appears for a SAD entry (but with a more extended explanation) Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signaling concerns. Moreover we have in Appendix C: DSCP ::= SEQUENCE { copy BOOLEAN, -- TRUE copy from inner header -- FALSE do not copy mapping OCTET STRING OPTIONAL} -- points to table -- if no copy We believe this description of bypass-dscp would be more accurate to avoid any confusion in the following way: leaf bypass-dscp { type boolean; default true; description "If True, to copy the DSCP value from inner header to outer header. If False, to map DSCP values from an inner header to values in an outer header following a mapping in ../dscp-mapping"; reference "Section 4.4.1.2. in RFC 4301."; } Moreover the dscp-mapping could be improved to include your suggestion regarding to have a setting for the outer header DSCP marking. This would also simplify the model so that we may remove spd-mark container (which is implementation specific - XFRM) to implement the concept of mapping. We can also include the must you suggested below. list dscp-mapping { must '../bypass-dscp = "false"'; key id; ordered-by user; leaf id { type uint8; description "The index of the list with the different mappings."; } leaf inner-dscp { type inet:dscp; description "The DSCP value of the inner IP packet. If this leaf is not defined it means ANY inner DSCP value"; } leaf outer-dscp { type inet:dscp; default 0; description "The DSCP value for the outer IP packet. The default value is 0 - Best Effort (BE)."; } description "A list that represents an array with the mapping from the inner DSCP value to outer DSCP value when bypass-dscp is False"; reference "Section 4.4.1.2. and Appendix C in RFC 4301."; } In relation with this discussion, from Section 4.4.2.1 we should model the following in the ietf-i2nsf-ikeless: DSCP values -- the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA. as container sad { … container tunnel { when "../mode = 'tunnel'"; uses nsfikec:tunnel-grouping; leaf-list dscp-values { type inet:dscp; description "DSCP values allowed for packets carried over this IPsec SA. If no values are specified, no DSCP-specific filtering is applied"; reference "Section 4.4.2.1. in RFC 4301."; } description "Endpoints of the IPsec tunnel."; } Does it sound reasonable and clearer? Obviously, we are trying to reflect what we saw and understand from RFC 4301. > > Should this instead be called "ignore-dscp" or "skip-dscp”? We used the same name as we saw it in RFC 4301, though we do not have any problem at all to change it as suggested > > * Related: does the dscp-mapping leaf only have significance if bypass-dscp > is false? If so, is there some "must ../bypass-dscp ..." syntax that would > be applicable? Yes, that would completely applicable. In fact if you see the list dscp-mapping above we would include this must must '../bypass-dscp = "false"'; Is this reasonable?. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [[ comments ]] > > [ appendix A ] > > * WRT the df-bit description. I think something should say that this > MUST be ignored or has no meaning when the local/remote IP addresses > are IPv6 addresses. Correct. Done. > > [ appendix D ] > > * "2001:DB8" -> "2001:db8” everywhere Fixed. > > RFC 5952 section 4.3 says: lowercase for hex characters. Ah ok. > > [ appendix E ] > > * "2001:DB8" -> "2001:db8” everywhere Fixed. > > RFC 5952 section 4.3 says: lowercase for hex characters. > > > [[ questions ]] > > [ section 6.2 ] > > * Why is spd-mask a hex-string when spd-mark is a uint32? I would have > expected them both to be uint32 or, at a minimum, both the same type. > > In appendix A they both appear to be uint32. You’re completely right. It is a typo in Section 6.2. Fixed. > > > [[ nits ]] > > [ section 1 ] > > * Saying that SDN allows "users to directly program..." seemed a little odd > (vis. common definitions of "users"). Perhaps s/users/administrators/, or > "network operators"? Alternatively "allows I2NSF Users", perhaps. Administrators is good term. We can use that. > > [ section 6.2 ] > > * s/Notificsation/Notification/ Fixed. > > * s/conform/constitute/g? Fixed. > > [ appendix A ] > > * "NOT ESP encapsulation." -> "NO ESP encapsulation.", perhaps Fixed. > > [ appendix B ] > > * s/typedef pfs-group{/typedef pfs-group {/ Fixed. > > * s/the only defined right now/the only one defined right now/ Fixed. > > * In the description for pad/identity/ipv4-address: > > "Specifies the identity as a single four (4) octet." -> > "Specifies the identity as a single four (4) octet IPv4 address.” Fixed. Thank so you much again. > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es -------------------------------------------------------
- [I2nsf] Erik Kline's Discuss on draft-ietf-i2nsf-… Erik Kline via Datatracker
- Re: [I2nsf] Erik Kline's Discuss on draft-ietf-i2… Rafa Marin-Lopez
- [I2nsf] Fwd: Erik Kline's Discuss on draft-ietf-i… Rafa Marin-Lopez