From nobody Mon Dec 3 07:56:55 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896C112D7EA; Mon, 3 Dec 2018 07:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nGCgktNJ1Na0; Mon, 3 Dec 2018 07:56:51 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC9C12872C; Mon, 3 Dec 2018 07:56:48 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id i12so6566476pfo.7; Mon, 03 Dec 2018 07:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1lMlPtAp+8IdY/z8sJ1+V6xXO5Tzdo7NMqHAIojWqO4=; b=dqMtXowbN/JYhfPCQIBKyG1xDw43cIBR3VgrukhMUQkA667e4NM0hp3zZWIchoKn71 mGa/kcGmwuUc1vab3zBhpoTbI0ADs10juYWxGlWQY3B5rgZPgdhizV6kSFIi1nzuDbrg hfoRcJH7UQ5Oerh8kWMeOPDdviHuJs3qf5wzV9corMEs2s8Pff67PQm2+y/UCjgNhxgj fhO+f5Hxn5AJxDIU0VnCRKubhCUdI/w5sNaknzlKLLXWT3//KRxuShWQ6FmHWDIJ6eqd IwhEw179k0mdWtdtqbqJDowiY22pDe6heWQNKv8LnurQuR7eZdumasP6UwHKwoC880// Sk/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1lMlPtAp+8IdY/z8sJ1+V6xXO5Tzdo7NMqHAIojWqO4=; b=HHcDJ7JNBXIj/olzXb9EoNha6DaZueoYJbFp5PIdl9wo8exDYKzhgF44WMGPR63zE1 DqpJcqwDkkfOi3sOpuAKW14yguZZWJ9aAOt1/8zlG/zb6+3siWZFDrWMqbtSVabLDl3R At/2C6vXORF1nshJ/1b28KtxmtI3TvUNYBiNxZ0fLuf6GR9312SrvOsfRCSEkx3nli44 J7fnlqfJEVFFaWJq7O3nS07V9lRxSdkbPYPufyyHp1vpirsl43tZhTHigUkiGB0tt8YB f+8bDmkEAOMinl1NeA2Map3w4qDJvmJWkIQcNNIriv9WK+W3LFcF62Uf1OfeiQn3F3Sd 86pA== X-Gm-Message-State: AA+aEWZVQSs/DNUQMxm0LGCoGHLGsS0FtkW8NfYsVet/hNOu64aOwZE+ OSmZyrCcY8p+SNjgOCkq5Ef0BYCj X-Google-Smtp-Source: AFSGD/WKas2m+mZxRaaVrclNwj9qvCBc3w71hP+rodNXZbpeXyRczcw5XKuuGM9ZNGw6wOl2Ai7kBg== X-Received: by 2002:a62:e0d8:: with SMTP id d85mr16087369pfm.214.1543852607469; Mon, 03 Dec 2018 07:56:47 -0800 (PST) Received: from [172.16.33.70] ([144.178.28.6]) by smtp.gmail.com with ESMTPSA id c23sm20137870pfi.83.2018.12.03.07.56.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Dec 2018 07:56:46 -0800 (PST) From: "Christopher Wood" To: "Paul Wouters" Cc: secdir@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org Date: Mon, 03 Dec 2018 07:56:45 -0800 X-Mailer: MailMate (1.12.2r5568) Message-ID: <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> In-Reply-To: <154321083813.24275.4373340388504093292@ietfa.amsl.com> References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [Taps] Secdir early review of draft-ietf-taps-transport-security-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 15:56:54 -0000 (ietf to bcc to minimize spam) Hi Paul, Thanks for the feedback! Please see inline below. On 25 Nov 2018, at 21:40, Paul Wouters wrote: > Reviewer: Paul Wouters > Review result: Has Issues > > Review of draft-ietf-taps-transport-security-04 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is HAS ISSUES. > > SecDir tools note: The secdir review link refers to an abstract > containing the > text: > > This draft summarizes a number of IETF transport security > protocols a > > Note the word "IETF ... protocols". I don't actually see that in any > of the > revisions 00 to 04? Where did this comment/text come from? As Spencer noted, it likely originated from the early review request. > > Reading the introduction, this draft's goal is: > > This document provides a survey of commonly used or notable network > security protocols, with a focus on how they interact and integrate > with applications and transport protocols. Its goal is to > supplement > efforts to define and catalog transport services [RFC8095] by > describing the interfaces required to add security protocols. > > My first comment is regarding "commonly used or notable". Especially > the latter one is odd. Why should the IETF reader be aware of > "notable" but "not commonly used" protocols? And the reason I > say this is because it lists CurveCP and MinimalT, which as far > as I know are not deployed at all. While openvpn, which has a > serious userbase, is not mentioned at all. And openconnect, an open > specification compatible with Cisco Anyconnect, which even has a > draft, > draft-mavrogiannopoulos-openconnect-02, is not mentioned at all. In my > opinion, the document would be improved by adding Openvpn and > Openconnect, > and removing CurveCP and MinimalT. > > My second comment is regarding IETF vs non-IETF protocols. Or even > "specified in a draft or RFC" versus "there is an academic paper and > some > implementation and it's not clear what's what". The reason I am saying > this is that for instance the protocol "specification" of WireGuard > keeps > changing. Their website lists a "whitepaper" that is changing over > time > with no changelog, and wild claims that I've spend time in the last > few > years to counter, upon which it gets rewritten with new misleading or > wrong claims. > > It is kind of hard to do an IETF style summary of protocols when the > "specification" includes phrases like: > > the tunnel simply works. Key exchanges, connections, > disconnections, > reconnections, discovery, and so forth happen behind the > scenes > transparently and reliably, and the administrator does not > need to > worry about these details. In other words, from the > perspective of > administration, the WireGuard interface appears to be > stateless. > > This is not a white paper but a Public Relations document. > > None of the other discussed protocols in this document require > administrators to "worry" about those "details" either. > > At the IETF, we recommend IETF protocols. If someone comes up with an > alternative protocol that accomplishes the same as an existing one, we > tend to tell people to use the existing IETF protocol instead. Or, we > think their new protocol merits further standarization, and we ask > them > to produce either a ISE or IETF stream document that people can > reference, > comment, improve and discuss openly on its technical merits. > > It is also clear the white paper is not a good complete formal > specification like we do at IETF. For example, if there is packetloss, > the "specification" does not at all specify which of the parties (or > both?) are responsible for retransmission. Can one spoofed packet lead > a WireGuard endpoint to retransmit its response repeatedly? > > This further weakens their "stateless" claim. (and if it sounds like I > am being harsh, I know I am. It is because previously, I had to > counter > false claims about IPsec speed, and IKE "being noisy" where as having > looked again at "the whitepaper" (which keeps changing every time I > look > at it) it seems to now have a new hobby horse in the word "stateless". > the > openvpn tun0: is also "stateless", so is the VTI IPsec based interface > vti0: > > Because of these reasons, I am a bit worried that an IETF document is > making any claims about WireGuard features, as there is no way to know > what the protocol will be like by the time this document is published, > and this document cannot even point to a stable reference of te > specification > at the time of review. > > If this document wants to mention WireGuard as a protocol to take note > of, > I would like to see at least some text there urging WireGuard to write > up > (and version) their protocol in an IETF draft/RFC or other > proper/formal > specification. > > Now, having said all of this about WireGuard, I do agree with > mentioning > WireGuard in this document as it does have an actual userbase. Let's > just urge and help them with their specification. (and If the > author(s) > of WireGuard are reading this, I am more than happy to help you with > this) > > As for CurveCP and MinimalT, as far as I can see, these are just > academic > exercises with no serious deployment. While the IRTF might be > discussing > the these, I don't think an IETF document should reference these two > proof of concept ideas until they have matured more. Protocol selection criteria was admittedly sort of ad-hoc in the beginning. For starters, we included CurveCP and MinimalT because they are unique in one way or another in contrast to the other protocols considered. We then included WireGuard specifically because of its (growing) popularity. And while it continues to grow, we are careful to ensure the core feature set described remains stable. The informal criteria we’ve established now is that any new protocol must bring something new to the table. For example, we added protocols such as SRTP because they had features not yet covered by other protocols. That said, we can certainly add OpenVPN and OpenConnect to round things out. Though I see no issue with including CurveCP and MinimalT. As stated in the introduction, this document is not restricted to IETF protocols. Rather, it aims to survey any protocol that might influence the API surface exposed. It is our opinion that the set of protocols included meets this goal. If necessary, we can move the more esoteric protocols to the appendix, though we should certainly not remove them for lack of a specification. > > Introduction / Abstract: > > Expand/explain TAPS on first use? > > Section 4.4.1.1: > > IKEv2 is a control protocol that runs on UDP port 500 > > Change to: > > IKEv2 is a control protocol that runs on UDP or TCP port 4500 and UDP > port 500. > > Note you don't mention the one big drawback, that it cannot be run on > any UDP > port (although at least now we can run on any TCP port) which is an > important > problem when networks block IKE/IPsec on purpose compared to non-IETF > VPN > protocols. > > It then > goes through a phase of authentication in which both peers > present > blobs signed by a shared secret or private key, after which > another > set of keys is derived, referred to as the "Child SA". These > Child > SA keys are used by ESP. > > This text makes it appear only the blob's are authenticated, but the > entire > IKE exchange is authenticated. Also sessions keys are not all that is > a > Child SA. So perhaps: > > IKE then > performs a phase of authentication in which both peers present > blobs signed by a shared secret or private key that authenticates > the entire IKE exchange and the IKE identities. IKE then derives > further sets of keys on demand, which together with traffic policies > are referred to as the "Child SA". These Child SA keys are used by > ESP. > > Each proposal may contain an encryption algorithm, an > authentication > algorithm > > This is a bit misleading with both the "may" and the lack of AEAD > discussion? > Perhaps: > > Each proposal contains an encryption with authentication algorithm or > an AEAD > algorithm, > > Any SA used by IKEv2 can be rekeyed upon expiration, > > Rekeying happens before expiration, not upon (which would imply > trafficflow > interuption) Similarly to how it is described for tcpcrypt in the > document. So > perhaps just change "upon" to "before" ? Or go in a little more detail > with: > > Any SA used by IKE/IPsec can be rekeyed before expiration. It does so > by > negotiating a second SA, and once confirmed up and running, the old SA > is > deleted. This guarantees there is no slowdown or halt of traffic flow > during > rekeying. > > that allows a set of Security Associations to migrate over > different > addresses and interfaces > > I would say "different outer IP addresses and interfaces" > > Each SA is > identified by a Security Parameter Index (SPI), which is > marked on > each encrypted ESP packet. > > I would avoid the word "mark" here, since to me that more presents > internal > state inside a kernel (eg iptables MARK) and not something that goes > over the > wire. So perhaps: > > The SA of an encrypted packet is identified by its Security Parameter > Index > (SPI) [which is send as part of the ESP header) These are all great suggestions! We will include them. > > an anti-replay service (a form of partial sequence integrity) > > What is partial about this? Perhaps you meant to say ESP, like UDP, > does not > provide guaranteed delivery? Anyway, a "partial" security function > reads odd :) This is quoted text from RFC4303. > > and limited traffic flow confidentiality. > > What is "limited" about it? You can generate bogus traffic and pad > traffic to > any size (most common max mtu). What would you want in additional to > make it > not "limited" ? This text is also quoted from RFC4303, so we left it as is. Though I think your suggestions point to what the authors are leading towards: traffic analysis. > > One thing I would add to the ESP section is mentioning it acts like > UDP. It > cannot be reset by a single TCP RST packet, and you don't have two > layers of > netflows doing retransmission. This feature of ESP (and some UDP based > protocols in this document) is fairly important. > > Section 4.4.2.1: > > Mutual Authentication > > It is possible to do server-only or opportunistic/anonymous IKE as > well. Maybe > add "Usually" ? ACK — will do. > > 4.6.1: > > Tcpcrypt exposes a universally-unique connection-specific > session ID > to the application, suitable for application-level endpoint > authentication either in-band or out-of-band. > > This kind of conflicts with the introduction that claims this is only > an > opportunistic encryption protocol? Maybe merge this part into the > description > text? Good observation. Yes, that is misleading. We’ll try to fix it. > > 4.6.2: > > I might say here something about only passive attacker protection? > That seems > like an important difference compared to the other protocols. Or > perhaps make > this clear in the introduction text when mentioning opportunistic > encryption. Yes, good point. We’ll fix that. > > 4.7: > > WireGuard is a layer 3 protocol designed to complement or > replace > IPsec [WireGuard] for certain use cases. > > I am confused about how it "complements" IPsec? Perhaps you mean it is > an > "alternative" (and perhaps a non-IETF alternative) ? > > I think "replace" is very misleading, as IPsec has a vast number of > different > use cases compared to WireGuard's "static VPN configuration". Yes, we should drop “to complement or replace” and say that it’s an alternative. > > WireGuard is designed to be entirely stateless, modulo the > CryptoKey > routing table, > > Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm > not sure > how different the ESP/wireguard statelessness is on a scale or truly > stateless > to NFS > > You don't mention anything about port preconfiguartion and the "port > knocking" > thing? > > o Record replay prevention (Stateful, timestamp-based). > > I thought it was stateless module CryptoKey routing? :) > > You do not mention mobility or session resumption for WireGuard. Since > it is > all about static inner IP addresses over arbitrary outer addresses, it > has > mobility. And I guess the 1RTT means it has session resumption? > > Can you add a description of rekeying for WireGuard similar to > IKEv2/ESP? I > thought there was an issue there that during rekey, there is no > continued data > flow possible, so connections briefly slow down or halt when the > channel is > being rekeyed. I’m on the fence about this suggestion (and about keeping the IKEv2/ESP rekeying text). Some of the feedback we’ve received thus far is that the internal protocol details are irrelevant to the overall story. Rekeying might fall in that category. We’ll play with it and see if we can find a happy medium. > > Does WireGuard not offer padding or any other kind of Traffic > Confidentiality > options ? As far as I know, it does not. > > 4.8: > > The MinimalT section seems to lack some information bullet points > compared to > the other sections? eg shouldn't it have things like: o Datagram > Transport ? Indeed! This section needs some improvement. > > Misc: > > Should tor be added to the list of protocols? We hadn’t considered it, though it might be worth including. If we can find a new feature not yet exposed by the others, then yes, by our criteria outlined above. > > Why are MinimalT and CurveCP part of this list? Is there any actual > deployment > out there? I thought this document described actual transport security > protocols people can pick. I don't see CurveCP as a real candidate for > this. I > don't know about MinimalT. As stated above, ease of use or popularity in practice is not the only filter we used. I’m therefore inclined to keep these. > > 5: > > I'm a little confused by the term Application in this section. Is this > the > enduser application or the userland part of the security protocol (eg > IKE). I > think you mean the application of the enduser? Yes, the application of the enduser. > > 5.1: > > Listed as mandatory feature is: > > o Public-key certificate based authentication. > > Yet you have mentioned that neither WireGuard or CurveCP can do > authentication > based on certificates? Indeed. This should read, “Public-key (raw or certificate) based authentication.” > > 5.2: > > o Length-hiding padding (LHP): > > * Application dependency: Knowledge of desired padding > policies. > > This is not (always?) true? For example ESP can do padding after IKE > negotiated > it, and do it based on MTU ? The (end user) application does not have > to be > aware of anything? That’s a fair point, though (in my view) padding without application input seems incomplete. Perhaps we can rephrase this to: “(Optional) Application dependency: Knowledge of desired padding policies. Some protocols, such as IKE, can negotiate application-agnostic padding policies.” > > 5.3: > > The definition of "Mandatory" within this section is confusing. Maybe > use > another word like "Core" to indicate it is part of the core of the > protocol and > cannot be disabled? We used mandatory to be consistent with the section above. > > NITS: > > spelling error: defailt Oops. Will fix! Thanks again for your careful review and feedback. We greatly appreciate it. Best, Chris et al. From nobody Tue Dec 4 18:29:57 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 479DE130E0A; Tue, 4 Dec 2018 18:29:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget To: Cc: opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154397698424.4865.5720014731238210447@ietfa.amsl.com> Date: Tue, 04 Dec 2018 18:29:44 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 02:29:44 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Significant nits: This document provides recommendations that do include security considerations; but it is missing privacy considerations. While there may be no (or little impact), there should at least be some mention of privacy considerations in Section 6 (or create a new section). The document also references two drafts that are expired. General: it would be useful to reference the “EH Types” (RFC7045?) so that it is clearly distinct from the general “Option types” defined in RFC8200 (and also include the RFC8200 as reference on the first occurrence of “option types”) Section 2.1: the Terminology needs to be updated to comply with the latest BCP14 and RFC8174 Section 2.3: given the expressed terminology, I believe the “is *not*” is better stated as “SHOULD NOT” to be consistent with IETF guidelines in RFC8174. Section 2.3: this section not about “Conventions” but is really more about “Assumptions” with some recommendations already sprinkled, so the section should fall more in the “General Discussion” section Section 3.1: Not sure this is correct: “[RFC7045] identifies which of the currently assigned Internet Protocol numbers identify IPv6 EHs vs. upper-layer protocols. ” Reading RFC7045: it seems to be focused on how to process the extensions appropriately not sure it really does the identification of protocol layering or distinction? Simple Editorial nits: Section 2.3: redundant reference. Suggest to update from: “in [RFC7045]. Namely (from [RFC7045]),” to: “namely from [RFC7045]:” Section 3.1: the following sentence or perhaps the last clause (“they contain”) is not needed: “ This document discusses the filtering of packets based on the IPv6 EHs (as specified by [RFC7045]) they contain.” From nobody Tue Dec 4 19:07:35 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7A130DD2; Tue, 4 Dec 2018 19:07:21 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 X1MmEO2UDElv; Tue, 4 Dec 2018 19:07:19 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950E6130DBE; Tue, 4 Dec 2018 19:07:19 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id y126so9261929pfb.4; Tue, 04 Dec 2018 19:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Y3gX3y7Wq8EtbhyOB3aGadOQMTO4pa9wEPmW9zpKEBA=; b=c4Wszhjo5vzoJzj2AId9Pq/w14pmYp4hJDCVToYB1DoG4HVXnK0SGDKwjPWQl/FbT1 vZaXacaTmyTx/KdBv+X0wAKGgpGzX/W3WerYMsMoOfWspZgoOnTz0MA33XEnnc4LCVqX Wcbfb4l72eBsTv8XvzdTzq/Yl5g2bT9zFTXtkPDH7NJQInm/Oke4AtNicxIZuRxecKRD nKrwWqe6sKiMXDB87kNTP/4cJeDrMKPPinCnJm5rktYjfN+/q4WAUb3STHQ/gSH1Gk7q IdSu4d+DlcmBq0PEqnG4MEWoBQl8hVImMesZ7+lVuhQO3k5y69k5OC/YkYZewHbeZLO1 0A1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y3gX3y7Wq8EtbhyOB3aGadOQMTO4pa9wEPmW9zpKEBA=; b=bHAjXHluZmqgtxvQ71nkyufGeDB87NwuELFvemISAf+ZaJ/ot1Ms1ZMbsT1wSyZ1Vu rIPpPqCFbzRMIbtsKfu+NwOtOuNIkAp1M5uDpDawP2TSTtLzoj0dDT4/oc5i0QhB/QPe mgC4etAqD7FfUUBkVEfhSSAJ0eir6vLSsG/9t/UttK4zF+GPqYJtBik98AnrlUthXHnU jCtFvPAvTdAes0myZBiO+jlwmkLAluwDXAYHb/QZ28gYrfREFvSCbws8Hd/X7yx8OVDw 5NixweFDxhsSJgN75ulit8WR++YkdL8uU8mLYImhAQGnrzozd+BhgKn/YLDjKC5Ei7kX QSiw== X-Gm-Message-State: AA+aEWbpAstXtgwUM8jOlRBTRiijjvtXgz2M/orjg9RxANamdGHwhLw/ xEa2sC2R1hVIMCHGB2POa0+lm8n5w9E= X-Google-Smtp-Source: AFSGD/Vo884qQfUmBy8Bm/chzpn+SBwAUC6gtz/wKombkFk8J9qh2ZTQOk7KRN6XcC8a7J7xEFfTsQ== X-Received: by 2002:a63:6782:: with SMTP id b124mr19251209pgc.151.1543979238803; Tue, 04 Dec 2018 19:07:18 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id l22sm17627996pfj.179.2018.12.04.19.07.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 19:07:17 -0800 (PST) To: Nancy Cam-Winget , secdir@ietf.org Cc: opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154397698424.4865.5720014731238210447@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <80d710f4-8c77-66f4-6837-e93cbb57a008@gmail.com> Date: Wed, 5 Dec 2018 16:07:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <154397698424.4865.5720014731238210447@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 03:07:22 -0000 On 2018-12-05 15:29, Nancy Cam-Winget wrote: > Section 3.1: Not sure this is correct: =E2=80=9C[RFC7045] identifies > which of the currently assigned Internet Protocol numbers identify > IPv6 EHs vs. upper-layer protocols. =E2=80=9D > Reading RFC7045: it seems to be focused on how to process the extension= s > appropriately not sure it really does the identification of protocol la= yering > or distinction? It set up the IANA registry that makes the distinction: https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ex= tension-header There is no way except looking in that registry to distinguish an EH numb= er from a protocol number. Brian From nobody Fri Dec 7 14:32:02 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E44C130EDA for ; Fri, 7 Dec 2018 14:32:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154422192050.20395.6140172954723122155.idtracker@ietfa.amsl.com> Date: Fri, 07 Dec 2018 14:32:00 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 22:32:01 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-12-20 Reviewer LC end Draft Joseph Salowey R2018-11-20 draft-wilde-sunset-header-08 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-08 Last calls: Reviewer LC end Draft John Bradley 2018-11-26 draft-ietf-ippm-port-twamp-test-03 John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-10 Roman Danyliw 2018-12-12 draft-ietf-lsr-isis-rfc7810bis-03 Alan DeKok 2018-12-11 draft-ietf-mpls-rsvp-shared-labels-06 Linda Dunbar 2018-12-11 draft-ietf-mpls-lsp-ping-lag-multipath-05 Donald Eastlake 2018-12-11 draft-ietf-httpbis-cdn-loop-01 Shawn Emery 2019-01-01 draft-arkko-trip-registry-update-01 Stephen Farrell 2018-12-20 draft-ietf-extra-sieve-special-use-04 Daniel Franke 2018-12-18 draft-ietf-sidrops-rtr-keying-01 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-12-18 draft-ietf-rtgwg-spf-uloop-pb-statement-08 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-12 Steve Hanna 2018-12-18 draft-ietf-extra-sieve-fcc-08 Steve Hanna 2018-10-03 draft-ietf-detnet-problem-statement-08 Dan Harkins 2018-12-18 draft-ietf-bess-evpn-vpls-seamless-integ-05 Russ Housley 2018-12-18 draft-ietf-bess-evpn-df-election-framework-06 Christian Huitema 2018-12-14 draft-ietf-v6ops-transition-ipv4aas-11 Matthew Miller 2018-10-12 draft-ietf-httpbis-rand-access-live-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Yoav Nir R2018-12-12 draft-ietf-idr-te-pm-bgp-15 Melinda Shore 2018-11-06 draft-ietf-dmarc-arc-protocol-21 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-09 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Klaas Wierenga 2018-09-06 draft-ietf-softwire-mesh-multicast-23 Christopher Wood 2018-11-27 draft-ietf-nfsv4-mv0-trunking-update-02 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Derek Atkins 2018-12-05 draft-ietf-dnssd-mdns-relay-01 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-02 Christopher Wood 2018-12-04 draft-ietf-tsvwg-transport-encrypt-03 Next in the reviewer rotation: Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick From nobody Sat Dec 8 15:29:38 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1FC130FA2; Sat, 8 Dec 2018 15:29:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: draft-ietf-bess-evpn-df-election-framework.all@ietf.org, ietf@ietf.org, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154431176283.1419.9002617678445961562@ietfa.amsl.com> Date: Sat, 08 Dec 2018 15:29:22 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bess-evpn-df-election-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2018 23:29:23 -0000 Reviewer: Russ Housley Review result: Has Nits I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-bess-evpn-df-election-framework-06 Reviewer: Russ Housley Review Date: 2018-12-09 IETF LC End Date: 2018-12-18 IESG Telechat date: unknown Summary: Has Nits Major Concerns: None Minor Concerns: Please spell out EVPN on first use. I suspect that "Ethernet VPN" is good enough since "VPN" is quite well known. The Abstract seems to be overly complete, so it reads more like an Introduction. I suggest someting like: An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPN (EVPN) networks is defined. The DF is the Provider Edge (PE) router responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to multi-homed Customer Equipment (CE) on a particular Ethernet Segment (ES) within a VLAN. In addition, the capability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. I suggest that the original Abstract text become Section 2. Section 3 says: ... In addition, since the specification in EVPN [RFC7432] does leave several questions open as to the precise final state machine behavior of the DF election, section 3.1 describes precisely the intended behavior. This seems like an update to RFC 7432. If that is the intent, please update the Introduction and the Title Page Heading to say so. Nits: Section 2.2.1: s/multi homed/multi-homed/ Section 4: s/the state of the server states/the server states./ From nobody Sun Dec 9 18:04:49 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4691C124BAA for ; Sun, 9 Dec 2018 18:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b0LRST2Y6AWb for ; Sun, 9 Dec 2018 18:04:45 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19358128D0C for ; Sun, 9 Dec 2018 18:04:45 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id c16so6789098lfj.8 for ; Sun, 09 Dec 2018 18:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=C/wvKFC53ZJtZDMu++Rz0ZLcmHZI/DYxfp3QMwTnZKU=; b=RQEHNAlDv3gmFx2Awoc4SWQXgH4A9XOe3Bg1rR7M37xQ6dIFLXM9zyvvsKxXl9KfE3 k68jvJGxcnebWjgvAgXnoYQh9hLTNM1rMNbVFbrblCsefyQrrd6R9MXghUf1Fek9IK2z 4H7o/SzkEH24zkhSrUwOFXY0XFvbvXWkFOr+f6laKfN/Ke421/MkeQFhBKOMyzAbmi31 M1QBDFiULTCSu0M/0dH6on4mFR6lCOGdQqp1VvL9flxiC7MrnaOnXMMHKC+OZWaMKBID hz5yKdvQc0LeStf92MRCRA4SOwuvY3Evcj0ePYLb6IUFE+KjK1l4Pm2VT17ceG5ZknAr DINw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=C/wvKFC53ZJtZDMu++Rz0ZLcmHZI/DYxfp3QMwTnZKU=; b=OTmOg8kL7a+WK/up0GNq1YBKY12oHSVuYQq0W5gqcb7hT6bPXW0dDqMjeCl+KNv0Yj cA5PgTa7AxZ29qesQgs6e4mc2cyifINSD7ztSQAn57Z4pvnYGN1P8tSvMFsoit9xkGrh iTFLF641yzlZChHA59a3IroNof02SkIEkivm+R/4pOV2eb3JjF1/vERO6L8CM3n98aKc zYZzrWZEqwZSLsTtVAfhLAoOGM60onoCHdiHfet7b+5w+DcQKDU0lY9nPLyH1fhGMEc/ DtU2jRzq93SWcLFTsDS6bhamljI6arNDWJCrAiUIFdYb3ockfvAWkTje/czo1WJTn+7Y s5Ow== X-Gm-Message-State: AA+aEWbdGIivGIFTmVIfs6sgzEhnMAMpIKGhBq4pxSXV33nMwgExtiyd ni+7GxMjBEvceW+dGcxzo3QG4CPXo/D8pA2mzW5+YgmX X-Google-Smtp-Source: AFSGD/UyeZXDJyaBjxhH6QncijDQkE4zqSCvvR2kXIFNBrwEOrJyzSIEiB+eF7tUyhQ399c3eNjqCwiI+etnS8U1t6k= X-Received: by 2002:a19:2395:: with SMTP id j143mr5401964lfj.107.1544407482845; Sun, 09 Dec 2018 18:04:42 -0800 (PST) MIME-Version: 1.0 From: Shawn Emery Date: Sun, 9 Dec 2018 19:04:31 -0700 Message-ID: To: secdir@ietf.org, draft-arkko-trip-registry-update.all@tools.ietf.org Content-Type: multipart/alternative; boundary="0000000000006750bf057ca163de" Archived-At: Subject: [secdir] Review of draft-arkko-trip-registry-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 02:04:47 -0000 --0000000000006750bf057ca163de Content-Type: text/plain; charset="UTF-8" Reviewer: Shawn M. Emery Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft updates the Telephony Routing over IP (TRIP) protocol (RFC 3219) IANA registry requirements to no longer include the contact's postal address. The security considerations section does exist and states that there are no security threats introduced by this draft. I agree. General comments: None. Editorial comments: None. Shawn. -- --0000000000006750bf057ca163de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Shawn M. Emery
Review result: Ready
=

I have reviewed this document as part of = the security directorate's
ongoing effort to review all=C2=A0IETF=C2=A0documents being processed by the IESG.
These comments were written prima= rily for the benefit of the security
<= span style=3D"font-size:12.8px">area directors. Document editors and WG cha= irs should treat these
comments just like any other last call comments.

Th= is draft updates the=C2=A0Telephony Routin= g=C2=A0over IP (TRIP) protocol
(R= FC 3219)=C2=A0IANA registry require= ments to no longer include the
= contact's postal=C2=A0address.

The security considerations sec= tion does exist and states that there are no
security threats introduced by this draft.=C2=A0 I agree.

Genera= l comments:

None.

Editorial comments:

None.

Shawn.
--
--0000000000006750bf057ca163de-- From nobody Mon Dec 10 04:02:01 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8FE130EC0; Mon, 10 Dec 2018 04:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=nokia.onmicrosoft.com 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 w46GE6ENLalk; Mon, 10 Dec 2018 04:01:51 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150090.outbound.protection.outlook.com [40.107.15.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9338C130EBE; Mon, 10 Dec 2018 04:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yZbHojX38kFMk+zDxKFjHb/LusIyx6CqmMBc+xQnwao=; b=RWwGqSyFPN+GFi41JC7r/jdhU4WRkjjWwKnfi8b7hsQxF3G69nJHSTw4F270hWXZ9Rs4PcEEKW8tUo88JjVQN5QlDniLAI75RweUzL/pSgE2S4wH0UgrGg7d8biypBt5lOzSDyr7n0/Xr47YZQRhgErSdsOCpFhrA0ilSKMqC08= Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB4307.eurprd07.prod.outlook.com (52.133.60.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.9; Mon, 10 Dec 2018 12:01:45 +0000 Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::9438:df7a:ac48:18d0]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::9438:df7a:ac48:18d0%3]) with mapi id 15.20.1425.016; Mon, 10 Dec 2018 12:01:45 +0000 From: "Rabadan, Jorge (Nokia - US/Mountain View)" To: Russ Housley , "secdir@ietf.org" CC: "draft-ietf-bess-evpn-df-election-framework.all@ietf.org" , "ietf@ietf.org" , "bess@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-bess-evpn-df-election-framework-06 Thread-Index: AQHUj03d4dPy3EZ4RUKDlpRabSUf36V38mCA Date: Mon, 10 Dec 2018 12:01:45 +0000 Message-ID: References: <154431176283.1419.9002617678445961562@ietfa.amsl.com> In-Reply-To: <154431176283.1419.9002617678445961562@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181202 x-originating-ip: [135.245.20.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB4307; 6:P9q0LWIULV2FkDsSKv/x08MX9EHQATt+mh6boduaedg4x4y2MsoVgoKEtFhfehf5S4vNVciKy8ep+XT5fImxxCJR6wUISDZCEjgUDX+xWgD/IBxPLBkYaqYE4bvELCqJrpHn15qlNe1G7O0xkKgVOczekv59UlOrSwPWYnKZ8nT6DJd3M1JNgGfM5Zf4Sk586FVoWWGuqQz6MWwvX3Z8AHfvDVW3cIC82L83CuHWEYnLrCf3+gR6FN4b5YcDEz2vv0eRAzSgMvyx+3k0FKUuPql+s/HnVJBosQ/rHqeSH0L5IAG8F+kSUuUcPWIPsWXGKuH1Ii13CF6jVfJJK61MS84yUdpzsFu7T6+k6jts6U5R8UYutzpH7OwMdj46qWqeE+MR1vSip3HuVmapccAtAR7KgteXLYjd8VhLXYM0OVgMO7e5ijllpRwMynlSjqspagSDmQlXVAxGkNtFLQUBKA==; 5:rxaGV75THCQAy55xZ3byimYE7BHzBMRIfn3zfZvbKDduWayG8rFjLun2wLy4L0WQ1VbHTDSTRs3kqPRB/BJYel678t1qnNgTPtXGlXdfedIqrMjDfwEfOS4zu1oHlLU7IgchGCNjd+D8mSolWlacwlL0HYOD3Yj9ZeIsONZtp5E=; 7:du5BVgK13S4o07Y4sL2wfgRvyo6zxoeOKIB6y7djdmdw1cQTWv7r9uzyataWOuz3k4yPc2WlQqaApHdN+7OILcZ9SfBL9QEM2COMeOQEUTwTIHkHa9kx21av12alTNRft6GvNyvk1ue/zc5dQNphpw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7e04c6d0-57cf-4618-6908-08d65e974190 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB4307; x-ms-traffictypediagnostic: AM0PR07MB4307: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230017)(999002)(11241501185)(806100)(6040522)(2401047)(5005006)(8121501046)(3231472)(944501520)(52105112)(3002001)(93006095)(93001095)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4307; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4307; x-forefront-prvs: 08828D20BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(396003)(376002)(39860400002)(199004)(189003)(13464003)(186003)(6506007)(76176011)(26005)(102836004)(36756003)(2906002)(66066001)(53546011)(33656002)(446003)(99286004)(8936002)(6512007)(5660300001)(6246003)(11346002)(2616005)(486006)(14454004)(105586002)(4326008)(81166006)(81156014)(82746002)(8676002)(106356001)(53936002)(316002)(58126008)(54906003)(110136005)(229853002)(6436002)(305945005)(86362001)(7736002)(6486002)(83716004)(476003)(4001150100001)(3846002)(6116002)(71190400001)(2501003)(25786009)(71200400001)(68736007)(5024004)(256004)(478600001)(14444005)(66574011)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4307; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 8Dz6TQp7obqY7v2omXNASEK7ynNQNF+qz86qzR3wrwDomEIxaGNK+z+NOPz962cl3BhqeIFvP5us77+At+AFf1g6VTdG1ZMF3B5Mjv3Ty0/RAjsel36XYhaC8qPs/+BxTI1LzfpoCciVKqg2lAiPAL6S5EPJ76APxRt0O2aDfmIsMltWWHgK+eGxIAuLZgkSqOU04KMUfpV7vcBUqWNiKe+U8+6RHpEQ7ZUIjaKLIcIpiFHffEDuEOQIctCDETufDZSVvsSsE/JG5GohyAFbr3f1Vvyncs9Mq6Y82p+NSYdTN16ruxfmol743BT8mRHv spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e04c6d0-57cf-4618-6908-08d65e974190 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2018 12:01:45.1939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4307 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-evpn-df-election-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 12:01:54 -0000 SGkgUnVzcywNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXcuDQpXZSdsbCBw dWJsaXNoIGEgbmV3IHZlcnNpb24gb25jZSB3ZSBtYWtlIGFsbCB0aGUgY2hhbmdlcyBzdWdnZXN0 ZWQgYnkgdGhlIGRpZmZlcmVudCByZXZpZXdlcnMuDQoNClBsZWFzZSBzZWUgc29tZSBjb21tZW50 cyBpbi1saW5lIHdpdGggW0pPUkdFXS4NClRoYW5rIHlvdS4NCkpvcmdlDQoNCg0K77u/LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNl Yy5jb20+DQpEYXRlOiBTdW5kYXksIERlY2VtYmVyIDksIDIwMTggYXQgMzoyOSBBTQ0KVG86ICJz ZWNkaXJAaWV0Zi5vcmciIDxzZWNkaXJAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWlldGYtYmVzcy1l dnBuLWRmLWVsZWN0aW9uLWZyYW1ld29yay5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWJlc3Mt ZXZwbi1kZi1lbGVjdGlvbi1mcmFtZXdvcmsuYWxsQGlldGYub3JnPiwgImlldGZAaWV0Zi5vcmci IDxpZXRmQGlldGYub3JnPiwgImJlc3NAaWV0Zi5vcmciIDxiZXNzQGlldGYub3JnPg0KU3ViamVj dDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZGYtZWxl Y3Rpb24tZnJhbWV3b3JrLTA2DQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+ DQpSZXNlbnQtVG86IDxqb3JnZS5yYWJhZGFuQG5va2lhLmNvbT4sIDxzYXR5YW1vaEBjaXNjby5j b20+LCA8c2FqYXNzaUBjaXNjby5jb20+LCA8amRyYWtlQGp1bmlwZXIubmV0PiwgPGtpcmFuLm5h Z2FyYWpAbm9raWEuY29tPiwgPHNlbnRoaWwuc2F0aGFwcGFuQG5va2lhLmNvbT4sIDxtYXR0aGV3 LmJvY2NpQG5va2lhLmNvbT4sIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4sIDxtYW5r YW1pc0BjaXNjby5jb20+LCA8bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20+LCA8ZGIzNTQ2QGF0 dC5jb20+LCA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4sIFN0ZXBoYW5lIExpdGtvd3NraSA8c3Rl cGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+DQpSZXNlbnQtRGF0ZTogU3VuZGF5LCBEZWNlbWJl ciA5LCAyMDE4IGF0IDM6MjkgQU0NCg0KICAgIFJldmlld2VyOiBSdXNzIEhvdXNsZXkNCiAgICBS ZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KICAgIA0KICAgIEkgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu dCBhcyBwYXJ0IG9mIHRoZSBTZWN1cml0eSBEaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCiAgICBlZmZv cnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElF U0cuICBUaGVzZQ0KICAgIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBi ZW5lZml0IG9mIHRoZSBTZWN1cml0eSBBcmVhDQogICAgRGlyZWN0b3JzLiAgRG9jdW1lbnQgYXV0 aG9ycywgZG9jdW1lbnQgZWRpdG9ycywgYW5kIFdHIGNoYWlycyBzaG91bGQNCiAgICB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRz Lg0KICAgIA0KICAgIERvY3VtZW50OiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1kZi1lbGVjdGlvbi1m cmFtZXdvcmstMDYNCiAgICBSZXZpZXdlcjogUnVzcyBIb3VzbGV5DQogICAgUmV2aWV3IERhdGU6 IDIwMTgtMTItMDkNCiAgICBJRVRGIExDIEVuZCBEYXRlOiAyMDE4LTEyLTE4DQogICAgSUVTRyBU ZWxlY2hhdCBkYXRlOiB1bmtub3duDQogICAgDQogICAgU3VtbWFyeTogSGFzIE5pdHMNCiAgICAN CiAgICANCiAgICBNYWpvciBDb25jZXJuczogTm9uZQ0KICAgIA0KICAgIA0KICAgIE1pbm9yIENv bmNlcm5zOg0KICAgIA0KICAgIFBsZWFzZSBzcGVsbCBvdXQgRVZQTiBvbiBmaXJzdCB1c2UuICBJ IHN1c3BlY3QgdGhhdCAiRXRoZXJuZXQgVlBOIiBpcw0KICAgIGdvb2QgZW5vdWdoIHNpbmNlICJW UE4iIGlzIHF1aXRlIHdlbGwga25vd24uDQoNCltKT1JHRV0gZG9uZS4NCiAgICANCiAgICBUaGUg QWJzdHJhY3Qgc2VlbXMgdG8gYmUgb3Zlcmx5IGNvbXBsZXRlLCBzbyBpdCByZWFkcyBtb3JlIGxp a2UgYW4NCiAgICBJbnRyb2R1Y3Rpb24uICBJIHN1Z2dlc3Qgc29tZXRpbmcgbGlrZToNCiAgICAN CiAgICAgICBBbiBhbHRlcm5hdGl2ZSB0byB0aGUgZGVmYXVsdCBEZXNpZ25hdGVkIEZvcndhcmRl ciAoREYpIHNlbGVjdGlvbg0KICAgICAgIGFsZ29yaXRobSBpbiBFdGhlcm5ldCBWUE4gKEVWUE4p IG5ldHdvcmtzIGlzIGRlZmluZWQuIFRoZSBERiBpcyB0aGUNCiAgICAgICBQcm92aWRlciBFZGdl IChQRSkgcm91dGVyIHJlc3BvbnNpYmxlIGZvciBzZW5kaW5nIGJyb2FkY2FzdCwgdW5rbm93bg0K ICAgICAgIHVuaWNhc3QgYW5kIG11bHRpY2FzdCAoQlVNKSB0cmFmZmljIHRvIG11bHRpLWhvbWVk IEN1c3RvbWVyIEVxdWlwbWVudA0KICAgICAgIChDRSkgb24gYSBwYXJ0aWN1bGFyIEV0aGVybmV0 IFNlZ21lbnQgKEVTKSB3aXRoaW4gYSBWTEFOLiBJbiBhZGRpdGlvbiwNCiAgICAgICB0aGUgY2Fw YWJpbGl0eSB0byBpbmZsdWVuY2UgdGhlIERGIGVsZWN0aW9uIHJlc3VsdCBmb3IgYSBWTEFOIGJh c2VkDQogICAgICAgb24gdGhlIHN0YXRlIG9mIHRoZSBhc3NvY2lhdGVkIEF0dGFjaG1lbnQgQ2ly Y3VpdCAoQUMpIGlzIHNwZWNpZmllZC4NCiAgICANCiAgICBJIHN1Z2dlc3QgdGhhdCB0aGUgb3Jp Z2luYWwgQWJzdHJhY3QgdGV4dCBiZWNvbWUgU2VjdGlvbiAyLg0KDQpbSk9SR0VdIE9LLCBkb25l LCB0aGFua3MuDQogICAgDQogICAgU2VjdGlvbiAzIHNheXM6DQogICAgDQogICAgICAgLi4uICBJ biBhZGRpdGlvbiwgc2luY2UgdGhlIHNwZWNpZmljYXRpb24gaW4gRVZQTg0KICAgICAgIFtSRkM3 NDMyXSBkb2VzIGxlYXZlIHNldmVyYWwgcXVlc3Rpb25zIG9wZW4gYXMgdG8gdGhlIHByZWNpc2Ug ZmluYWwNCiAgICAgICBzdGF0ZSBtYWNoaW5lIGJlaGF2aW9yIG9mIHRoZSBERiBlbGVjdGlvbiwg c2VjdGlvbiAzLjEgZGVzY3JpYmVzDQogICAgICAgcHJlY2lzZWx5IHRoZSBpbnRlbmRlZCBiZWhh dmlvci4NCiAgICANCiAgICBUaGlzIHNlZW1zIGxpa2UgYW4gdXBkYXRlIHRvIFJGQyA3NDMyLiAg SWYgdGhhdCBpcyB0aGUgaW50ZW50LCBwbGVhc2UNCiAgICB1cGRhdGUgdGhlIEludHJvZHVjdGlv biBhbmQgdGhlIFRpdGxlIFBhZ2UgSGVhZGluZyB0byBzYXkgc28uDQoNCltKT1JHRV0gVGhlIGF1 dGhvcnMsIGNoYWlycyBhbmQgQUQgaGF2ZSBkaXNjdXNzZWQgdGhpcyBhIGZldyB0aW1lcyBhbmQg d2UgYWdyZWVkIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYW4gdXBkYXRlIG9mIFJG Qzc0MzIsIHNpbmNlIGl0IGlzIG5vdCBzdWdnZXN0aW5nIGFueSBjaGFuZ2VzIHRvIHRoZSBleGlz dGluZyBSRkM3NDMyIHByb2NlZHVyZXMsIGJ1dCBuZXcgcHJvY2VkdXJlcy4gVGhhdCBzZWN0aW9u IGlzIGp1c3QgYSBkZXNjcmlwdGlvbiBvZiB0aGUgZXhpc3Rpbmcgc3RhdGUgbWFjaGluZS4gSG93 ZXZlciwgaWYgeW91IGFuZCBvdGhlciByZXZpZXdlcnMgc3RpbGwgdGhpbmsgaXQgc2hvdWxkIGJl IGFuIHVwZGF0ZSwgd2UgY2FuIG1heWJlIGNoYW5nZSB0aGUgdGVzdCBvciBkaXNjdXNzIGl0IGFn YWluLiBUaGUgaW50ZW5kIGlzIGRlZmluaXRpdmVseSBub3QgdG8gdXBkYXRlIFJGQzc0MzIuDQog ICAgDQogICAgDQogICAgTml0czoNCiAgICANCiAgICBTZWN0aW9uIDIuMi4xOiAgcy9tdWx0aSBo b21lZC9tdWx0aS1ob21lZC8NCiAgICANCiAgICBTZWN0aW9uIDQ6ICBzL3RoZSBzdGF0ZSBvZiB0 aGUgc2VydmVyIHN0YXRlcy90aGUgc2VydmVyIHN0YXRlcy4vDQpbSk9SR0VdIGZpeGVkLCB0aGFu ayB5b3UuDQogICAgDQogICAgDQoNCg== From nobody Mon Dec 10 18:55:27 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0B12426A; Mon, 10 Dec 2018 18:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 skbvo7VLrG9u; Mon, 10 Dec 2018 18:55:24 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 9F878126CC7; Mon, 10 Dec 2018 18:55:24 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wBB2tN7v008263; Mon, 10 Dec 2018 21:55:23 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu wBB2tN7v008263 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1544496923; bh=l7I4aqLI3C+FZaUZzeMDJ+1wDERV6/M5PWPP7RvN+sU=; h=From:To:Subject:Date:From; b=L9BF03cfcer9s4ePZtrs2xh/mYnJ07Fl0miM27ZFBz+rllRz8OXOI+cFpmA+6eiFU PIMNPmoQvynUazLuZNle+t21iH/A87n6TnTcmFuN2HYfymhWdzMVKTjxTQlCpuSvmL 8K93HSfPf1BLAhBbrRiqsQSgUXd866gE0jwHf/5I= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wBB2tIOj002915; Mon, 10 Dec 2018 21:55:18 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0415.000; Mon, 10 Dec 2018 21:55:18 -0500 From: Roman Danyliw To: "secdir@ietf.org" , "draft-ietf-lsr-isis-rfc7810bis@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-lsr-isis-rfc7810bis-03 Thread-Index: AdSQ/Ax3a8nBEVGyRgq+8VLVl1/2TQ== Date: Tue, 11 Dec 2018 02:55:17 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0184C5E4B7@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lsr-isis-rfc7810bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 02:55:26 -0000 Document: draft-ietf-lsr-isis-rfc7810bis-03 Reviewer: Roman Danyliw Review result: Has Nits I reviewed this document as part of the Security Directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comment= s were written primarily for the benefit of the Security Area Directors. D= ocument authors, document editors, and WG chairs should treat these comment= s just like any other IETF Last Call comments. As the shepherd write-up [1] and Appendix A of this draft indicate, the te= xt in this document is nearly identical to RFC7801 beyond changes made to S= ection 4. Nothing new was added to this bis draft beyond addressing errata= . The minor editorial nits from this review are: (1) This draft doesn't register anything new. Section 2 opens with "[t]hi= s document registers new IS-IS TE sub-TLVs ...". Technically, the RFC7801 = already registered them. Perhaps "This document describes IS-IS TE sub-TLV= s that can be ..." (2) Per Section 11, consider s/man-in-the-middle/on-path-attacker/ per [2] Not being deemed a nit that should be addressed here, but this draft does b= ase some of its security properties on RFC5304/HMAC-MD5. [1] https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/shepher= dwriteup/ [2] https://www.ietf.org/mail-archive/web/ietf/current/msg109350.html From nobody Tue Dec 11 03:40:23 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06624130DD5; Tue, 11 Dec 2018 03:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 enLn2J4o8B30; Tue, 11 Dec 2018 03:40:21 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FF8130DDB; Tue, 11 Dec 2018 03:40:18 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id o19so3035648itg.5; Tue, 11 Dec 2018 03:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Yt3gqCliQW5jS3Ezbcnck3iTxoCixBawlxyHaTJoXoA=; b=klDZpM5rHI8V2kiWTJMwh0Bpj8CQ3dwbtVrVX1cMMWe0/vmGYRq4GLKiUOQs8xX3Fd cEw3L2z8C1+AH+U5RJ503QfN+t1m8ajgKQThXq1jDhfMWm4zAGNOG7JOpae1Wus0XEWr /7K/8gNXa/LtsavQUVyhRpJDJva+ODRraCotdXtAGF/H3xRmSmdwT0WADgkKDoRLtaIv XCvzP3JZGPGXIQiot0oIcagEvPUYS0HBXr38GbPxDyuetcnxzS6zVMiofvHCBtXZtjx6 3tkaUJiifxdwUP9HcRvT+RKNfeNeo54ZJBmMQ06t6F35hllcT1QFkyFKIMRoUo/H3lrQ I/tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Yt3gqCliQW5jS3Ezbcnck3iTxoCixBawlxyHaTJoXoA=; b=Mtx5RKXOzzzMInX8+NsR5vrstw4r5wDhpodEoPnOiO1Otb/ZT1hxhm7VSH/Q9HxvwY uz7GBNUmSkdBKuirKlAYTIPhZNTXVhkzkG3bLAw6I8sHjS+LeJLKb6/EFk+F7ZDt8Ht3 eA/54k/bwl1/ZkX+qnCT1w5v7HDLFsvej1LDHIErlQePNuJpsHEHaSg78x1+s6HHb4nO 1OL/EqGwI4ILeZc7pvbf5pCynZHObVkwrzuo8quEktQs/iZQxfs1KX9cDU0fBm+7PFAv B0OgyTSb0AbKBzmNB1h/qfD3Z3CK7O1KPbU4lwgdp6I0lT7pHwUSYvJV3M3H3GcPnTyE 997g== X-Gm-Message-State: AA+aEWbHdi8qxlMWzbgyiQvuI25cQiHuAbYTTi67cARlfsKTblwIxyrI 9XU8bXOiDVdbALjE0QIhNloKB0YIYmZCVDduROYE7snt X-Google-Smtp-Source: AFSGD/X51CNH6zrWkWLTGZ3Q6cMMijeR8uJnk9ddZpytVehE+wkfUIgUzujnU9IZgE30Gy5/DM8jWi6d5qnHpnDPizk= X-Received: by 2002:a24:6e88:: with SMTP id w130mr1715974itc.103.1544528416961; Tue, 11 Dec 2018 03:40:16 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Tue, 11 Dec 2018 06:40:05 -0500 Message-ID: To: "iesg@ietf.org" , draft-ietf-httpbis-cdn-loop.all@ietf.org Cc: secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000a37ae5057cbd8b9a" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-httpbis-cdn-loop-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 11:40:22 -0000 --000000000000a37ae5057cbd8b9a Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with issues. This document specifies a new "CDN-Loop" HTTP header field to detect Content Delivery Network loops. Such loops can be caused by misconfiguration or as part of a denial of service attack. Security: It is slightly misleading that in Section 1 the draft says how valuable an HTTP header "guaranteed not to be modified" would be but then the draft does not provide such a header. Maybe instead say "should normally be unmodified". I believe this document should RECOMMEND that CDN-Loop headers include some sort of MAC (Message Authentication Code) covering the header so a CDN node can reliably recognize CDN-Loop headers that it has added. Since it need only recognize its own headers, the MAC need not be further specified or interoperable. (CDN-Loop information in an HTTP message can grow by the appending of entries or by additional of another CDN-Loop header. Since I have little confidence in the stability of header order, I would suggest MACs added as a parameter to a CDN-Loop header by the last parameter for that entry and sign that entry and all previous entries in that CDN-Loop header.) This could be done by modifying the 3rd paragraph of the Security Considerations section. Nit: Section 2: 3rd paragraph, suggest replacing "field to all requests" with "field in all requests". Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com --000000000000a37ae5057cbd8b9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG.=C2=A0 Document editors and WG chairs should treat these comment= s just like any other last call comments.

The summary of the review = is Ready with issues.

This document specifies a new "CDN-Loop&q= uot; HTTP header field to detect Content Delivery Network loops. Such loops= can be caused by misconfiguration or as part of a denial of service attack= .

Security:

It is slightly misleading that in Section 1 the = draft says how valuable an HTTP header "guaranteed not to be modified&= quot; would be but then the draft does not provide such a header. Maybe ins= tead say "should normally be unmodified".
=
<= div>I believe this document should RECOMMEND that CDN-Loop headers include = some sort of MAC (Message Authentication Code) covering the header so a CDN= node can reliably recognize CDN-Loop headers that it has added. Since it n= eed only recognize its own headers, the MAC need not be further specified o= r interoperable. (CDN-Loop information in an HTTP message can grow by the a= ppending of entries or by additional of another CDN-Loop header. Since I ha= ve little confidence in the stability of header order, I would suggest MACs= added as a parameter to a CDN-Loop header by the last parameter for that e= ntry and sign that entry and all previous entries in that CDN-Loop header.)= This could be done by modifying the 3rd paragraph of the Security Consider= ations section.

Nit:

Section 2: 3rd parag= raph, suggest replacing "field to all requests" with "field = in all requests".

Thanks,
Donald
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0= 1424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com
--000000000000a37ae5057cbd8b9a-- From nobody Tue Dec 11 06:16:43 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DFC1277CC; Tue, 11 Dec 2018 06:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 p8b9lISfO6cK; Tue, 11 Dec 2018 06:16:40 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC23127333; Tue, 11 Dec 2018 06:16:37 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id w6so6695684pgl.6; Tue, 11 Dec 2018 06:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=VC6WgYu/M7c6gIqF32lzCLgnOEe+5bPgPQwJg6vUmoo=; b=Q4wAQdV/SgqWWNg+RHi0dz5kEsyaFpn8xfi1jU6vi+TJzqVYFAFR9+aWKcpK3rBteJ GjVTJTfjxg0kUfip160r3KeoQLr6xoW9MIVi6FcPCyXLbKIiT4trSjCQ7diwGdkvWaD0 qwqT9uoZdtGjAUHpSBBV0rG2MzzpF8ZVE6p/1cDp5ZaRCGSqguAoyeHOAthOypAP8VPg /a3c4hI8MHluen3AyBRCWszI7ad8eDqJBfKi20taqiIepyWDgRIJJkbCKM/KsL2nVRim g6/W7UQZp/d38SvXJs0tu1gxRFYcGXqiJBFHr/bOHEQsGPxA754U0itEf9n3LjNWugD2 ruqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=VC6WgYu/M7c6gIqF32lzCLgnOEe+5bPgPQwJg6vUmoo=; b=GYsKi/zzB6mMITwxLeN63/j5eEslSao1d4bgTDEoex+DMaEHGRRofxftKhgBBEP9Al 7L/O4Hx64yDXvX78SiLEkrSKLYqjepS+r4mUdyyuXyutyIBInvlBGJuPEjHLcRCWI8YH ikbW824h/3hpgOd0w/MsgKZ1pab41AomqhdEGm7PKdeytYNFasEm0nffPyUKmVy931wu R/v1zA0Ae6GR8equ3WvLCG3kTIg1MLQZyBprlwgufpnvClYOMEqsCqsa1c9ulIL9QEW2 TbJ0z0VRX4Ukjhx681IUueGCBSBq7kY9eK7bXg+pWCcZnoNhpjl21pJNq1ylwrmTu2j9 Tciw== X-Gm-Message-State: AA+aEWbIvN1n9tJSCQlla2z5rsqnbGhxwwbmfaw/mS5m404rO1P1L94H 1iXTPnwv4NC54fQmLyBbSOx0z07U X-Google-Smtp-Source: AFSGD/XLhCreErdrvVnIpz3b6QIQjWFNkxDZBRSkX72xiVtHCpWgN9lStqeDprdF42sydHkDwr6sQQ== X-Received: by 2002:a62:3a04:: with SMTP id h4mr16327741pfa.119.1544537796036; Tue, 11 Dec 2018 06:16:36 -0800 (PST) Received: from [10.0.0.184] ([2601:646:8100:1cfc:9555:9833:e3d2:73f7]) by smtp.gmail.com with ESMTPSA id l3sm24677313pga.92.2018.12.11.06.16.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 06:16:35 -0800 (PST) From: "Christopher Wood" To: "The IESG" , secdir@ietf.org, draft-ietf-nfsv4-mv0-trunking-update@ietf.org Date: Tue, 11 Dec 2018 06:16:33 -0800 X-Mailer: MailMate (1.12.2r5568) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [secdir] secdir review of draft-ietf-nfsv4-mv0-trunking-update-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 14:16:41 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of my review is: Ready with nits. This document is in great shape and very well written. Most of my comments are editorial in nature aimed at helping improve readability of the document. Please let me know if you’ve further questions, comments, or concerns. - Section 3, fourth bullet: Regarding “[NFSv4.1] distinguishes two (see [RFC5661]),” would it be possible to provide the two types of trunking relationships inline? Although this document is meant to supplement existing work, I do think it would help improve readability and minimize cross-referencing. - Section 5.1, fifth bullet: Rather than specify that addresses “MUST provide a way of connecting to a single server,” could we specify desired client behavior if this does not happen? I do not know how often such misconfigurations occur, though it seems prudent to provide guidance in case it does. - Section 5.2, sixth bullet: It might be worth pointing to the amended Security Considerations section, which contains relevant text regarding DNSSEC validation for host name entries. I left a note here while reading only to discover it was addressed later on. - Section 5.2.3: Are clients allowed to race connection attempts across all types available? The text implies that this must be done sequentially, which seems unnecessarily prohibitive. - Section 5.2.5, third paragraph, first sentence: Perhaps a simpler way to write this is something akin to “fs_locations cannot point to alternate locations until data propagation occurs”? Best, Chris From nobody Tue Dec 11 11:42:14 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA53C130F58; Tue, 11 Dec 2018 11:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VdN8-OGsojWr; Tue, 11 Dec 2018 11:42:11 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 32071130F55; Tue, 11 Dec 2018 11:42:11 -0800 (PST) Received: from [192.168.20.203] (unknown [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id BEDFE621; Tue, 11 Dec 2018 19:42:09 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: Date: Tue, 11 Dec 2018 14:42:08 -0500 To: secdir@ietf.org, draft-ietf-mpls-rsvp-shared-labels.all@ietf.org X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: [secdir] Secdir review of draft-ietf-mpls-rsvp-shared-labels-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 19:42:13 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. The summary of the review is Ready. The document seems to be clear and well written. I have no additional = comments. From nobody Tue Dec 11 12:24:31 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F74130F63; Tue, 11 Dec 2018 12:24:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar To: Cc: mpls@ietf.org, draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154455986336.13151.8483284555885294015@ietfa.amsl.com> Date: Tue, 11 Dec 2018 12:24:23 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 20:24:24 -0000 Reviewer: Linda Dunbar Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with comment The described mechanism for LSP Multipath Ping is very clear. The Security Consideration re-uses the description of RFC8029, which is very comprehensive. It would be better if the draft describes how to prevent intermediate LSRs in between the Initiating LSR and Responding LSR from mis-using the detailed link information (e.g. forwarding to somewhere else). Best Regards, Linda Dunbar From nobody Thu Dec 13 03:17:53 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EE71286E3 for ; Thu, 13 Dec 2018 03:17:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154469987188.2732.8897923391902284017.idtracker@ietfa.amsl.com> Date: Thu, 13 Dec 2018 03:17:51 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 11:17:52 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-12-20 Reviewer LC end Draft Joseph Salowey R2018-11-20 draft-wilde-sunset-header-08 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-08 Last calls: Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-10 Stephen Farrell 2018-12-20 draft-ietf-extra-sieve-special-use-04 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-12-18 draft-ietf-rtgwg-spf-uloop-pb-statement-08 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-13 Steve Hanna 2018-12-18 draft-ietf-extra-sieve-fcc-08 Christian Huitema 2018-12-14 draft-ietf-v6ops-transition-ipv4aas-11 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Charlie Kaufman 2018-12-24 draft-ietf-6lo-deadline-time-03 Scott Kelly 2018-12-21 draft-ietf-sipcore-sip-push-21 Stephen Kent 2018-12-18 draft-ietf-bess-evpn-vpls-seamless-integ-05 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Yoav Nir R2018-12-12 draft-ietf-idr-te-pm-bgp-15 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-10 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Derek Atkins 2018-12-05 draft-ietf-dnssd-mdns-relay-01 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-02 Christopher Wood 2018-12-04 draft-ietf-tsvwg-transport-encrypt-03 Next in the reviewer rotation: Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault From nobody Thu Dec 13 09:00:25 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0622130DFF; Thu, 13 Dec 2018 09:00:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: Cc: idr@ietf.org, ietf@ietf.org, draft-ietf-idr-te-pm-bgp.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154472041086.32079.7701806228294346668@ietfa.amsl.com> Date: Thu, 13 Dec 2018 09:00:10 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-te-pm-bgp-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 17:00:11 -0000 Reviewer: Yoav Nir Review result: Ready This completes my early review of this draft. All the points I've raised have been addressed. I believe that the current draft has the needed text in the security considerations section. From nobody Thu Dec 13 12:49:43 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 901AC130E9B; Thu, 13 Dec 2018 12:49:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154473417654.32125.9104927217788947044@ietfa.amsl.com> Date: Thu, 13 Dec 2018 12:49:36 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 20:49:37 -0000 Reviewer: Christian Huitema Review result: Has Issues I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is "ready with issue". The document describes solution for providing "IPv4 as a service", i.e. provision of IPv4 as a service over an IPv6 only network. It calls this support "transition as a service". For various reasons, IETF working groups have standardized not just one but five different mechanisms for providing this transition: 464XLAT [RFC6877], Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python could have produced a nice sketch about that.) The purpose of the draft is to state how home routers (a.k.a. customer premise equipment, CPE) should inform local devices about which of the mechanisms are available, which should be preferred, and what parameters should be used when deploying the chosen services. This is done using the DHCPv6 "S46" option specified in RFC 8026. The draft also makes specific recommendation regarding the use of the UPnP and PCP services, by requiring specific error codes when a requested port mapping is not available through the specified transition technology. The security section briefly points to the "Basic Requirements for IPv6 Customer Edge Routers" specified in RFC 7084, and to the security section of each of the RFC describing the security technologies, and implicitly argues that there are no other security issues. I think that is insufficient. The draft introduces a reliance on the DHCPv6 "S46" option for assessing the relative priority of different transition technologies. An attacker could spoof the DHCPv6 response, and direct client traffic to a different technology than selected by the service provider. This could be used, for example, to capture IPv4 traffic in an IPv6 network and send it to a route chosen by the attacker. The attack might also be used in a dual stack network that does not support any transition technology. I don't understand how this attack is mitigated. Nits: The introduction uses the acronym WAN without spelling out "Wide Area Network". Also, WAN is used as substitute for local Internet Service Provider network. We could debate whether such networks are always "wide area", by opposition to say "metropolitan" or "regional". This is the same convention used in RFC 7084 that this document updates. It is arguably defined by reference, but spelling it out would be nice. The comparison with RFC7084 section includes a mangled sentence: This document doesn't include support for 6rd ([RFC5969]), because as in an IPv6-in-IPv4 tunneling. Please rephrase. Please also rephrase the next sentence, for similar reasons: Regarding DS-LITE [RFC6333], this document includes slightly different requirements, because the PCP ([RFC6887]) support and the prioritization of the transition mechanisms, including dual-stack. From nobody Thu Dec 13 13:14:20 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 183D6130E9A; Thu, 13 Dec 2018 13:14:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Kent To: Cc: draft-ietf-bess-evpn-vpls-seamless-integ.all@ietf.org, ietf@ietf.org, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154473564505.32043.14717744747073496646@ietfa.amsl.com> Date: Thu, 13 Dec 2018 13:14:05 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 21:14:05 -0000 Reviewer: Stephen Kent Review result: Has Nits BESS Workgroup A. Sajassi (Editor) INTERNET-DRAFT S. Salam Intended Status: Standard Track Cisco N. Del Regno Verizon J. Rabadan Nokia Expires: May 27, 2019 November 27, 2018 (PBB-)EVPN Seamless Integration with (PBB-)VPLS draft-ietf-bess-evpn-vpls-seamless-integ-05 Abstract This draft specifies procedures for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB- EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions (PBB-)VPLS. It also provides mechanisms for seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce (PBB-)EVPN PEs in their brown-field deployments of (PBB-)VPLS networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Sajassi et al. Expires May 27, 2019 [Page 1] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 Copyright and License Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 6 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 3.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 9 3.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 9 3.4.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 9 4 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 10 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 10 4.3 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Multicast Operation . . . . . . . . . . . . . . . . . . . . 11 4.4.1 Ingress Replication . . . . . . . . . . . . . . . . . . 11 4.4.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 12 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1 Normative References . . . . . . . . . . . . . . . . . . . 12 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Sajassi et al. Expires May 27, 2019 [Page 2] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 1 Introduction Virtual Private LAN Service (VPLS) and Provider Backbone Bridging VPLS (PBB-VPLS) are widely-deployed Layer-2 VPN (L2VPN) technologies. Many Service Providers (SPs) who are looking at adopting Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to preserve their investment in the VPLS and PBB-VPLS networks. Hence, they require procedures by which EVPN and PBB-EVPN technology can be introduced into their brown-field VPLS and PBB-VPLS networks without requiring any upgrades (software or hardware) to these networks. This document specifies procedures for the seamless integration of the two technologies in the same MPLS/IP network. Throughout this document, we use the term (PBB-)EVPN to correspond to both EVPN and PBB-EVPN and we use the term (PBB-)VPLS to correspond to both VPLS and PBB- VPLS. VPLS PE +---+ |PE1| +---+ / EVPN/VPLS PE +---------------+ EVPN/VPLS PE +---+ | | +---+ |PE4|----| MPLS/IP |---|PE5| +---+ | Core | +---+ | | +---------------+ / \ +---+ +---+ |PE2| |PE3| +---+ +---+ VPLS PE VPLS PE Figure 1: Seamless Integration of (PBB-)EVPN & (PBB-)VPLS Section 2 provides the details of the requirements. Section 3 specifies procedures for the seamless integration of VPLS and EVPN networks. And section 4 specifies procedures for the seamless integration of PBB-VPLS and PBB-EVPN networks. It should be noted that the scenarios for PBB-VPLS integration with EVPN and VPLS integration with PBB-EVPN are not covered in this document because there haven't been any requirements from service providers for these scenarios. The reason for that is that deployments which employ PBB-VPLS typically require PBB encapsulation for various reasons. Hence, it is expected that for those deployments the evolution path would be from PBB-VPLS towards PBB-EVPN. Furthermore, the evolution path from VPLS is expected to be towards Sajassi et al. Expires May 27, 2019 [Page 3] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 EVPN. The seamless integration solution described in this document has the following attributes: - When ingress replication is used for multi-destination traffic delivery, the solution reduces the scope of [MMRP] (which is a soft- state protocol) to only that of existing VPLS PEs, and uses the more robust BGP-based mechanism for multicast pruning among new EVPN PEs. - It is completely backward compatible. - New PEs can leverage the extensive multi-homing mechanisms and provisioning simplifications of (PBB-)EVPN: a. Auto-sensing of MHN / MHD b. Auto-discovery of redundancy group c. Auto-provisioning of Designated Forwarder election and VLAN carving 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terms and Abbreviations Broadcast Domain: In a bridged network, the broadcast domain corresponds to a Virtual LAN (VLAN), where a VLAN is typically represented by a single VLAN ID (VID) but can be represented by several VIDs where Shared VLAN Learning (SVL) is used per [IEEE.802.1ah]. Bridge Table: An instantiation of a broadcast domain on a MAC-VRF RIB: Routing Information Base - An instantiation of a routing table on a MAC-VRF FIB: Forwarding Information Base - An instantiation of a forwarding table on a MAC-VRF CE: A Customer Edge device, e.g., a host, router, or switch. MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on an EVPN PE. Sajassi et al. Expires May 27, 2019 [Page 4] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 MAC address: Media Access Control address C-MAC address: Customer MAC address - e.g., host or CE's MAC address B-MAC address: Backbone MAC address - e.g., PE's MAC address Ethernet segment (ES): Refers to the set of Ethernet links that connects a customer site (device or network) to one or more PEs. Ethernet Tag: An Ethernet Tag identifies a particular broadcast domain, e.g., a VLAN. An EVPN instance consists of one or more broadcast domains MHD: Multi-Homed Device MHN: Multi-Homed Network P2MP: Point-to-Multipoint PBB: Provider Backbone Bridge PE: Provider Edge device VSI: Virtual Switch Instance VPLS: Virtual Private LAN Service Single-Active Redundancy Mode: When only a single PE, among all the PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet segment for a given VLAN, then the Ethernet segment is defined to be operating in Single-Active redundancy mode. All-Active Redundancy Mode: When all PEs attached to an Ethernet segment are allowed to forward known unicast traffic to/from that Ethernet segment for a given VLAN, then the Ethernet segment is defined to be operating in All-Active redundancy mode. (PBB-)EVPN: refers to both, PBB-EVPN and EVPN. This document uses this abbreviation when a given description applies to both technologies. (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this abbreviation is used when the text applies to both technologies. VPLS A-D: refers to Virtual Private LAN Services with BGP-based Auto Discovery as in [RFC6074]. PW: Pseudowire Sajassi et al. Expires May 27, 2019 [Page 5] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 I-SID: Ethernet Services Instance Identifier 2. Requirements Following are the key requirements for backward compatibility between (PBB-)EVPN and (PBB-)VPLS: 1. The solution MUST allow for staged migration towards (PBB-)EVPN on a site-by-site basis per VPN instance - e.g., new EVPN sites to be provisioned on (PBB-)EVPN Provider Edge devices (PEs). 2. The solution MUST require no changes to existing VPLS or PBB-VPLS PEs, not even a software upgrade. 3. The solution MUST allow for the coexistence of PEs running (PBB- )EVPN and (PBB-)VPLS for the same VPN instance and single-homed segments. 4. The solution MUST support single-active redundancy of multi-homed networks and multi-homed devices for (PBB-)EVPN PEs. 5. In case of single-active redundancy, the participant VPN instances MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as the MHD or MHN is connected to (PBB-)EVPN PEs. In case of an ES link failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to the EVPN peers OR MAC advertisement with MAC Mobility extended community for PBB-EVPN AND follow existing VPLS MAC Flush procedures with the VPLS peers. 6. The support of All-Active redundancy mode across both (PBB-)EVPN PEs and (PBB-)VPLS PEs is outside the scope of this document. These requirements collectively allow for the seamless insertion of the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments. 3 VPLS Integration with EVPN In order to support seamless integration with VPLS PEs, this document requires that VPLS PEs support VPLS A-D per [RFC6074] and EVPN PEs support both BGP EVPN routes per [RFC7432] and VPLS A-D per [RFC6074]. All the logic for seamless integration shall reside on the EVPN PEs. If a VPLS instance is setup without the use of VPLS A-D, it is still possible (but cumbersome) for EVPN PEs to integrate into that VPLS instance by manually configuring Pseudowires (PWs) to all the VPLS PEs in that instance (i.e., the integration is no longer seamless). Sajassi et al. Expires May 27, 2019 [Page 6] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 3.1 Capability Discovery The EVPN PEs MUST advertise both the BGP VPLS Auto-Discovery (A-D) route as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) route for a given VPN instance. The VPLS PEs only advertise the BGP VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762] and [RFC6074]. The operator may decide to use the same Route Target (RT) to identify a VPN on both EVPN and VPLS networks. In this case, when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the basis that it belongs to an unknown SAFI. However, the operator may choose to use two RTs - one to identify the VPN on VPLS network and another for EVPN network and employ RT-constrained [RFC4684] in order to prevent BGP EVPN routes from reaching the VPLS PEs. When an EVPN PE receives both a VPLS A-D route as well as an EVPN IMET route from a given remote PE for the same VPN instance, it MUST give preference to the EVPN route for the purpose of discovery. This ensures that, at the end of the route exchanges, all EVPN capable PEs discover other EVPN capable PEs in addition to the VPLS-only PEs for that VPN instance. Furthermore, all the VPLS-only PEs will discover the EVPN PEs as if they were standard VPLS PEs. In other words, when the discovery phase is complete, the EVPN PEs will have discovered all the PEs in the VPN instance along with their associated capability (EVPN or VPLS-only), whereas the VPLS PEs will have discovered all the PEs in the VPN instance as if they were all VPLS- only PEs. 3.2 Forwarding Setup and Unicast Operation The procedures for forwarding state setup and unicast operation on the VPLS PE are per [RFC8077], [RFC4761], [RFC4762]. The procedures for forwarding state setup and unicast operation on the EVPN PE are as follows: - The EVPN PE MUST establish a PW to each remote PE from which it has received only a VPLS A-D route for the corresponding VPN instance, and MUST set up the label stack corresponding to the PW FEC. For seamless integration between EVPN and VPLS PEs, the PW that is setup between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE and the MAC-VRF of the EVPN PE. - The EVPN PE must set up the label stack corresponding to the MP2P VPN unicast FEC to any remote PE that has advertised EVPN IMET route. - If an EVPN PE receives a VPLS A-D route from a given PE, it sets up a PW to that PE. If it then receives an EVPN IMET route from the same Sajassi et al. Expires May 27, 2019 [Page 7] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 PE, then the EVPN PE MUST bring that PW operationally down. - If an EVPN PE receives an EVPN IMET route followed by a VPLS A-D route from the same PE, then the EVPN PE will setup the PW but MUST keep it operationally down. - In case VPLS AD is not used in some VPLS PEs, the EVPN PEs need to be provisioned manually with PWs to those remote VPLS PEs for each VPN instance. In that case, if an EVPN PE receives an EVPN IMET route from a PE to which a PW exists, the EVPN PE MUST bring the PW operationally down. When the EVPN PE receives traffic over the VPLS PWs, it learns the associated C-MAC addresses in the data-plane. The C-MAC addresses learned over these PWs MUST be injected into the bridge table of the associated MAC-VRF on that EVPN PE. The learned C-MAC addresses MAY also be injected into the RIB/FIB tables of the associated MAC-VRF on that EVPN PE. For seamless integration between EVPN and VPLS PEs, since these PWs belong to the same split-horizon group as the MP2P EVPN service tunnels, then the C-MAC addresses learned and associated to the PWs MUST NOT be advertised in the control plane to any remote EVPN PEs. This is because every EVPN PE can send and receive traffic directly to/from every VPLS PE belonging to the same VPN instance. The C-MAC addresses learned over local Attachment Circuits (ACs) by an EVPN PE are learned in data-plane. For EVPN PEs, these C-MAC addresses MUST be injected into the corresponding MAC-VRF and advertised in the control-plane using BGP EVPN routes. Furthermore, the C-MAC addresses learned in the control plane via the BGP EVPN routes sent by remote EVPN PEs, are injected into the corresponding MAC-VRF table. 3.3 MAC Mobility In EVPN, host addresses (C-MAC addresses) can move around among EVPN PEs or even between EVPN and VPLS PEs. When a C-MAC address moves from an EVPN PE to a VPLS PE, then as soon as Broadcast/Unknown-unicast/Multicast (BUM) traffic is initiated from that MAC address, it is flooded to all other PEs (both VPLS and EVPN PEs) and the receiving PEs update their MAC tables (VSI or MAC- VRF). The EVPN PEs do not advertise the C-MAC addresses learned over the PW to each other because every EVPN PE learns them directly over its associated PW to that VPLS PE. If only known-unicast traffic is initiated from the moved C-MAC address toward a known C-MAC, then this can result in black-holing of traffic destined to the C-MAC that has moved until there is a BUM traffic originated with the moved C- MAC address as the source MAC address (e.g., as a result of MAC age- Sajassi et al. Expires May 27, 2019 [Page 8] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 out timer expires). Note that this is behavior typical of VPLS PEs. When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon as BUM or known-unicast traffic is initiated from that C-MAC address, the C-MAC is learned and advertised in BGP to other EVPN PEs and MAC mobility procedure is exercised among EVPN PEs. For BUM traffic, both EVPN and VPLS PEs learn the new location of the moved C-MAC address; however, if there is only known-unicast traffic, then only EVPN PEs learn the new location of the C-MAC that has moved but not VPLS PEs. This can result in black-holing of traffic sent from VPLS PEs destined to the C-MAC that has moved until there is a BUM traffic originated with the moved C-MAC address as the source MAC address (e.g., as a result of MAC age-out timer expires). Note that this is behavior typical of VPLS PEs. 3.4 Multicast Operation 3.4.1 Ingress Replication The procedures for multicast operation on the VPLS PE, using ingress replication, are per [RFC4761], [RFC4762], and [RFC7080]. The procedures for multicast operation on the EVPN PE, for ingress replication, are as follows: - The EVPN PE builds a replication sub-list to all the remote EVPN PEs per EVPN instance as the result of the exchange of the EVPN IMET routes per [RFC7432]. This will be referred to as sub-list A. It comprises MP2P service tunnels used for delivering EVPN BUM traffic [RFC7432]. - The EVPN PE builds a replication sub-list per VPLS instance to all the remote VPLS PEs. This will be referred to as sub-list B. It comprises PWs from the EVPN PE in question to all the remote VPLS PEs in the same VPLS instance. The replication list, maintained per VPN instance, on a given EVPN PE will be the union of sub-list A and sub-list B. Note that the PE must enable split-horizon over all the entries in the replication list, across both PWs and MP2P service tunnels. 3.4.2 P2MP Tunnel The procedures for multicast operation on the EVPN PEs using P2MP tunnels are outside of the scope of this document. Sajassi et al. Expires May 27, 2019 [Page 9] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 4 PBB-VPLS Integration with PBB-EVPN In order to support seamless integration between PBB-VPLS and PBB- EVPN PEs, this document requires that PBB-VPLS PEs support VPLS A-D per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this seamless integration shall reside on the PBB-EVPN PEs. 4.1 Capability Discovery The procedures for capability discovery are per Section 3.1 above. 4.2 Forwarding Setup and Unicast Operation The procedures for forwarding state setup and unicast operation on the PBB-VPLS PE are per [RFC8077] and [RFC7080]. The procedures for forwarding state setup and unicast operation on the PBB-EVPN PE are as follows: - The PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE from which it has received only a VPLS A-D route for the corresponding VPN instance, and MUST set up the label stack corresponding to the PW FEC. For seamless integration between PBB-EVPN and PBB-VPLS PEs, the PW that is setup between a pair of PBB-VPLS and PBB-EVPN PEs, is between B-components of PBB-EVPN PE and PBB-VPLS PE per section 4 of [RFC7041]. - The PBB-EVPN PE must set up the label stack corresponding to the MP2P VPN unicast FEC to any remote PBB-EVPN PE that has advertised EVPN IMET route. - If a PBB-EVPN PE receives a VPLS A-D route from a given PE, it sets up a PW to that PE. If it then receives an EVPN IMET route from the same PE, then the PBB-EVPN PE MUST bring that PW operationally down. - If a PBB-EVPN PE receives an EVPN IMET route followed by a VPLS A-D route from the same PE, then the PBB-EVPN PE will setup the PW but MUST keep it operationally down. - In case VPLS AD is not used in some PBB-VPLS PEs, the PBB-EVPN PEs need to be provisioned manually with PWs to those remote PBB-VPLS PEs for each VPN instance. In that case, if a PBB-EVPN PE receives an EVPN IMET route from a PE to which a PW exists, the PBB-EVPN PE MUST bring the PW operationally down. - When the PBB-EVPN PE receives traffic over the PBB-VPLS PWs, it learns the associated B-MAC addresses in the data-plane. The B-MAC Sajassi et al. Expires May 27, 2019 [Page 10] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 addresses learned over these PWs MUST be injected into the bridge table of the associated MAC-VRF on that PBB-EVPN PE. The learned B- MAC addresses MAY also be injected into the RIB/FIB tables of the associated the MAC-VRF on that BPP-EVPN PE. For seamless integration between PBB-EVPN and PBB-VPLS PEs, since these PWs belongs to the same split-horizon group as the MP2P EVPN service tunnels, then the B-MAC addresses learned and associated to the PWs MUST NOT be advertised in the control plane to any remote PBB-EVPN PEs. This is because every PBB-EVPN PE can send and receive traffic directly to/from every PBB-VPLS PE belonging to the same VPN instance. - The C-MAC addresses learned over local Attachment Circuits (ACs) by an PBB-EVPN PE are learned in data-plane. For PBB-EVPN PEs, these C- MAC addresses are learned in I-component of PBB-EVPN PEs and they are not advertised in the control-plane per [RFC7623]. - The B-MAC addresses learned in the control plane via the BGP EVPN routes sent by remote PBB-EVPN PEs, are injected into the corresponding MAC-VRF table. 4.3 MAC Mobility In PBB-EVPN, a given B-MAC address can be learnt either over the BGP control-plane from a remote PBB-EVPN PE, or in the data-plane over a PW from a remote PBB-VPLS PE. There is no mobility associated with B- MAC addresses in this context. Hence, when the same B-MAC address shows up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE, the local PE can deduce that it is an anomaly and SHOULD notify the operator. 4.4 Multicast Operation 4.4.1 Ingress Replication The procedures for multicast operation on the PBB-VPLS PE, using ingress replication, are per [RFC7041] and [RFC7080]. The procedures for multicast operation on the PBB-EVPN PE, for ingress replication, are as follows: - The PBB-EVPN PE builds a replication sub-list per I-SID to all the remote PBB-EVPN PEs in a given VPN instance as a result of the exchange of the EVPN IMET routes, as described in [RFC7623]. This will be referred to as sub-list A. It comprises MP2P service tunnels used for delivering PBB-EVPN BUM traffic. - The PBB-EVPN PE builds a replication sub-list per VPN instance to Sajassi et al. Expires May 27, 2019 [Page 11] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 all the remote PBB-VPLS PEs. This will be referred to as sub-list B. It comprises PWs from the PBB-EVPN PE in question to all the remote PBB-VPLS PEs in the same VPN instance. - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis, by running [MMRP] over the PBB-VPLS network. This will be referred to as sub-list C. This list comprises a pruned set of the PWs in the sub-list B. The replication list maintained per I-SID on a given PBB-EVPN PE will be the union of sub-list A and sub-list B if [MMRP] is not used, and the union of sub-list A and sub-list C if [MMRP] is used. Note that the PE must enable split-horizon over all the entries in the replication list, across both pseudowires and MP2P service tunnels. 4.4.2 P2MP Tunnel - Inclusive Tree The procedures for multicast operation on the PBB-EVPN PEs using P2MP tunnels are outside of the scope of this document. 5 Security Considerations All the security considerations in [RFC4761], [RFC4762], [RFC7080], [RFC7432], and [RFC7623] apply directly to this document because this document leverages the control plane and the data plane procedures described in these RFCs. This document does not introduce any new security considerations beyond that of the above RFCs because the advertisements and processing of MAC addresses in BGP follow that of [RFC7432] and processing of MAC addresses learned over PWs follow that of [RFC4761], [RFC4762], and [RFC7080]. 6 IANA Considerations This document has no actions for IANA. 7 References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8077] Martini, et al., "Pseudowire Setup and Maintenance using the Label Distribution Protocol", RFC 8077, February 2017. [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, February, 2015. [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015. [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007, . [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, . [RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. 7.2 Informative References [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2013. [RFC7041] Balus et al., "Extensions to VPLS PE model for Provider Backbone Bridging", RFC 7041, November 2013. [RFC7080] Sajassi et al., "VPLS Interoperability with Provider Backbone Bridges", RFC 7080, December, 2013. [IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146. Sajassi et al. Expires May 27, 2019 [Page 13] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ Nov 27, 2019 [RFC4684] Marques et al., "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November, 2006. Authors' Addresses Ali Sajassi Cisco Email: sajassi@cisco.com Samer Salam Cisco Email: ssalam@cisco.com Nick Del Regno Verizon Email: nick.delregno@verizon.com Jorge Rabadan Nokia Email: jorge.rabadan@nokia.com Sajassi et al. Expires May 27, 2019 [Page 14] From nobody Thu Dec 13 14:09:28 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A6A130EAB; Thu, 13 Dec 2018 14:09:20 -0800 (PST) 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=consulintel.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 5_UocSz880fb; Thu, 13 Dec 2018 14:09:18 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E740F130EA9; Thu, 13 Dec 2018 14:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1544738953; x=1545343753; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=wr+XANuANecS0GYlO+Omfz5q8NiilK8Ke9B377eVZYs=; b=OxFrD8td9bD3R l9CtefcdORS9X8pStsNMOf0y8zQV+CK2PnsOEJd6hCUiA0C8FKy5Odh7IKcwz3vF vRmWpjXOh4hBJdPe0Jn1OR5e/65vw5cn7dkfJ+dCRBShBShkAQs/93R/EmDdn18T gRH6kchQsb3BzE8OxrhUZ32Dh/WhHg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 13 Dec 2018 23:09:13 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 13 Dec 2018 23:09:12 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006063193.msg; Thu, 13 Dec 2018 23:09:12 +0100 X-MDRemoteIP: 2001:470:1f09:495:a811:1373:c444:4be5 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 13 Dec 2018 23:09:12 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1885a872f7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 13 Dec 2018 23:09:09 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , CC: , , Message-ID: <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> In-Reply-To: <154473417654.32125.9104927217788947044@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 22:09:21 -0000 Hi Christian, Thanks a lot for your review. Please see below in-line. I'm working in a new version according to the comments got from the ops rev= iew as well, so will be able to integrate yours very quickly. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Christian Huitema Fecha: jueves, 13 de diciembre de 2018, 21:50 Para: CC: , , Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4= aas-11 Reviewer: Christian Huitema Review result: Has Issues =20 I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG ch= airs should treat these comments just like any other last call comments. =20 The summary of the review is "ready with issue". =20 The document describes solution for providing "IPv4 as a service", i.e. provision of IPv4 as a service over an IPv6 only network. It calls this support "transition as a service". =20 For various reasons, IETF working groups have standardized not just one= but five different mechanisms for providing this transition: 464XLAT [RFC68= 77], Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python coul= d have produced a nice sketch about that.) The purpose of the draft is to state how home routers (a.k.a. customer premise equipment, CPE) should inform local devices about which of the mechanisms are available, which should be preferred, and what parameters should be used when deploying the chosen services. This is done using the DHCPv6 "S46" option specified in RFC 8026. =20 The draft also makes specific recommendation regarding the use of the U= PnP and PCP services, by requiring specific error codes when a requested port m= apping=20 is not available through the specified transition technology. =20 The security section briefly points to the "Basic Requirements for IPv6 Customer Edge Routers" specified in RFC 7084, and to the security section of each of the RFC describing the security technologies, and im= plicitly argues that there are no other security issues. I think that is insuffi= cient. =20 The draft introduces a reliance on the DHCPv6 "S46" option for assessin= g the relative priority of different transition technologies. An attacker cou= ld spoof the DHCPv6 response, and direct client traffic to a different technolog= y than selected by the service provider. This could be used, for example, to c= apture IPv4 traffic in an IPv6 network and send it to a route chosen by the at= tacker. The attack might also be used in a dual stack network that does not sup= port any transition technology. I don't understand how this attack is mitiga= ted. Not sure if you will suggest here that we should say something about the se= curity considerations already mention in RFC8026. In general all those are = generic DHCPv6 security considerations I think. =20 Nits: =20 The introduction uses the acronym WAN without spelling out "Wide Area N= etwork".=20 Also, WAN is used as substitute for local Internet Service Provider net= work. We could debate whether such networks are always "wide area", by opposition to s= ay "metropolitan" or "regional". This is the same convention used in RFC 7= 084 that this document updates. It is arguably defined by reference, but spellin= g it out would be nice. =20 Will do. =20 The comparison with RFC7084 section includes a mangled sentence:=20 =20 This document doesn't include support for 6rd ([RFC5969]), because a= s in an IPv6-in-IPv4 tunneling. Typo, sorry the correct sentence was: This document doesn't include support for 6rd ([RFC5969]), because i= s an IPv6-in-IPv4 tunneling. =20 Please rephrase. Please also rephrase the next sentence, for similar re= asons: =20 Regarding DS-LITE [RFC6333], this document includes slightly different requirements, because the PCP ([RFC6887]) support and the prioritization of the transition mechanisms, including dual-stack. I think it is much clear this way: Regarding DS-LITE [RFC6333], this document includes slightly different requirements, related to the support of PCP ([RFC6887]), IGD-PCP IWF [RFC6970] and the prioritization of the transition=20 mechanisms, including dual-stack. =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Dec 13 18:11:45 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A994A130F66; Thu, 13 Dec 2018 18:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OpbTn4Lfz50L; Thu, 13 Dec 2018 18:11:37 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CD626130F5C; Thu, 13 Dec 2018 18:11:36 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D7DE2CB0F96AA; Fri, 14 Dec 2018 02:11:32 +0000 (GMT) Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 14 Dec 2018 02:11:33 +0000 Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 14 Dec 2018 02:11:33 +0000 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Fri, 14 Dec 2018 02:11:33 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.202]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0415.000; Fri, 14 Dec 2018 10:11:22 +0800 From: Mach Chen To: Linda Dunbar , "secdir@ietf.org" CC: "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 Thread-Index: AQHUkY+Xr7eIQ7lWe0az4uRG6fBCdqV9d+Sw Date: Fri, 14 Dec 2018 02:11:21 +0000 Message-ID: References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> In-Reply-To: <154455986336.13151.8483284555885294015@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 02:11:39 -0000 SGkgTGluZGEsDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldyENCg0KU29tZSByZXNwb25zZXMgaW5s aW5lLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWV0ZiBbbWFp bHRvOmlldGYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpbmRhIER1bmJhcg0KPiBT ZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDEyLCAyMDE4IDQ6MjQgQU0NCj4gVG86IHNlY2RpckBp ZXRmLm9yZw0KPiBDYzogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxh Zy1tdWx0aXBhdGguYWxsQGlldGYub3JnOw0KPiBpZXRmQGlldGYub3JnDQo+IFN1YmplY3Q6IFNl Y2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVs dGlwYXRoLTA1DQo+IA0KPiBSZXZpZXdlcjogTGluZGEgRHVuYmFyDQo+IFJldmlldyByZXN1bHQ6 IFJlYWR5DQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRo ZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCj4gZWZmb3J0IHRvIHJldmlldyBhbGwg SUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UNCj4gY29t bWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3Vy aXR5IGFyZWENCj4gZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNo b3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cw0KPiBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2Fs bCBjb21tZW50cy4NCj4gDQo+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgUmVhZHkgd2l0 aCBjb21tZW50DQo+IA0KPiBUaGUgZGVzY3JpYmVkIG1lY2hhbmlzbSBmb3IgTFNQIE11bHRpcGF0 aCBQaW5nIGlzIHZlcnkgY2xlYXIuIFRoZSBTZWN1cml0eQ0KPiBDb25zaWRlcmF0aW9uIHJlLXVz ZXMgdGhlIGRlc2NyaXB0aW9uIG9mIFJGQzgwMjksIHdoaWNoIGlzIHZlcnkNCj4gY29tcHJlaGVu c2l2ZS4NCj4gSXQgd291bGQgYmUgYmV0dGVyIGlmIHRoZSBkcmFmdCBkZXNjcmliZXMgaG93IHRv IHByZXZlbnQgaW50ZXJtZWRpYXRlIExTUnMgaW4NCj4gYmV0d2VlbiB0aGUgSW5pdGlhdGluZyBM U1IgYW5kIFJlc3BvbmRpbmcgTFNSIGZyb20gbWlzLXVzaW5nIHRoZSBkZXRhaWxlZA0KPiBsaW5r IGluZm9ybWF0aW9uIChlLmcuIGZvcndhcmRpbmcgdG8gc29tZXdoZXJlIGVsc2UpLg0KDQpUaGUg RWNobyBSZXF1ZXN0IGFuZCBSZXBseSBtZXNzYWdlcyBhcmUgZGlyZWN0bHkgZXhjaGFuZ2VkIGJl dHdlZW4gdGhlIEluaXRpYXRpbmcgTFNSIGFuZCB0aGUgUmVzcG9uZGluZyBMU1IsIHRob3NlIGlu dGVybWVkaWF0ZSBMU1JzIGp1c3QgZm9yd2FyZCB0aGUgbWVzc2FnZXMgYXMgbm9ybWFsIHBhY2tl dHMsIHRoZXkgd2lsbCBub3Qgc2VlIHRoZSBkZXRhaWxlZCBsaW5rIGluZm9ybWF0aW9uIHVubGVz cyBpZiB0aGV5IGluc3BlY3QgYW5kIGRvIERQSSBvbiBldmVyeSBwYWNrZXQgZm9yd2FyZGVkIGJ5 IHRoZW0uIA0KDQpUaGUgZGV0YWlsZWQgbGluayBpbmZvcm1hdGlvbiBpcyBzdXBwbGllZCB0byB0 aGUgSW5pdGlhdGluZyBMU1IgZm9yIHVzaW5nLCB0aGUgaW50ZXJtZWRpYXRlIExTUnMgd2lsbCBu b3QgdHJ5IHRvIHVzZSBpdCBldmVuIGlmIHRoZXkgcmVjZWl2ZWQgdGhlIGluZm9ybWF0aW9uLCBi ZWNhdXNlIHRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgRWNobyBSZXF1ZXN0IHRvIHRoZSByZWNl aXZlZCBFY2hvIFJlcGx5LiAgDQoNCg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQo+IA0KPiBCZXN0 IFJlZ2FyZHMsDQo+IExpbmRhIER1bmJhcg0KPiANCg0K From nobody Thu Dec 13 23:26:21 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4A81310C1 for ; Thu, 13 Dec 2018 23:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 09zOw0mP-RWY for ; Thu, 13 Dec 2018 23:26:17 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 9EA6012426A for ; Thu, 13 Dec 2018 23:26:16 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx64.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1gXhrP-00085a-VV for secdir@ietf.org; Fri, 14 Dec 2018 08:26:14 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gXhrJ-00070a-JL for secdir@ietf.org; Fri, 14 Dec 2018 02:26:09 -0500 Received: (qmail 18090 invoked from network); 14 Dec 2018 07:26:03 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Dec 2018 07:26:03 -0000 To: JORDI PALET MARTINEZ , secdir@ietf.org Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> Date: Thu, 13 Dec 2018 23:26:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 168.144.250.177 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5hqkWmZN4WN3xEFt7tF6zcJ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQSJSiUrjE2y3emWnnlIhaOz4yz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1tT1jo78dYYOFDoRbOcZwPqXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsexSViPrG1zvXxpHVfvosE48pPeKgSNrMz1anClngGiZAW7OOBBQs/zm seXdStJ7lMtqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+TVTl5gcG/32KMUxSPuiSviDg5/bq7ChmPMN Ycw1QSmRbO1iRAyEYdfHnv07DAgS52tRW7HSa1Jfe0fEhfWOYSFm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhioLN/2B1AP3wljqUewcuNVa+NTKQHNkjJg8xvPcdYB8Xty99UBiAdSw7PLl+ PSS/1v27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 07:26:20 -0000 On 12/13/2018 2:09 PM, JORDI PALET MARTINEZ wrote: > Hi Christian, > > Thanks a lot for your review. > > Please see below in-line. > > I'm working in a new version according to the comments got from the ops review as well, so will be able to integrate yours very quickly. > > Regards, > Jordi > > > > -----Mensaje original----- > De: v6ops en nombre de Christian Huitema > Fecha: jueves, 13 de diciembre de 2018, 21:50 > Para: > CC: , , > Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 > > Reviewer: Christian Huitema > Review result: Has Issues > > I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily for > the benefit of the security area directors. Document editors and WG chairs > should treat these comments just like any other last call comments. > > The summary of the review is "ready with issue". > > The document describes solution for providing "IPv4 as a service", i.e. > provision of IPv4 as a service over an IPv6 only network. > It calls this support "transition as a service". > > For various reasons, IETF working groups have standardized not just one but > five different mechanisms for providing this transition: 464XLAT [RFC6877], > Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], > MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python could have > produced a nice sketch about that.) The purpose of the draft is to > state how home routers (a.k.a. customer premise equipment, CPE) should > inform local devices about which of the mechanisms are available, which > should be preferred, and what parameters should be used when deploying > the chosen services. This is done using the DHCPv6 "S46" option > specified in RFC 8026. > > The draft also makes specific recommendation regarding the use of the UPnP and > PCP services, by requiring specific error codes when a requested port mapping > is not available through the specified transition technology. > > The security section briefly points to the "Basic Requirements for IPv6 > Customer Edge Routers" specified in RFC 7084, and to the security > section of each of the RFC describing the security technologies, and implicitly > argues that there are no other security issues. I think that is insufficient. > > The draft introduces a reliance on the DHCPv6 "S46" option for assessing the > relative priority of different transition technologies. An attacker could spoof > the DHCPv6 response, and direct client traffic to a different technology than > selected by the service provider. This could be used, for example, to capture > IPv4 traffic in an IPv6 network and send it to a route chosen by the attacker. > The attack might also be used in a dual stack network that does not support > any transition technology. I don't understand how this attack is mitigated. > > Not sure if you will suggest here that we should say something about the security considerations already mention in RFC8026. In general all those are generic DHCPv6 security considerations I think. Basically, the devices should be programmed to ignore DHCPv6 if they have another more secure way of getting their configuration data. Plus, apply general defense against DHCPv6 hacks in the network, etc. I understand that your draft is meant to inform the building of CPEs, but its effect is generalization of an unsafe mechanism. > > Nits: > > The introduction uses the acronym WAN without spelling out "Wide Area Network". > Also, WAN is used as substitute for local Internet Service Provider network. We could > debate whether such networks are always "wide area", by opposition to say > "metropolitan" or "regional". This is the same convention used in RFC 7084 that > this document updates. It is arguably defined by reference, but spelling it out > would be nice. > > Will do. > > > The comparison with RFC7084 section includes a mangled sentence: > > This document doesn't include support for 6rd ([RFC5969]), because as > in an IPv6-in-IPv4 tunneling. > > Typo, sorry the correct sentence was: > This document doesn't include support for 6rd ([RFC5969]), because is > an IPv6-in-IPv4 tunneling. This document doesn't include support for 6rd ([RFC5969]), because it is an IPv6-in-IPv4 tunneling. > > Please rephrase. Please also rephrase the next sentence, for similar reasons: > > Regarding DS-LITE [RFC6333], this document includes slightly > different requirements, because the PCP ([RFC6887]) support and the > prioritization of the transition mechanisms, including dual-stack. > > I think it is much clear this way: > > Regarding DS-LITE [RFC6333], this document includes slightly > different requirements, related to the support of PCP ([RFC6887]), > IGD-PCP IWF [RFC6970] and the prioritization of the transition > mechanisms, including dual-stack. OK. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > From nobody Thu Dec 13 23:32:46 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C025126C01; Thu, 13 Dec 2018 23:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.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 2xX7uASxIQe8; Thu, 13 Dec 2018 23:32:41 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981371310C2; Thu, 13 Dec 2018 23:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1544772758; x=1545377558; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=bjwZVhty+r7g8955qMvA+mk6BWbmAPRnXQt0vOI5ikY=; b=VoptqCqfnPep6 EJxrmuXvNDrLG3dbM0Rinq80or8rGlxbbIxXmc24onG4XOPvaR981hgJqn6G3iGr 3gRq9KNMOod54Z1v26UboqvgNCh/jPjNZXB1UClaPv4W5P/8g0m5Qm8f0ipJaZd/ Gua+bxv4khrQFxrzftWzSOWyuWGK+M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 14 Dec 2018 08:32:38 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 14 Dec 2018 08:32:38 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006064428.msg; Fri, 14 Dec 2018 08:32:36 +0100 X-MDRemoteIP: 2001:470:1f09:495:2d51:35fd:4fd9:8498 X-MDHelo: [10.10.10.99] X-MDArrival-Date: Fri, 14 Dec 2018 08:32:36 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=18861ebfab=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Fri, 14 Dec 2018 08:32:35 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , CC: , , Message-ID: Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> In-Reply-To: <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 07:32:44 -0000 Regarding the DHCPv6 unsafety ... The problem I see is that your recommenda= tion will be against the use of DHCPv6 in a generic way. This is a much broader problem that our document, so out of scope of this d= ocument itself ! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de Christian Huitema Fecha: viernes, 14 de diciembre de 2018, 8:26 Para: JORDI PALET MARTINEZ , CC: , , Asunto: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-= ipv4aas-11 =20 On 12/13/2018 2:09 PM, JORDI PALET MARTINEZ wrote: > Hi Christian, > > Thanks a lot for your review. > > Please see below in-line. > > I'm working in a new version according to the comments got from the o= ps review as well, so will be able to integrate yours very quickly. > > Regards, > Jordi > =20 > =20 > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Christian Huitema > Fecha: jueves, 13 de diciembre de 2018, 21:50 > Para: > CC: , , > Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transitio= n-ipv4aas-11 > > Reviewer: Christian Huitema > Review result: Has Issues > =20 > I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of= the > security directorate's ongoing effort to review all IETF document= s > being processed by the IESG. These comments were written primari= ly for > the benefit of the security area directors. Document editors and= WG chairs > should treat these comments just like any other last call comment= s. > =20 > The summary of the review is "ready with issue". > =20 > The document describes solution for providing "IPv4 as a service"= , i.e. > provision of IPv4 as a service over an IPv6 only network. > It calls this support "transition as a service". > =20 > For various reasons, IETF working groups have standardized not ju= st one but > five different mechanisms for providing this transition: 464XLAT = [RFC6877], > Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], > MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Pytho= n could have > produced a nice sketch about that.) The purpose of the draft is t= o > state how home routers (a.k.a. customer premise equipment, CPE) s= hould > inform local devices about which of the mechanisms are available,= which > should be preferred, and what parameters should be used when depl= oying > the chosen services. This is done using the DHCPv6 "S46" option > specified in RFC 8026. > =20 > The draft also makes specific recommendation regarding the use of= the UPnP and > PCP services, by requiring specific error codes when a requested = port mapping=20 > is not available through the specified transition technology. > =20 > The security section briefly points to the "Basic Requirements fo= r IPv6 > Customer Edge Routers" specified in RFC 7084, and to the security > section of each of the RFC describing the security technologies, = and implicitly > argues that there are no other security issues. I think that is i= nsufficient. > =20 > The draft introduces a reliance on the DHCPv6 "S46" option for as= sessing the > relative priority of different transition technologies. An attack= er could spoof > the DHCPv6 response, and direct client traffic to a different tec= hnology than > selected by the service provider. This could be used, for example= , to capture > IPv4 traffic in an IPv6 network and send it to a route chosen by = the attacker. > The attack might also be used in a dual stack network that does n= ot support > any transition technology. I don't understand how this attack is = mitigated. > > Not sure if you will suggest here that we should say something about = the security considerations already mention in RFC8026. In general all thos= e are generic DHCPv6 security considerations I think. =20 Basically, the devices should be programmed to ignore DHCPv6 if they have another more secure way of getting their configuration data. Plus, apply general defense against DHCPv6 hacks in the network, etc. I understand that your draft is meant to inform the building of CPEs, but its effect is generalization of an unsafe mechanism. =20 =20 > =20 > Nits: > =20 > The introduction uses the acronym WAN without spelling out "Wide = Area Network".=20 > Also, WAN is used as substitute for local Internet Service Provid= er network. We could > debate whether such networks are always "wide area", by oppositio= n to say > "metropolitan" or "regional". This is the same convention used in= RFC 7084 that > this document updates. It is arguably defined by reference, but s= pelling it out > would be nice. > =20 > Will do. > > =20 > The comparison with RFC7084 section includes a mangled sentence:= =20 > =20 > This document doesn't include support for 6rd ([RFC5969]), bec= ause as > in an IPv6-in-IPv4 tunneling. > > Typo, sorry the correct sentence was: > This document doesn't include support for 6rd ([RFC5969]), bec= ause is > an IPv6-in-IPv4 tunneling. =20 This document doesn't include support for 6rd ([RFC5969]), becau= se it is an IPv6-in-IPv4 tunneling. =20 > =20 > Please rephrase. Please also rephrase the next sentence, for simi= lar reasons: > =20 > Regarding DS-LITE [RFC6333], this document includes slightly > different requirements, because the PCP ([RFC6887]) support an= d the > prioritization of the transition mechanisms, including dual-st= ack. > > I think it is much clear this way: > > Regarding DS-LITE [RFC6333], this document includes slightly > different requirements, related to the support of PCP ([RFC688= 7]), > IGD-PCP IWF [RFC6970] and the prioritization of the transition= =20 > mechanisms, including dual-stack. =20 =20 OK. =20 =20 > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Dec 13 23:44:40 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B74E1310CC; Thu, 13 Dec 2018 23:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RGBPB-8Tak34; Thu, 13 Dec 2018 23:44:30 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95A21310C2; Thu, 13 Dec 2018 23:44:29 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 43GMy41f3wz8tbS; Fri, 14 Dec 2018 08:44:28 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 43GMy40jd2z5vNC; Fri, 14 Dec 2018 08:44:28 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0415.000; Fri, 14 Dec 2018 08:44:27 +0100 From: To: Christian Huitema , JORDI PALET MARTINEZ , "secdir@ietf.org" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 Thread-Index: AQHUk35gwIitBLjfoEqKymi2z0/HLKV92cbw Date: Fri, 14 Dec 2018 07:44:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E059014@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> In-Reply-To: <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 07:44:33 -0000 Q2hyaXN0aWFuLA0KDQpBcyBtZW50aW9uZWQgYnkgSm9yZGksIFJGQzgwMjYgYWxyZWFkeSBkZXNj cmliZXMgdGhlIGF0dGFjayB2ZWN0b3IgeW91IG1lbnRpb25lZC4gDQoNCldvdWxkbid0IHBvaW50 aW5nIHRvIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDE1I3NlY3Rpb24tMjIgYmUg c3VmZmljaWVudCBoZXJlPyANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+IERlwqA6IGlldGYgW21haWx0bzppZXRmLWJvdW5jZXNAaWV0Zi5vcmddIERl IGxhIHBhcnQgZGUgQ2hyaXN0aWFuIEh1aXRlbWENCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxNCBk w6ljZW1icmUgMjAxOCAwODoyNg0KPiDDgMKgOiBKT1JESSBQQUxFVCBNQVJUSU5FWjsgc2VjZGly QGlldGYub3JnDQo+IENjwqA6IHY2b3BzQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1p ZXRmLXY2b3BzLXRyYW5zaXRpb24tDQo+IGlwdjRhYXMuYWxsQGlldGYub3JnDQo+IE9iamV0wqA6 IFJlOiBbdjZvcHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdjZvcHMt dHJhbnNpdGlvbi0NCj4gaXB2NGFhcy0xMQ0KPiANCj4gDQo+IE9uIDEyLzEzLzIwMTggMjowOSBQ TSwgSk9SREkgUEFMRVQgTUFSVElORVogd3JvdGU6DQo+ID4gSGkgQ2hyaXN0aWFuLA0KPiA+DQo+ ID4gVGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldy4NCj4gPg0KPiA+IFBsZWFzZSBzZWUgYmVs b3cgaW4tbGluZS4NCj4gPg0KPiA+IEknbSB3b3JraW5nIGluIGEgbmV3IHZlcnNpb24gYWNjb3Jk aW5nIHRvIHRoZSBjb21tZW50cyBnb3QgZnJvbSB0aGUgb3BzDQo+IHJldmlldyBhcyB3ZWxsLCBz byB3aWxsIGJlIGFibGUgdG8gaW50ZWdyYXRlIHlvdXJzIHZlcnkgcXVpY2tseS4NCj4gPg0KPiA+ IFJlZ2FyZHMsDQo+ID4gSm9yZGkNCj4gPg0KPiA+DQo+ID4NCj4gPiDvu78tLS0tLU1lbnNhamUg b3JpZ2luYWwtLS0tLQ0KPiA+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4g bm9tYnJlIGRlIENocmlzdGlhbiBIdWl0ZW1hDQo+IDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KPiA+ IEZlY2hhOiBqdWV2ZXMsIDEzIGRlIGRpY2llbWJyZSBkZSAyMDE4LCAyMTo1MA0KPiA+IFBhcmE6 IDxzZWNkaXJAaWV0Zi5vcmc+DQo+ID4gQ0M6IDx2Nm9wc0BpZXRmLm9yZz4sIDxpZXRmQGlldGYu b3JnPiwgPGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gaXB2NGFhcy5hbGxAaWV0Zi5v cmc+DQo+ID4gQXN1bnRvOiBbdjZvcHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gaXB2NGFhcy0xMQ0KPiA+DQo+ID4gICAgIFJldmll d2VyOiBDaHJpc3RpYW4gSHVpdGVtYQ0KPiA+ICAgICBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVz DQo+ID4NCj4gPiAgICAgSSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlv bi1pcHY0YWFzLTExIGFzIHBhcnQgb2YgdGhlDQo+ID4gICAgIHNlY3VyaXR5IGRpcmVjdG9yYXRl J3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cw0KPiA+ICAgICBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvcg0KPiA+ICAgICB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBk aXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRw0KPiBjaGFpcnMNCj4gPiAgICAgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KPiA+DQo+ID4gICAgIFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgInJlYWR5 IHdpdGggaXNzdWUiLg0KPiA+DQo+ID4gICAgIFRoZSBkb2N1bWVudCBkZXNjcmliZXMgc29sdXRp b24gZm9yIHByb3ZpZGluZyAiSVB2NCBhcyBhIHNlcnZpY2UiLCBpLmUuDQo+ID4gICAgIHByb3Zp c2lvbiBvZiBJUHY0IGFzIGEgc2VydmljZSBvdmVyIGFuIElQdjYgb25seSBuZXR3b3JrLg0KPiA+ ICAgICBJdCBjYWxscyB0aGlzIHN1cHBvcnQgInRyYW5zaXRpb24gYXMgYSBzZXJ2aWNlIi4NCj4g Pg0KPiA+ICAgICBGb3IgdmFyaW91cyByZWFzb25zLCBJRVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUg c3RhbmRhcmRpemVkIG5vdCBqdXN0IG9uZQ0KPiBidXQNCj4gPiAgICAgZml2ZSBkaWZmZXJlbnQg bWVjaGFuaXNtcyBmb3IgcHJvdmlkaW5nIHRoaXMgdHJhbnNpdGlvbjogNDY0WExBVA0KPiBbUkZD Njg3N10sDQo+ID4gICAgIER1YWwtU3RhY2sgTGl0ZSBbUkZDNjMzM10sIExpZ2h0d2VpZ2h0IDRv dmVyNiAobHc0bzYpIFtSRkM3NTk2XSwNCj4gPiAgICAgTUFQLUUgW1JGQzc1OTddLCBhbmQgTUFQ LVQgW1JGQzc1OTldLiAoSSBhbSBzdXJlIHRoYXQgTW9udHkgUHl0aG9uDQo+IGNvdWxkIGhhdmUN Cj4gPiAgICAgcHJvZHVjZWQgYSBuaWNlIHNrZXRjaCBhYm91dCB0aGF0LikgVGhlIHB1cnBvc2Ug b2YgdGhlIGRyYWZ0IGlzIHRvDQo+ID4gICAgIHN0YXRlIGhvdyBob21lIHJvdXRlcnMgKGEuay5h LiBjdXN0b21lciBwcmVtaXNlIGVxdWlwbWVudCwgQ1BFKSBzaG91bGQNCj4gPiAgICAgaW5mb3Jt IGxvY2FsIGRldmljZXMgYWJvdXQgd2hpY2ggb2YgdGhlIG1lY2hhbmlzbXMgYXJlIGF2YWlsYWJs ZSwgd2hpY2gNCj4gPiAgICAgc2hvdWxkIGJlIHByZWZlcnJlZCwgYW5kIHdoYXQgcGFyYW1ldGVy cyBzaG91bGQgYmUgdXNlZCB3aGVuIGRlcGxveWluZw0KPiA+ICAgICB0aGUgY2hvc2VuIHNlcnZp Y2VzLiBUaGlzIGlzIGRvbmUgdXNpbmcgdGhlIERIQ1B2NiAiUzQ2IiBvcHRpb24NCj4gPiAgICAg c3BlY2lmaWVkIGluIFJGQyA4MDI2Lg0KPiA+DQo+ID4gICAgIFRoZSBkcmFmdCBhbHNvIG1ha2Vz IHNwZWNpZmljIHJlY29tbWVuZGF0aW9uIHJlZ2FyZGluZyB0aGUgdXNlIG9mIHRoZQ0KPiBVUG5Q IGFuZA0KPiA+ICAgICBQQ1Agc2VydmljZXMsIGJ5IHJlcXVpcmluZyBzcGVjaWZpYyBlcnJvciBj b2RlcyB3aGVuIGEgcmVxdWVzdGVkIHBvcnQNCj4gbWFwcGluZw0KPiA+ICAgICBpcyBub3QgYXZh aWxhYmxlIHRocm91Z2ggdGhlIHNwZWNpZmllZCB0cmFuc2l0aW9uIHRlY2hub2xvZ3kuDQo+ID4N Cj4gPiAgICAgVGhlIHNlY3VyaXR5IHNlY3Rpb24gYnJpZWZseSBwb2ludHMgdG8gdGhlICJCYXNp YyBSZXF1aXJlbWVudHMgZm9yIElQdjYNCj4gPiAgICAgQ3VzdG9tZXIgRWRnZSBSb3V0ZXJzIiBz cGVjaWZpZWQgaW4gUkZDIDcwODQsIGFuZCB0byB0aGUgc2VjdXJpdHkNCj4gPiAgICAgc2VjdGlv biBvZiBlYWNoIG9mIHRoZSBSRkMgZGVzY3JpYmluZyB0aGUgc2VjdXJpdHkgdGVjaG5vbG9naWVz LCBhbmQNCj4gaW1wbGljaXRseQ0KPiA+ICAgICBhcmd1ZXMgdGhhdCB0aGVyZSBhcmUgbm8gb3Ro ZXIgc2VjdXJpdHkgaXNzdWVzLiBJIHRoaW5rIHRoYXQgaXMNCj4gaW5zdWZmaWNpZW50Lg0KPiA+ DQo+ID4gICAgIFRoZSBkcmFmdCBpbnRyb2R1Y2VzIGEgcmVsaWFuY2Ugb24gdGhlIERIQ1B2NiAi UzQ2IiBvcHRpb24gZm9yDQo+IGFzc2Vzc2luZyB0aGUNCj4gPiAgICAgcmVsYXRpdmUgcHJpb3Jp dHkgb2YgZGlmZmVyZW50IHRyYW5zaXRpb24gdGVjaG5vbG9naWVzLiBBbiBhdHRhY2tlcg0KPiBj b3VsZCBzcG9vZg0KPiA+ICAgICB0aGUgREhDUHY2IHJlc3BvbnNlLCBhbmQgZGlyZWN0IGNsaWVu dCB0cmFmZmljIHRvIGEgZGlmZmVyZW50DQo+IHRlY2hub2xvZ3kgdGhhbg0KPiA+ICAgICBzZWxl Y3RlZCBieSB0aGUgc2VydmljZSBwcm92aWRlci4gVGhpcyBjb3VsZCBiZSB1c2VkLCBmb3IgZXhh bXBsZSwgdG8NCj4gY2FwdHVyZQ0KPiA+ICAgICBJUHY0IHRyYWZmaWMgaW4gYW4gSVB2NiBuZXR3 b3JrIGFuZCBzZW5kIGl0IHRvIGEgcm91dGUgY2hvc2VuIGJ5IHRoZQ0KPiBhdHRhY2tlci4NCj4g PiAgICAgVGhlIGF0dGFjayBtaWdodCBhbHNvIGJlIHVzZWQgaW4gYSBkdWFsIHN0YWNrIG5ldHdv cmsgdGhhdCBkb2VzIG5vdA0KPiBzdXBwb3J0DQo+ID4gICAgIGFueSB0cmFuc2l0aW9uIHRlY2hu b2xvZ3kuIEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhpcyBhdHRhY2sgaXMNCj4gbWl0aWdhdGVk Lg0KPiA+DQo+ID4gTm90IHN1cmUgaWYgeW91IHdpbGwgc3VnZ2VzdCBoZXJlIHRoYXQgd2Ugc2hv dWxkIHNheSBzb21ldGhpbmcgYWJvdXQgdGhlDQo+IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFs cmVhZHkgbWVudGlvbiBpbiBSRkM4MDI2LiBJbiBnZW5lcmFsIGFsbCB0aG9zZSBhcmUNCj4gZ2Vu ZXJpYyBESENQdjYgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgSSB0aGluay4NCj4gDQo+IEJhc2lj YWxseSwgdGhlIGRldmljZXMgc2hvdWxkIGJlIHByb2dyYW1tZWQgdG8gaWdub3JlIERIQ1B2NiBp ZiB0aGV5DQo+IGhhdmUgYW5vdGhlciBtb3JlIHNlY3VyZSB3YXkgb2YgZ2V0dGluZyB0aGVpciBj b25maWd1cmF0aW9uIGRhdGEuIFBsdXMsDQo+IGFwcGx5IGdlbmVyYWwgZGVmZW5zZSBhZ2FpbnN0 IERIQ1B2NiBoYWNrcyBpbiB0aGUgbmV0d29yaywgZXRjLiBJDQo+IHVuZGVyc3RhbmQgdGhhdCB5 b3VyIGRyYWZ0IGlzIG1lYW50IHRvIGluZm9ybSB0aGUgYnVpbGRpbmcgb2YgQ1BFcywgYnV0DQo+ IGl0cyBlZmZlY3QgaXMgZ2VuZXJhbGl6YXRpb24gb2YgYW4gdW5zYWZlIG1lY2hhbmlzbS4NCj4g DQo+IA0KPiA+DQo+ID4gICAgIE5pdHM6DQo+ID4NCj4gPiAgICAgVGhlIGludHJvZHVjdGlvbiB1 c2VzIHRoZSBhY3JvbnltIFdBTiB3aXRob3V0IHNwZWxsaW5nIG91dCAiV2lkZSBBcmVhDQo+IE5l dHdvcmsiLg0KPiA+ICAgICBBbHNvLCBXQU4gaXMgdXNlZCBhcyBzdWJzdGl0dXRlIGZvciBsb2Nh bCBJbnRlcm5ldCBTZXJ2aWNlIFByb3ZpZGVyDQo+IG5ldHdvcmsuIFdlIGNvdWxkDQo+ID4gICAg IGRlYmF0ZSB3aGV0aGVyIHN1Y2ggbmV0d29ya3MgYXJlIGFsd2F5cyAid2lkZSBhcmVhIiwgYnkg b3Bwb3NpdGlvbiB0bw0KPiBzYXkNCj4gPiAgICAgIm1ldHJvcG9saXRhbiIgb3IgInJlZ2lvbmFs Ii4gVGhpcyBpcyB0aGUgc2FtZSBjb252ZW50aW9uIHVzZWQgaW4gUkZDDQo+IDcwODQgdGhhdA0K PiA+ICAgICB0aGlzIGRvY3VtZW50IHVwZGF0ZXMuIEl0IGlzIGFyZ3VhYmx5IGRlZmluZWQgYnkg cmVmZXJlbmNlLCBidXQNCj4gc3BlbGxpbmcgaXQgb3V0DQo+ID4gICAgIHdvdWxkIGJlIG5pY2Uu DQo+ID4NCj4gPiBXaWxsIGRvLg0KPiA+DQo+ID4NCj4gPiAgICAgVGhlIGNvbXBhcmlzb24gd2l0 aCBSRkM3MDg0IHNlY3Rpb24gaW5jbHVkZXMgYSBtYW5nbGVkIHNlbnRlbmNlOg0KPiA+DQo+ID4g ICAgICAgIFRoaXMgZG9jdW1lbnQgZG9lc24ndCBpbmNsdWRlIHN1cHBvcnQgZm9yIDZyZCAoW1JG QzU5NjldKSwgYmVjYXVzZQ0KPiBhcw0KPiA+ICAgICAgICBpbiBhbiBJUHY2LWluLUlQdjQgdHVu bmVsaW5nLg0KPiA+DQo+ID4gVHlwbywgc29ycnkgdGhlIGNvcnJlY3Qgc2VudGVuY2Ugd2FzOg0K PiA+ICAgICAgICBUaGlzIGRvY3VtZW50IGRvZXNuJ3QgaW5jbHVkZSBzdXBwb3J0IGZvciA2cmQg KFtSRkM1OTY5XSksIGJlY2F1c2UNCj4gaXMNCj4gPiAgICAgICAgYW4gSVB2Ni1pbi1JUHY0IHR1 bm5lbGluZy4NCj4gDQo+ICAgICAgICBUaGlzIGRvY3VtZW50IGRvZXNuJ3QgaW5jbHVkZSBzdXBw b3J0IGZvciA2cmQgKFtSRkM1OTY5XSksIGJlY2F1c2UgaXQNCj4gaXMNCj4gICAgICAgIGFuIElQ djYtaW4tSVB2NCB0dW5uZWxpbmcuDQo+IA0KPiA+DQo+ID4gICAgIFBsZWFzZSByZXBocmFzZS4g UGxlYXNlIGFsc28gcmVwaHJhc2UgdGhlIG5leHQgc2VudGVuY2UsIGZvciBzaW1pbGFyDQo+IHJl YXNvbnM6DQo+ID4NCj4gPiAgICAgICAgUmVnYXJkaW5nIERTLUxJVEUgW1JGQzYzMzNdLCB0aGlz IGRvY3VtZW50IGluY2x1ZGVzIHNsaWdodGx5DQo+ID4gICAgICAgIGRpZmZlcmVudCByZXF1aXJl bWVudHMsIGJlY2F1c2UgdGhlIFBDUCAoW1JGQzY4ODddKSBzdXBwb3J0IGFuZCB0aGUNCj4gPiAg ICAgICAgcHJpb3JpdGl6YXRpb24gb2YgdGhlIHRyYW5zaXRpb24gbWVjaGFuaXNtcywgaW5jbHVk aW5nIGR1YWwtc3RhY2suDQo+ID4NCj4gPiBJIHRoaW5rIGl0IGlzIG11Y2ggY2xlYXIgdGhpcyB3 YXk6DQo+ID4NCj4gPiAgICAgICAgUmVnYXJkaW5nIERTLUxJVEUgW1JGQzYzMzNdLCB0aGlzIGRv Y3VtZW50IGluY2x1ZGVzIHNsaWdodGx5DQo+ID4gICAgICAgIGRpZmZlcmVudCByZXF1aXJlbWVu dHMsIHJlbGF0ZWQgdG8gdGhlIHN1cHBvcnQgb2YgUENQIChbUkZDNjg4N10pLA0KPiA+ICAgICAg ICBJR0QtUENQIElXRiBbUkZDNjk3MF0gYW5kIHRoZSBwcmlvcml0aXphdGlvbiBvZiB0aGUgdHJh bnNpdGlvbg0KPiA+ICAgICAgICBtZWNoYW5pc21zLCBpbmNsdWRpbmcgZHVhbC1zdGFjay4NCj4g DQo+IE9LLg0KPiANCj4gDQo+ID4NCj4gPg0KPiA+ICAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4g PiAgICAgdjZvcHNAaWV0Zi5vcmcNCj4gPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+IElQdjQgaXMgb3Zlcg0KPiA+IEFy ZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiA+IGh0dHA6Ly93d3cudGhlaXB2 NmNvbXBhbnkuY29tDQo+ID4gVGhlIElQdjYgQ29tcGFueQ0KPiA+DQo+ID4gVGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg b3INCj4gY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFu ZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwNCj4gY29weWlu ZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlv biwgZXZlbiBpZg0KPiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZQ0KPiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2Zm ZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZQ0KPiB0 aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBj b250ZW50cyBvZiB0aGlzDQo+IGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVk aW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseQ0KPiBwcm9oaWJpdGVkLCB3aWxsIGJlIGNv bnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUNCj4g b3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRl bGV0ZSBpdC4NCj4gPg0KPiA+DQo+ID4NCg0K From nobody Fri Dec 14 07:08:04 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1D8128CB7 for ; Fri, 14 Dec 2018 07:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 bWncHf0HhJ-T for ; Fri, 14 Dec 2018 07:08:02 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A201D1288BD for ; Fri, 14 Dec 2018 07:08:01 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.57.147; From: "Susan Hares" To: "'Yoav Nir'" , References: <154472041086.32079.7701806228294346668@ietfa.amsl.com> In-Reply-To: <154472041086.32079.7701806228294346668@ietfa.amsl.com> Date: Fri, 14 Dec 2018 10:07:55 -0500 Message-ID: <00a201d493be$cb046840$610d38c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFiQcmhbp4dFLr+Otmeq94d8UXrmqZi+dkQ Content-Language: en-us X-Antivirus: AVG (VPS 181214-4, 12/14/2018), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-idr-te-pm-bgp-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 15:08:03 -0000 Yoav:=20 Thank you for your review. I appreciate your prompt review of the IDR = document.=20 Susan Hares=20 -----Original Message----- From: Yoav Nir [mailto:ynir.ietf@gmail.com]=20 Sent: Thursday, December 13, 2018 12:00 PM To: secdir@ietf.org Cc: idr@ietf.org; ietf@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org Subject: Secdir last call review of draft-ietf-idr-te-pm-bgp-15 Reviewer: Yoav Nir Review result: Ready This completes my early review of this draft. All the points I've raised have been addressed. I believe that the = current draft has the needed text in the security considerations = section. From nobody Fri Dec 14 09:59:55 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE931311D7; Fri, 14 Dec 2018 09:59:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: draft-wilde-sunset-header.all@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154481038620.30630.16239406236727155123@ietfa.amsl.com> Date: Fri, 14 Dec 2018 09:59:46 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-wilde-sunset-header-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 17:59:47 -0000 Reviewer: Joseph Salowey Review result: Ready The document revision adequately addressed my comments. From nobody Fri Dec 14 11:28:48 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3CF1312AD for ; Fri, 14 Dec 2018 11:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 ZIGBdob3nfJR for ; Fri, 14 Dec 2018 11:28:45 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 A085D1312B7 for ; Fri, 14 Dec 2018 11:28:42 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx63.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gXt8Z-0009BL-8q for secdir@ietf.org; Fri, 14 Dec 2018 20:28:40 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gXt7n-00043I-HT for secdir@ietf.org; Fri, 14 Dec 2018 14:28:37 -0500 Received: (qmail 22276 invoked from network); 14 Dec 2018 19:01:09 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Dec 2018 19:01:09 -0000 To: mohamed.boucadair@orange.com, JORDI PALET MARTINEZ , "secdir@ietf.org" Cc: "v6ops@ietf.org" , "ietf@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> <787AE7BB302AE849A7480A190F8B93302E059014@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Fri, 14 Dec 2018 11:01:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E059014@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vwon9KZlglxxIbQMkBX98l602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQSEIsaL6W5kBtA1+kI91C8+oyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1Tp2qINNumDttMaLRLWWvV6Xe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsey6n3SPEHq5iliCZ8XofdvQPwUimsNGvJJilSn4u6QSZKX4S37qQQBw Aej9qldla+ss95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53mHv93Xd4vvLeOO86n1rCqjAMgFPp7+h3kLe NmBV53UGW9b8VrusR2lXu2H6mhL90RXoHi/zqZrZl2NgJNWo0lVRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/FR5hOBQdDDoj2Q1DGd4Y477G3ch6MdB0XuALpEgtIRS8rMgFGxC0xSok+fi i+Mknt40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 19:28:47 -0000 Pointing to the RFC8415 security section would definitely help. What is specific about your draft is that attackers can leverage the DHCPv6 issue and mislead nodes into choosing transition schemes in the wrong order. This is an additional exploitation mechanism on top of=C2=A0 the existing issues mentioned in the DHCPv6 RFC. I would also mention that these security issues are hard to mitigate and that secure environments might require other configuration methods. This also begs the larger question about why we have so many transition mechanisms in the first place, and why the local nodes even need to be aware about them. It seems that this could be radically simplified, by having the router either advertise IPv4 connectivity using traditional IPv4 means, or advertise a NAT64 prefix if it expects local nodes to perform their own mapping. On 12/13/2018 11:44 PM, mohamed.boucadair@orange.com wrote: > Christian, > > As mentioned by Jordi, RFC8026 already describes the attack vector you = mentioned.=20 > > Wouldn't pointing to https://tools.ietf.org/html/rfc8415#section-22 be = sufficient here?=20 > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: ietf [mailto:ietf-bounces@ietf.org] De la part de Christian = Huitema >> Envoy=C3=A9=C2=A0: vendredi 14 d=C3=A9cembre 2018 08:26 >> =C3=80=C2=A0: JORDI PALET MARTINEZ; secdir@ietf.org >> Cc=C2=A0: v6ops@ietf.org; ietf@ietf.org; draft-ietf-v6ops-transition- >> ipv4aas.all@ietf.org >> Objet=C2=A0: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-t= ransition- >> ipv4aas-11 >> >> >> On 12/13/2018 2:09 PM, JORDI PALET MARTINEZ wrote: >>> Hi Christian, >>> >>> Thanks a lot for your review. >>> >>> Please see below in-line. >>> >>> I'm working in a new version according to the comments got from the o= ps >> review as well, so will be able to integrate yours very quickly. >>> Regards, >>> Jordi >>> >>> >>> >>> =EF=BB=BF-----Mensaje original----- >>> De: v6ops en nombre de Christian Huitema >> >>> Fecha: jueves, 13 de diciembre de 2018, 21:50 >>> Para: >>> CC: , , > ipv4aas.all@ietf.org> >>> Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transitio= n- >> ipv4aas-11 >>> Reviewer: Christian Huitema >>> Review result: Has Issues >>> >>> I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of= the >>> security directorate's ongoing effort to review all IETF document= s >>> being processed by the IESG. These comments were written primari= ly for >>> the benefit of the security area directors. Document editors and= WG >> chairs >>> should treat these comments just like any other last call comment= s. >>> >>> The summary of the review is "ready with issue". >>> >>> The document describes solution for providing "IPv4 as a service"= , i.e. >>> provision of IPv4 as a service over an IPv6 only network. >>> It calls this support "transition as a service". >>> >>> For various reasons, IETF working groups have standardized not ju= st one >> but >>> five different mechanisms for providing this transition: 464XLAT >> [RFC6877], >>> Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], >>> MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Pytho= n >> could have >>> produced a nice sketch about that.) The purpose of the draft is t= o >>> state how home routers (a.k.a. customer premise equipment, CPE) s= hould >>> inform local devices about which of the mechanisms are available,= which >>> should be preferred, and what parameters should be used when depl= oying >>> the chosen services. This is done using the DHCPv6 "S46" option >>> specified in RFC 8026. >>> >>> The draft also makes specific recommendation regarding the use of= the >> UPnP and >>> PCP services, by requiring specific error codes when a requested = port >> mapping >>> is not available through the specified transition technology. >>> >>> The security section briefly points to the "Basic Requirements fo= r IPv6 >>> Customer Edge Routers" specified in RFC 7084, and to the security= >>> section of each of the RFC describing the security technologies, = and >> implicitly >>> argues that there are no other security issues. I think that is >> insufficient. >>> The draft introduces a reliance on the DHCPv6 "S46" option for >> assessing the >>> relative priority of different transition technologies. An attack= er >> could spoof >>> the DHCPv6 response, and direct client traffic to a different >> technology than >>> selected by the service provider. This could be used, for example= , to >> capture >>> IPv4 traffic in an IPv6 network and send it to a route chosen by = the >> attacker. >>> The attack might also be used in a dual stack network that does n= ot >> support >>> any transition technology. I don't understand how this attack is >> mitigated. >>> Not sure if you will suggest here that we should say something about = the >> security considerations already mention in RFC8026. In general all tho= se are >> generic DHCPv6 security considerations I think. >> >> Basically, the devices should be programmed to ignore DHCPv6 if they >> have another more secure way of getting their configuration data. Plus= , >> apply general defense against DHCPv6 hacks in the network, etc. I >> understand that your draft is meant to inform the building of CPEs, bu= t >> its effect is generalization of an unsafe mechanism. >> >> >>> Nits: >>> >>> The introduction uses the acronym WAN without spelling out "Wide = Area >> Network". >>> Also, WAN is used as substitute for local Internet Service Provid= er >> network. We could >>> debate whether such networks are always "wide area", by oppositio= n to >> say >>> "metropolitan" or "regional". This is the same convention used in= RFC >> 7084 that >>> this document updates. It is arguably defined by reference, but >> spelling it out >>> would be nice. >>> >>> Will do. >>> >>> >>> The comparison with RFC7084 section includes a mangled sentence: >>> >>> This document doesn't include support for 6rd ([RFC5969]), bec= ause >> as >>> in an IPv6-in-IPv4 tunneling. >>> >>> Typo, sorry the correct sentence was: >>> This document doesn't include support for 6rd ([RFC5969]), bec= ause >> is >>> an IPv6-in-IPv4 tunneling. >> This document doesn't include support for 6rd ([RFC5969]), beca= use it >> is >> an IPv6-in-IPv4 tunneling. >> >>> Please rephrase. Please also rephrase the next sentence, for simi= lar >> reasons: >>> Regarding DS-LITE [RFC6333], this document includes slightly >>> different requirements, because the PCP ([RFC6887]) support an= d the >>> prioritization of the transition mechanisms, including dual-st= ack. >>> >>> I think it is much clear this way: >>> >>> Regarding DS-LITE [RFC6333], this document includes slightly >>> different requirements, related to the support of PCP ([RFC688= 7]), >>> IGD-PCP IWF [RFC6970] and the prioritization of the transition= >>> mechanisms, including dual-stack. >> OK. >> >> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged = or >> confidential. The information is intended to be for the exclusive use = of the >> individual(s) named above and further non-explicilty authorized disclo= sure, >> copying, distribution or use of the contents of this information, even= if >> partially, including attached files, is strictly prohibited and will b= e >> considered a criminal offense. If you are not the intended recipient b= e aware >> that any disclosure, copying, distribution or use of the contents of t= his >> information, even if partially, including attached files, is strictly >> prohibited, will be considered a criminal offense, so you must reply t= o the >> original sender to inform about this communication and delete it. >>> >>> From nobody Sun Dec 16 13:27:08 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DBC1310DA; Fri, 14 Dec 2018 01:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1544779342; bh=i3t12kmsnNBCZOVE9FH4uVvvbx/E/Kfx1eBuZ+hfPSk=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=RdBNxKs8zt4zwgRd7gjlLkCA7Fk2X8s3vdfIsx58uGdkqL9N8xdRIePWy5TK0yKe4 UBpFVsdPcN2vn247cMewu0OY8YtSiiN6t2kcnKtAvZ+xcVkifbAQKUPrvpFi3tlw+t I3I5GwhmNcMVUiLKCgvfvsL+lqLpXeKi0wX3wOYQ= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Dec 14 01:22:21 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC64128AFB; Fri, 14 Dec 2018 01:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1544779341; bh=i3t12kmsnNBCZOVE9FH4uVvvbx/E/Kfx1eBuZ+hfPSk=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=k2/y0Io3/2XY5T0FJ/K+njz/m4IQsu9zd4qF4iyJIKWoZKNXuy6gl+IREg0jXdB04 t3v49xMRSAaGiPyHkbLI4UKvsDCK834d4QpXXSsMGlGM0rn33h+4X62sZs0+LeMF2G GrCEZo2k9iZK5mvQ3FbatR1sYxOeClo2ZBIpOC9Y= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF587126CC7 for ; Fri, 14 Dec 2018 01:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL=0.141, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 3ff-3SLJKlwX for ; Fri, 14 Dec 2018 01:22:18 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 2DA76126CB6 for ; Fri, 14 Dec 2018 01:22:14 -0800 (PST) Received: from [112.102.121.93] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gXjfg-0008HJ-8f for new-work@ietf.org; Fri, 14 Dec 2018 09:22:12 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <1cbf4203-9e5f-e281-6341-5f0b3233a7a8@w3.org> Date: Fri, 14 Dec 2018 17:22:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sun, 16 Dec 2018 13:27:08 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Scalable Vector Graphics (SVG) Working Group (until 2019-01-25) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 09:22:24 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgU2NhbGFi bGUgVmVjdG9yIEdyYXBoaWNzIChTVkcpIFdvcmtpbmcgCkdyb3VwOgogwqAgaHR0cHM6Ly93d3cu dzMub3JnL0dyYXBoaWNzL1NWRy9zdmctMjAxOS1hYy5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5n IHRoYXQgdGhlIGNvbW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhp cyBkcmFmdCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSBy ZXZpZXcgcGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAxOS0w MS0yNSBvbiB0aGUKcHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVi bGljLW5ldy13b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRw Oi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0 aGFuIGNvbW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29t bWl0dGVlIFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0 bwpjb21tZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29y ZGluYXRlCnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNl bnRhdGl2ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50 cyB2aWEgdGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2Vu dGF0aXZlIHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRz LgoKSWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9y bWF0aW9uLCBwbGVhc2UKY29udGFjdCBDaHJpcyBMaWxsZXksIFNWRyBXb3JraW5nIEdyb3VwIFN0 YWZmIENvbnRhY3QsIDxjaHJpc0B3My5vcmc+LgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEsIFcz QyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNv cnRpdW0vTWVtYmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Sun Dec 16 15:56:25 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4C61310CF; Sun, 16 Dec 2018 15:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=mnot.net header.b=mdjtYPTq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sUyuXHzS 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 IoJJr7JwtgAD; Sun, 16 Dec 2018 15:56:14 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576A51310C6; Sun, 16 Dec 2018 15:56:14 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 76ABF11B9; Sun, 16 Dec 2018 18:56:13 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 16 Dec 2018 18:56:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=x mMzL0kZXz9mdsxte/GdctBJjqu03J9Rydr6J7RHV7k=; b=mdjtYPTqE6mJMjPsc lCTCi8NU6ml056OTVw2CmAb02CDZ6Ha8ssaLw5gYc4gQGWFogiaK0mm/EmWdExXF Ojk2Ars+DnP0FlKJLtA20ksLaHeQks6hdsicLVDbkzjLvGKCZoWVXx1OGoTiJojL spXZJI6qqCFvBBCqUC9Iu0oJR5mo6XYLpbJo2i9ysSOCjLaiKzwG/1y7e6GKgVea l6ileVXCwEeZXy8V3BMTY8GDSwt1IeH13E8uhxsFGD7g7BqItk7sGyCUU16JogB4 5xS1y+BDoC3QqXKpJ53Y51jc2KXxAiD8A1ynUjN/W8KTEhnP9jREJ4b00NdvGlFr qayMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=xmMzL0kZXz9mdsxte/GdctBJjqu03J9Rydr6J7RHV 7k=; b=sUyuXHzSb33BUubjXxtbXb5IiMYa8UCmzb0p1xQvE6lhRsJmBmHcWpKVt /L7GCAaY6VEK/OafOS+uCwjRg2A1e/PokUiGLg9pXqXoUVGsv2kVewaIwJqy4hXO Q9lbOsN/h3E9Paa9QBwpE6dmBv3FxOWaOSUEh1jzBpI8xCrC9o0Yt3F67v42vI11 fWmkohfb+Od4dbDTfMkQiu343aGKnxRQb8imiNMC/R/0G/DbawmGPqE/Zc5z6iZ5 Q5UcL2LfxQ2Nli7tjIN3XrLMA7UHz8bQTdIF1o43ts81uCRQxefnSZtL2pHC01r+ e6w04LwQscDmchM6WlrDVwhfmUcRw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudehledgudejlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhroh hmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecu ffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedrvdekne curfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id AB3D2E4892; Sun, 16 Dec 2018 18:56:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Mark Nottingham In-Reply-To: Date: Mon, 17 Dec 2018 10:56:06 +1100 Cc: "iesg@ietf.org" , draft-ietf-httpbis-cdn-loop.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8EC47356-006A-4A47-8C4C-09C9F31010D2@mnot.net> References: To: Donald Eastlake X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-cdn-loop-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2018 23:56:17 -0000 Hi Donald, Thanks for the review. Some responses below. > On 11 Dec 2018, at 10:40 pm, Donald Eastlake wrote: >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = Document editors and WG chairs should treat these comments just like = any other last call comments. >=20 > The summary of the review is Ready with issues. >=20 > This document specifies a new "CDN-Loop" HTTP header field to detect = Content Delivery Network loops. Such loops can be caused by = misconfiguration or as part of a denial of service attack. >=20 > Security: >=20 > It is slightly misleading that in Section 1 the draft says how = valuable an HTTP header "guaranteed not to be modified" would be but = then the draft does not provide such a header. Maybe instead say "should = normally be unmodified". Agreed; we'll adjust this language. > I believe this document should RECOMMEND that CDN-Loop headers include = some sort of MAC (Message Authentication Code) covering the header so a = CDN node can reliably recognize CDN-Loop headers that it has added. = Since it need only recognize its own headers, the MAC need not be = further specified or interoperable. (CDN-Loop information in an HTTP = message can grow by the appending of entries or by additional of another = CDN-Loop header. Since I have little confidence in the stability of = header order, I would suggest MACs added as a parameter to a CDN-Loop = header by the last parameter for that entry and sign that entry and all = previous entries in that CDN-Loop header.) This could be done by = modifying the 3rd paragraph of the Security Considerations section. The authors have discussed this, and we don't see much utility in this; = a MAC would protect against the modification of the key/value pairs, but = they're not crucial to the functionality of the header. If an attacker = were able to modify header values, something much more than a MAC would = be needed. Also, as you note, interoperability isn't necessary here. So, = while I think we're fine with mentioning in Security Considerations that = parameters can be used to secure the field, I for one would be wary of = going any further than that in this specification. > Nit: >=20 > Section 2: 3rd paragraph, suggest replacing "field to all requests" = with "field in all requests". Thanks. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Dec 17 12:15:10 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FC1126F72; Mon, 17 Dec 2018 12:14:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: Cc: extra@ietf.org, draft-ietf-extra-sieve-special-use.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154507769480.4171.7860732594241016456@ietfa.amsl.com> Date: Mon, 17 Dec 2018 12:14:54 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-extra-sieve-special-use-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 20:14:55 -0000 Reviewer: Stephen Farrell Review result: Ready As stated in the draft I see no new security issues here, given that SIEVE already includes the ability to deliver messages and create mailboxes. A non-security comment, that you should feel free to ignore: as a mail user it is irritating to have multiple folders (that may or may not have a "special-use" attribute associated with 'em) created by multiple MUAs and into which messages can be deposited in a manner that's unpredictable to me as a user . I understand that this spec is already trying to help with that, by reducing the likelihood that such redundant folders get created. But I already have a bunch of those folders, so while this is likely the wrong place for such text, I'd have been happier if the guidance for what to do when there's >1 matching special-use mailbox had been more deterministic, even when the SIEVE-supplied default one doesn't exist. For example, if you'd been able to say to sort the matching folders in some way and then pick the first that'd be better I think, but maybe there are reasons why you can't do that in SIEVE. (I'd be even happier if someone was working on specs/tooling to help merge all those folders somehow, but that's definitely out of scope here.) From nobody Wed Dec 19 08:15:36 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FCC130E2B for ; Wed, 19 Dec 2018 08:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 EepiwT3DTWy6 for ; Wed, 19 Dec 2018 08:15:25 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCD512D4F2 for ; Wed, 19 Dec 2018 08:15:25 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id a11so19546870otr.10 for ; Wed, 19 Dec 2018 08:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kd5c8TLkuWE4qHVQHOj79TbhfvgBOaFy9GmlX52JTRI=; b=Z53wVU7wJERMTYPTYUUtG2vr4YFAxjMfdjegzu4CqX0jDgqH1PMPnzw2n8f/xn0tAk bOc/nTMDueRItagWwfnUUIwQtnAeq9qhXkPZbOKORJIkYRx2ukKG7aDzTio4yTwxHgna s2/8vp8pB/DL/Bt0J34h5Pgx8VmjOXiqG8qFRLDqScNcLbhCHcwTyeKB/wxAfMHVLp3i AUTa3lccWu5L6gvh7QD3tNzk69hDq3FsUsCEX6eB9MI6tXJnWzQ/lGsrqaeP/ErQBF8S 4sfrfs6+XkzR0/ni2/bLmtxHrmtZbZnujy5cMsoSjvYj3lud0dxQLAERVGDDvHpWdm0/ k1kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kd5c8TLkuWE4qHVQHOj79TbhfvgBOaFy9GmlX52JTRI=; b=GPg3ClWM49I3PVUeRUG4TEvA7WHswnQ4Njgi8v6F2p/icnIkk/RWWyRdEHnqr5H+hW TcOZi9/szeWvKveZj0OdqlsRCMjpr/owisqm6YTr+TMBmVEkUviBidQ6WvHF4h81bsfG ICbxmOGQ4bBDB9VtCuhAhylBZzXtQzq0qwULxTrBfae2Lq82t+yrtV5BgSL8Uhg6vamd bW9m/iE9UY2yheboNhW7RKTN8S4XK8uWV4dVwkWrIu7n6tZMt6gk0BPgdJ8sSBzkFo6N dpxE8Mdt+uO8nTlYlNBwx2CBapghPW3wkWXAqOYrljeJVKpCBJDzDYK7NNBACF7ZfIuO p+Rg== X-Gm-Message-State: AA+aEWYe92Y0W8/q2brQz2Etoj11Qo4q+ja6HcU/RoiVvdewQbsAeL0t 8slUeIzPJrjdRCAlbm0K9ANhIFAIABEInqQ4IdTYuuhoa4J5cA== X-Google-Smtp-Source: AFSGD/UT1POrfTOX2Xd18WaM/x5U7iqFVLz7vc1tIeaLRQXar/+8hskLXAyypV5kdw8mdNb8QUyiGzHqSxBJcRh0S2M= X-Received: by 2002:a9d:191a:: with SMTP id j26mr6700950ota.81.1545236123730; Wed, 19 Dec 2018 08:15:23 -0800 (PST) MIME-Version: 1.0 References: <201810312038.w9VKcZmV013489@rumpleteazer.rhmr.com> In-Reply-To: <201810312038.w9VKcZmV013489@rumpleteazer.rhmr.com> From: Richard Barnes Date: Wed, 19 Dec 2018 11:15:08 -0500 Message-ID: To: Hilarie Orman Cc: The IESG , secdir , draft-ietf-perc-srtp-ekt-diet.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000003ff476057d6252eb" Archived-At: Subject: Re: [secdir] Security review of draft-ietf-perc-srtp-ekt-diet-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 16:15:29 -0000 --0000000000003ff476057d6252eb Content-Type: text/plain; charset="UTF-8" Hi Hilarie, Thanks for the review. Sorry for the delay in responding. Responses inline. On Wed, Oct 31, 2018 at 4:39 PM Hilarie Orman wrote: > Security review of Encrypted Key Transport for DTLS and Secure RTP > draft-ietf-perc-srtp-ekt-diet-08 > > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > The draft defines a way by which each sender in a multi-participant > session can communicate its encrypting key (called a "master key") to > the other participants. In this scheme, all participants learn a > key encrypting key (EKTKey) that is used to protect sender's > encrypting keys during transit. > > "This specification also defines a way to send the encrypted SRTP > master key (with the EKTKey) along with the SRTP packet ... > Endpoints that receive this and know the EKTKey can use the EKTKey > to decrypt the SRTP master key which can then be used to decrypt > the SRTP packet." > > I think that the paragraph above would be clearer if "(with the > EKTkey)" were changed to "(encrypted with the EKTkey)". > Ack, queued pending resolution of other topics here. > I do not understand the security model. If all participants know the > EKTkey, then why do senders need to separately select their own > individual keys? Cannot all participants use something derived from > the EKTkey? Is this a legacy thing? > Yes, it's precisely a legacy thing, in a couple of ways. The most important one is that in the SRTP conferencing context, there's not really an identifier that you can rely on being distinct per participant, so basically you don't have a label to put into the KDF. A secondary consideration (not required for PERC AFAIK) is that this allows keys from external systems to be bridged into an EKT-enabled conference. If there were only the first concern, you could do something like use the random value the endpoints make up as a KDF input (together with the master key) instead of a key. But that would cut off the second use case, which I would hesitate to do without some list discussion. Do you have a security concern here, or is this just a question for understanding? I agree that there's some risk that endpoints will generate bad keys, but it seems like if you're unable to generate good keys, you have bigger problems. > > Section 4.4 states that > "EKT uses an authenticated cipher to encrypt and authenticate the > EKTPlaintext." > > Also section 6 (security considerations) states: > The EKT Cipher includes its own authentication/integrity check. For > an attacker to successfully forge a FullEKTField, it would need to > defeat the authentication mechanisms of the EKT Cipher authentication > mechanism. > > Section 4.4.1 state "The default EKT Cipher is the Advanced Encryption > Standard (AES) Key Wrap with Padding [RFC5649] algorithm." > > RFC5649 does not purport to define an authenticated cipher. I am not > sure what properties of RFC5649 are the ones that are considered > important, so I cannot recommend appropriate wording, though I suspect > that "integrity" is the right word, not "authentication". > What do you consider the difference between "integrity" and "authentication" here? ISTM that these two are usually are very commonly conflated at the crypto layer (vs. higher layers of authentication like PKIs). For example, message *authentication* codes are a commonly used for integrity protection. > I have one concern about the requirement that all senders change their > keys when the EKTKey changes. Suppose a malicious participant manages > to create a replay attack that sends a EKTkey message with a key that > was previously used, perhaps even the same one that is currently used. > This would force all participants to change their keys, perhaps at a > very high rate, and this might lead to denial of service. > Participants might be advised to ignore EKTkey messages that repeat > the current EKTkey. > This is a good idea. Queued pending resolution of other topics here. --Richard > > Hilarie > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --0000000000003ff476057d6252eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hilarie,

Thanks for the r= eview.=C2=A0 Sorry for the delay in responding.=C2=A0 Responses inline.
=

On Wed, Oct 31, 2018 = at 4:39 PM Hilarie Orman <hi= larie@purplestreak.com> wrote:
Security review of Encrypted Key Transport for DTLS a= nd Secure RTP
draft-ietf-perc-srtp-ekt-diet-08

Do not be alarmed.=C2=A0 I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and<= br> WG chairs should treat these comments just like any other last call
comments.

The draft defines a way by which each sender in a multi-participant
session can communicate its encrypting key (called a "master key"= ) to
the other participants.=C2=A0 In this scheme, all participants learn a
key encrypting key (EKTKey) that is used to protect sender's
encrypting keys during transit.

"This specification also defines a way to send the encrypted SRTP
=C2=A0 =C2=A0master key (with the EKTKey) along with the SRTP packet ... =C2=A0 =C2=A0Endpoints that receive this and know the EKTKey can use the EK= TKey
=C2=A0 =C2=A0to decrypt the SRTP master key which can then be used to decry= pt
=C2=A0 =C2=A0the SRTP packet."

I think that the paragraph above would be clearer if "(with the
EKTkey)" were changed to "(encrypted with the EKTkey)".
<= /blockquote>

Ack, queued pending resolution of other top= ics here.

=C2=A0
I do not understand the security model.=C2=A0 If all participants know the<= br> EKTkey, then why do senders need to separately select their own
individual keys?=C2=A0 Cannot all participants use something derived from the EKTkey?=C2=A0 Is this a legacy thing?=C2=A0

<= /div>
Yes, it's precisely a legacy thing, in a couple of ways.=C2= =A0 The most important one is that in the SRTP conferencing context, there&= #39;s not really an identifier that you can rely on being distinct per part= icipant, so basically you don't have a label to put into the KDF.=C2=A0= A secondary consideration (not required for PERC AFAIK) is that this allow= s keys from external systems to be bridged into an EKT-enabled conference.<= /div>

If there were only the first concern, you could do= something like use the random value the endpoints make up as a KDF input (= together with the master key) instead of a key.=C2=A0 But that would cut of= f the second use case, which I would hesitate to do without some list discu= ssion.

Do you have a security concern here, or is = this just a question for understanding?=C2=A0 I agree that there's some= risk that endpoints will generate bad keys, but it seems like if you'r= e unable to generate good keys, you have bigger problems.
=C2= =A0

Section 4.4 states that
=C2=A0 =C2=A0"EKT uses an authenticated cipher to encrypt and authenti= cate the
=C2=A0 =C2=A0EKTPlaintext."

Also section 6 (security considerations) states:
=C2=A0 =C2=A0The EKT Cipher includes its own authentication/integrity check= .=C2=A0 For
=C2=A0 =C2=A0an attacker to successfully forge a FullEKTField, it would nee= d to
=C2=A0 =C2=A0defeat the authentication mechanisms of the EKT Cipher authent= ication
=C2=A0 =C2=A0mechanism.

Section 4.4.1 state "The default EKT Cipher is the Advanced Encryption=
=C2=A0 =C2=A0Standard (AES) Key Wrap with Padding [RFC5649] algorithm."= ;

RFC5649 does not purport to define an authenticated cipher.=C2=A0 I am not<= br> sure what properties of RFC5649 are the ones that are considered
important, so I cannot recommend appropriate wording, though I suspect
that "integrity" is the right word, not "authentication"= ;.

What do you consider the difference = between "integrity" and "authentication" here?=C2=A0 IS= TM that these two are usually are very commonly conflated at the crypto lay= er (vs. higher layers of authentication like PKIs).=C2=A0 For example, mess= age *authentication* codes are a commonly used for integrity protection.

=C2=A0
I have one concern about the requirement that all senders change their
keys when the EKTKey changes.=C2=A0 Suppose a malicious participant manages=
to create a replay attack that sends a EKTkey message with a key that
was previously used, perhaps even the same one that is currently used.
This would force all participants to change their keys, perhaps at a
very high rate, and this might lead to denial of service.
Participants might be advised to ignore EKTkey messages that repeat
the current EKTkey.

This is a good idea= .=C2=A0 Queued pending resolution of other topics here.

--Richard

=C2=A0

Hilarie

_______________________________________________
secdir mailing list
secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview
--0000000000003ff476057d6252eb-- From nobody Wed Dec 19 13:20:29 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A71130EC9; Wed, 19 Dec 2018 13:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001] autolearn=ham autolearn_force=no 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 YGj7b3BUD008; Wed, 19 Dec 2018 13:20:12 -0800 (PST) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (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 8602E130E86; Wed, 19 Dec 2018 13:20:09 -0800 (PST) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.89) (envelope-from ) id 1gZjG8-00056y-EJ; Wed, 19 Dec 2018 22:20:04 +0100 Date: Wed, 19 Dec 2018 22:20:04 +0100 From: Sebastian Kiesel To: Liang Xia Cc: secdir@ietf.org, draft-ietf-alto-xdom-disc.all@ietf.org, ietf@ietf.org, alto@ietf.org Message-ID: <20181219212004.3wyr4nq6mcq4c5ug@gw01.ehlo.wurstkaes.de> References: <154346082207.13636.11710948370196493817@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <154346082207.13636.11710948370196493817@ietfa.amsl.com> Accept-Languages: en, de Organization: my personal mail account User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-alto-xdom-disc-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 21:20:15 -0000 Hi, thanks for the review! [draft-ietf-alto-xdom-disc-04] On Wed, Nov 28, 2018 at 07:07:02PM -0800, Liang Xia wrote: > Reviewer: Liang Xia > Review result: Ready > In general, this draft is in good shape, including the security > considerations part. > > I just have some general comments or confusions for discussion as below: > > 1. I don't see the content about the authorization policy for alto server > information distribution, is it necessary? Sorry, I'm not completely sure what that question means. In section 6.3 we state that in all use cases we have studied so far, the mapping from an IP address to the URI of an ALTO server (that can give information related to that IP address) is public information. Therefore, we do not need authentication/authorization/access control for the XDOM procedure as such. Once the URI is discovered and the ALTO client has sent a query to the ALTO server, the ALTO server may do some kind of access control and refuse to return information to the ALTO client. Or is it about an ISP that puts the wrong NAPTR records into their subdomain of in-addr.arpa., thus pointing to the wrong (sombody else's) ALTO server? That would cause some extra load on that other ALTO server, but the ISP would hurt himself most, as traffic distribution in his network could become worse and/or more unpredictable. If I completely missed your point, please clarify. > 2. If the replied alto server > information message is much larger than the request message, the attack can > trigger the reflection DDoS attack using it. Does it need to be considered? The replies with NAPTR records are somewhat larger than the queries, but so are the replies with PTR records in the "normal" usage scenario for in-addr.arpa. I don't think that XDOM will make the current situation much worse. How could we analyze this in more detail? Thanks Sebastian From nobody Wed Dec 19 15:18:30 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7064129BBF; Wed, 19 Dec 2018 15:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3dcCEvUX4vQa; Wed, 19 Dec 2018 15:18:26 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F5E126F72; Wed, 19 Dec 2018 15:18:26 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id o13so12317ioh.2; Wed, 19 Dec 2018 15:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MaUkJsJ92+s0BfHOlExbQV8MxUKJWTmyXsVNt0QFGNU=; b=HzuoB6+Q4/i68WPsndB/HIjWdVqEhwsksCq2Ls6Jdv4vWU/KBN3fX3pfTp1tzjOCM0 2HFJzbP5x0EVuVXaMEJP5gBXjSmQe+h5KITYZNzOr0RNBOJhmuABnn4t42seBNUPMS4J FaxaRinu0FAAECiRSHj7SPiwFj6SZj7npgWbo7UGIslHdPp+TN6hVUv9r3ymDAOc5I+4 AtMayNCwLSRy8YJrHFgjnMGdBr4ToXnSbs8RmilopQJ8qM+tN11I8aM+Pdo4MoNU88n5 pSgvt1YBHucvpw9KsUfhScxhzSubV7ItY/ECteeGewOjC/SWPXKmbzufTX6sxRVeqYNu qHyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MaUkJsJ92+s0BfHOlExbQV8MxUKJWTmyXsVNt0QFGNU=; b=ce7+XZPRC4wy+rQzLvpTTA//5RVOLvRFh7894XK0Di1f0WK+oRN1EYgB8qMe/5ORh+ N5u3OVZ1ylqq5QaE8sHuHJahlSA021zGoCO7puSxQLqF7iu/OdlGvn+nEWY9CqFwaUZz Oj+q1tK+CwavutiQruhwVMUkb5fztSq4/7BDhSkxt7+Lh+7K1e/p6//+fl77LjfjvjaF drJ7xHY513rGpr7waHQJLhDb2oJ/RuyyrJIvyMtHlMdwHI48/e41/CF4qX0rUGQaI4B9 8/hues7MW2V45QM5qhvSl2xo3eCAVEHrKkl1SsiLtjvdQRDRscEHuCm2olDPSzysIRZT yTPQ== X-Gm-Message-State: AA+aEWZzCUSqFFJzl3XB0N8sfOo+e9yPNGX7j3ilaI5ul3ftEaz40ewC WR7pReW8zORows7XJUC2ZZqeVDz+1b2cF8B6u1o= X-Google-Smtp-Source: AFSGD/Xwjoic4HdC/rsGcQZCi1GcMwi6874whImwpP157VsBJj9E0vxkMmFxWrDkkVYifjDIBr7Wb/5+K8PzjW8IZO8= X-Received: by 2002:a6b:e919:: with SMTP id u25mr19991060iof.132.1545261505769; Wed, 19 Dec 2018 15:18:25 -0800 (PST) MIME-Version: 1.0 References: <8EC47356-006A-4A47-8C4C-09C9F31010D2@mnot.net> In-Reply-To: <8EC47356-006A-4A47-8C4C-09C9F31010D2@mnot.net> From: Donald Eastlake Date: Wed, 19 Dec 2018 18:18:14 -0500 Message-ID: To: Mark Nottingham Cc: "iesg@ietf.org" , draft-ietf-httpbis-cdn-loop.all@ietf.org, secdir@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-cdn-loop-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 23:18:29 -0000 On Sun, Dec 16, 2018 at 6:56 PM Mark Nottingham wrote: > > Hi Donald, > > Thanks for the review. Some responses below. > > > On 11 Dec 2018, at 10:40 pm, Donald Eastlake wrote: > > > > I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. Docu= ment editors and WG chairs should treat these comments just like any other = last call comments. > > > > The summary of the review is Ready with issues. > > > > This document specifies a new "CDN-Loop" HTTP header field to detect Co= ntent Delivery Network loops. Such loops can be caused by misconfiguration = or as part of a denial of service attack. > > > > Security: > > > > It is slightly misleading that in Section 1 the draft says how valuable= an HTTP header "guaranteed not to be modified" would be but then the draft= does not provide such a header. Maybe instead say "should normally be unmo= dified". > > Agreed; we'll adjust this language. > > > I believe this document should RECOMMEND that CDN-Loop headers include = some sort of MAC (Message Authentication Code) covering the header so a CDN= node can reliably recognize CDN-Loop headers that it has added. Since it n= eed only recognize its own headers, the MAC need not be further specified o= r interoperable. (CDN-Loop information in an HTTP message can grow by the a= ppending of entries or by additional of another CDN-Loop header. Since I ha= ve little confidence in the stability of header order, I would suggest MACs= added as a parameter to a CDN-Loop header by the last parameter for that e= ntry and sign that entry and all previous entries in that CDN-Loop header.)= This could be done by modifying the 3rd paragraph of the Security Consider= ations section. > > The authors have discussed this, and we don't see much utility in this; a= MAC would protect against the modification of the key/value pairs, but the= y're not crucial to the functionality of the header. If an attacker were ab= le to modify header values, something much more than a MAC would be needed.= Also, as you note, interoperability isn't necessary here. So, while I thin= k we're fine with mentioning in Security Considerations that parameters can= be used to secure the field, I for one would be wary of going any further = than that in this specification. Well, OK I guess. It just seems so easy to add a MAC in the header covering the preceding part of that header that I would do it. And it would help rule out certain causes when debugging problems. But if the WG has decided not to recommend this, so be it. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com > > Nit: > > > > Section 2: 3rd paragraph, suggest replacing "field to all requests" wit= h "field in all requests". > > Thanks. > > Cheers, > > > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Wed Dec 19 21:11:37 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10841127B4C; Wed, 19 Dec 2018 21:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=mnot.net header.b=Ke5YXsH2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D4o6Pj4i 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 cQbOO_zljVOz; Wed, 19 Dec 2018 21:11:32 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A822F123FFD; Wed, 19 Dec 2018 21:11:31 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 91DD421F40; Thu, 20 Dec 2018 00:11:30 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 20 Dec 2018 00:11:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=3 +I3IBgts2GqlWt55XJnl7cQAF97GI8QGjT61GXFJt4=; b=Ke5YXsH2MevdU250B 0b+sHkbn9KY/Hg4G/LK4F81Q0pWLP9YeLaBAoex24TWR8gFen1pVLOKEtfybmz0I cCs8YZTijei32sgcY/0v8wp8Z5Ax/HVvEaAWU2Rtf99o8SftQ7Y1kUYDxstahYVx 5P+KUmBn84+5fndciRkMfu2CLvtQNdBNNUAZxk8GkO14njsWb2rhEd9GbNcbjVaD lDQ8Z+eEzzpo+zbz+X5Mk1BdYCUizPs/8TZ+S4CoHanKk63Tx9T2QNrirEZxCpNd JEifg4xC2TJaRv+NPFO8c1H1PrO9yR4ptxIbxJR/8r7eOho+c1sozdbBJkjYLYU1 CYuJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=3+I3IBgts2GqlWt55XJnl7cQAF97GI8QGjT61GXFJ t4=; b=D4o6Pj4ijmS0cNodzdxJQQMhjsldO0ZS83EpV9HHmzIaUmG18vat1QeFt M8BqGD+qNJ7/KBLMGh8MGDh0W73Lnk2OQi42m4xRtWykImdMKLG2J8km9AdO7q2c GTTtD+7wTmQH3cCDRR05RpVVs+50QKCf1ouQufOGYLlkyKWulj/3/4RvdhVfsqgq 1jVZoHnE4HO1HAOXqBlN1Y5eNsyWr2PjjZ2v8eOHzATIBlFLJaiNXXkDRYuOqHK8 t6YA2BOV1J0YMsk/fcgFIjigxuec15Hi0Q0zUqN/4d0r+fpnYe/TdcytrHQ/fXKz yeodxgN3nfYIB+pOnl6Mg99ouNA/w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejvddgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomh epofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucff ohhmrghinhepmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddvkeenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id E6E4BE40A1; Thu, 20 Dec 2018 00:11:27 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Mark Nottingham In-Reply-To: Date: Thu, 20 Dec 2018 16:11:24 +1100 Cc: "iesg@ietf.org" , draft-ietf-httpbis-cdn-loop.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <523B0785-6B4A-4B68-9D04-F32087332CE7@mnot.net> References: <8EC47356-006A-4A47-8C4C-09C9F31010D2@mnot.net> To: Donald Eastlake X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-cdn-loop-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 05:11:35 -0000 > On 20 Dec 2018, at 10:18 am, Donald Eastlake wrote: >=20 >>> I believe this document should RECOMMEND that CDN-Loop headers = include some sort of MAC (Message Authentication Code) covering the = header so a CDN node can reliably recognize CDN-Loop headers that it has = added. Since it need only recognize its own headers, the MAC need not be = further specified or interoperable. (CDN-Loop information in an HTTP = message can grow by the appending of entries or by additional of another = CDN-Loop header. Since I have little confidence in the stability of = header order, I would suggest MACs added as a parameter to a CDN-Loop = header by the last parameter for that entry and sign that entry and all = previous entries in that CDN-Loop header.) This could be done by = modifying the 3rd paragraph of the Security Considerations section. >>=20 >> The authors have discussed this, and we don't see much utility in = this; a MAC would protect against the modification of the key/value = pairs, but they're not crucial to the functionality of the header. If an = attacker were able to modify header values, something much more than a = MAC would be needed. Also, as you note, interoperability isn't necessary = here. So, while I think we're fine with mentioning in Security = Considerations that parameters can be used to secure the field, I for = one would be wary of going any further than that in this specification. >=20 > Well, OK I guess. It just seems so easy to add a MAC in the header > covering the preceding part of that header that I would do it. And it > would help rule out certain causes when debugging problems. But if the > WG has decided not to recommend this, so be it. Just to make sure you saw it, Security Considerations already includes: """ It is possible to sign the contents of the header (either by putting the = signature directly into the field's content, or using another header field), but such use is not = defined (or required) by this specification. """ Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Dec 20 05:08:21 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC63131105; Thu, 20 Dec 2018 00:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1545295104; bh=MFGVgTbEz79O7pwwak+Oep3WJ7S1/5mFnNjbUUvPRNQ=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=y9ISKhFR7tPR5/oEhlGHHYjBuiFDhKtfsrwXRHdSto7aAsiPb+V1juhlKHdPkjwmY Z9VxDrHhS0O5sOkK6I56Gm3LNSZ63Cs+qkmh1DOnmiqoKaCAY4cgFrg1kvbazZpfjI ex+xHtksSjVI+fswz1PC/I3wAv/x8iN5/L/yjhVc= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Dec 20 00:38:23 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A11D61310F9; Thu, 20 Dec 2018 00:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1545295103; bh=MFGVgTbEz79O7pwwak+Oep3WJ7S1/5mFnNjbUUvPRNQ=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ZUphVgmsnIcYDqBVJESgkrPTOy8Egf5AysIFDcvlFUMBX2EzKertuiXq4qgDBp41V u2neE8O19isDfVacy+Rcl/dZBwrJMKxtw2Nj59icLD5rYx6k3tLsvdvf3syQweVMN1 GI5EesvUoG0nMezzr/ieZohWCMxlIufQvI7Fgtxg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2E7130EF5 for ; Thu, 20 Dec 2018 00:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 CqsSeEYf4hAc for ; Thu, 20 Dec 2018 00:38:20 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 4F30E1310F9 for ; Thu, 20 Dec 2018 00:38:20 -0800 (PST) Received: from boc06-4-78-216-15-101.fbx.proxad.net ([78.216.15.101] helo=[192.168.0.14]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gZtqU-0001jy-28; Thu, 20 Dec 2018 08:38:18 +0000 From: Coralie Mercier Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 20 Dec 2018 09:38:15 +0100 Message-Id: To: new-work@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 20 Dec 2018 05:08:21 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Secure Web Payments Interest Group (until 2019-01-23) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 08:38:26 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Secure Web Payments Interest Group: https://www.w3.org/securepay/charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2019-01-23 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Ian Jacobs, Staff Contact . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/Coralie/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Dec 20 08:15:12 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE253129AA0; Thu, 20 Dec 2018 08:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rTu6bLY7MgM5; Thu, 20 Dec 2018 08:15:01 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BED12894E; Thu, 20 Dec 2018 08:15:00 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id l10so1781144lfh.9; Thu, 20 Dec 2018 08:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EHuZ6eFZRvfRmkMnFuprTuhpXuWMEXs6tB5XaMPLb0k=; b=JZqrT5zaGNB9aa/SQBV0V5QejwmEbwK+fgxJYEfjde6ZCwvRtb+MY2cmkWgljKdrkl SJPa5M7ab4pBmgg/lAIDo+kCikuXQhVmWFppvIN7L5klF+OnVxRqoGuG5ievOE0lwo7e Bd2B/vK4cDJo39JPp9Nj2mr++VA40kXEczRVkq9eNEalnqtjr/CaHGNBKNTXHCiIf5r0 KmjxSPkUffkpgoNJ7JAjG1BDRivEBTjv1txE97iayylP4Ai3rLR/fgZrFS54Eo1NBnkd DfccyJ7b0V9cmEAiA9dB+G4UaalYzFBb7DCgaUXLZumHZgFGH9R53zKtxtSVmgvYvM1I Nkag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EHuZ6eFZRvfRmkMnFuprTuhpXuWMEXs6tB5XaMPLb0k=; b=Mv/cwedq3MraKHBzY+aOjaFlrSRROSXwZLa3axBjRMhUj0jIvg5g6eX6wppFWRVV7W jy+R8QOcIKD7mw51YKsCPvJcEIFMmtJDHvvJU1kilQ60AqPfyJbYijFJGU2tuzPOStbB 8F7/A1Y+bLWs/B8cA9+Z4TIDwv0MQFsTqMP+sG5ghOTPoTPKKKxvadbtVqbeRwZD3msi kafhHBdvL0Ms8pq4ZtV2J3TrIrnTCqiIQQ2sOI35aiZdIx0Nt9Cp23l24Ba2P32ul0+u 8VMGz6ANZV0wlgxubo3ItC4M/l8VOEJ1r64C5CsxPNqqr05XtbSjgrZ5qBR9vQsoluFL wOdQ== X-Gm-Message-State: AA+aEWbX3crcmyHyJlITt2FSTZYgDL5C4adx1sUaYkQVuf+loK9hZGkO xT1OGyqih7Bv8WgNzbZro7152Whbb3cL79/BqF8= X-Google-Smtp-Source: AFSGD/XgJH8XSx2MiZe/h+nIvSlb4xZEjO7Z2Axlb/UDty5l0SZa5nrRoNn7JyJB3mZs100WEcUaJakr7NrhzJdPNOw= X-Received: by 2002:a19:4345:: with SMTP id m5mr15246469lfj.142.1545322498584; Thu, 20 Dec 2018 08:14:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 20 Dec 2018 10:14:45 -0600 Message-ID: To: Christopher Wood Cc: The IESG , secdir@ietf.org, draft-ietf-nfsv4-mv0-trunking-update@ietf.org Content-Type: multipart/alternative; boundary="00000000000097743f057d766e69" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-nfsv4-mv0-trunking-update-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 16:15:04 -0000 --00000000000097743f057d766e69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Authors, On Tue, Dec 11, 2018 at 8:16 AM Christopher Wood < christopherwood07@gmail.com> wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > The summary of my review is: Ready with nits. > I believe these are the only Last Call comments I've seen on your draft, and the Last Call period has ended. Could you respond to Christopher, and (if necessary) submit a revised draft= ? Thanks! Spencer (D) > This document is in great shape and very well written. Most of my > comments are editorial in nature aimed at helping improve readability of > the document. Please let me know if you=E2=80=99ve further questions, > comments, or concerns. > > - Section 3, fourth bullet: Regarding =E2=80=9C[NFSv4.1] distinguishes tw= o > (see [RFC5661]),=E2=80=9D would it be possible to provide the two types o= f > trunking relationships inline? Although this document is meant to > supplement existing work, I do think it would help improve readability > and minimize cross-referencing. > - Section 5.1, fifth bullet: Rather than specify that addresses =E2=80=9C= MUST > provide a way of connecting to a single server,=E2=80=9D could we specify > desired client behavior if this does not happen? I do not know how often > such misconfigurations occur, though it seems prudent to provide > guidance in case it does. > - Section 5.2, sixth bullet: It might be worth pointing to the amended > Security Considerations section, which contains relevant text regarding > DNSSEC validation for host name entries. I left a note here while > reading only to discover it was addressed later on. > - Section 5.2.3: Are clients allowed to race connection attempts across > all types available? The text implies that this must be done > sequentially, which seems unnecessarily prohibitive. > - Section 5.2.5, third paragraph, first sentence: Perhaps a simpler way > to write this is something akin to =E2=80=9Cfs_locations cannot point to > alternate locations until data propagation occurs=E2=80=9D? > > Best, > Chris > > --00000000000097743f057d766e69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Authors,

On Tue, Dec 11, 2018 at 8:16 AM Christopher Wood &= lt;christopherwood07@gmail.c= om> wrote:
This document is in great shape and very well written. Most of my <= br> comments are editorial in nature aimed at helping improve readability of the document. Please let me know if you=E2=80=99ve further questions,
comments, or concerns.

- Section 3, fourth bullet: Regarding =E2=80=9C[NFSv4.1] distinguishes two =
(see [RFC5661]),=E2=80=9D would it be possible to provide the two types of =
trunking relationships inline? Although this document is meant to
supplement existing work, I do think it would help improve readability
and minimize cross-referencing.
- Section 5.1, fifth bullet: Rather than specify that addresses =E2=80=9CMU= ST
provide a way of connecting to a single server,=E2=80=9D could we specify <= br> desired client behavior if this does not happen? I do not know how often such misconfigurations occur, though it seems prudent to provide
guidance in case it does.
- Section 5.2, sixth bullet: It might be worth pointing to the amended
Security Considerations section, which contains relevant text regarding DNSSEC validation for host name entries. I left a note here while
reading only to discover it was addressed later on.
- Section 5.2.3: Are clients allowed to race connection attempts across all types available? The text implies that this must be done
sequentially, which seems unnecessarily prohibitive.
- Section 5.2.5, third paragraph, first sentence: Perhaps a simpler way to write this is something akin to =E2=80=9Cfs_locations cannot point to alternate locations until data propagation occurs=E2=80=9D?

Best,
Chris

--00000000000097743f057d766e69-- From nobody Thu Dec 20 08:18:46 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8126512894E; Thu, 20 Dec 2018 08:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 ncXs_di-7PvH; Thu, 20 Dec 2018 08:18:37 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 253B21274D0; Thu, 20 Dec 2018 08:18:37 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBKGE1jp083838; Thu, 20 Dec 2018 16:18:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=4siqX0oagqMU878NZ62o+dDcUu1FUewrFt0gU3t4SuI=; b=LVO7qwThXgP9k5eTN+kAWhVeKTHeOrMICxeAtNG07tVKasJpfOJ5hiJiNTxyd/Mk8I1j Wuh8exsotvJgBV+PvRuuIC7N/EmXC+IIpKi01Uy0+Ip0G70OHs+sGayUsEXZik4NOEqp dlyrNmzNtN3eI869laHYivascR732IIvhfsHsSQlBuzIUY3eH2riWL02iDJ6wHZVZw55 9JbLyVgmhOBvqxf0bOHcwPoSpItqjpI4y79ZnURebn10ec23ybgIC3g1OMhqdqw4B549 7jdYsXl179SPt2opWsConNojJqZr2Goh+83dzHpq2U4EQeX45W1YVZVvIt9EOPAQHq9n KQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2pfn1yxytx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Dec 2018 16:18:34 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wBKGITwq005376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Dec 2018 16:18:29 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wBKGISIX012381; Thu, 20 Dec 2018 16:18:28 GMT Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Dec 2018 08:18:28 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Chuck Lever In-Reply-To: Date: Thu, 20 Dec 2018 11:18:27 -0500 Cc: Christopher Wood , The IESG , secdir@ietf.org, draft-ietf-nfsv4-mv0-trunking-update@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <10202A1E-95D3-4C73-910E-526C644E200F@oracle.com> References: To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9113 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812200132 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-nfsv4-mv0-trunking-update-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 16:18:39 -0000 > On Dec 20, 2018, at 11:14 AM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Authors, >=20 > On Tue, Dec 11, 2018 at 8:16 AM Christopher Wood = wrote: > Hello, >=20 > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the = IESG.=20 > These comments were written primarily for the benefit of the = security=20 > area directors. Document editors and WG chairs should treat these=20 > comments just like any other last call comments. >=20 > The summary of my review is: Ready with nits. >=20 > I believe these are the only Last Call comments I've seen on your = draft, and the Last Call period has ended.=20 >=20 > Could you respond to Christopher, and (if necessary) submit a revised = draft? I actually hadn't seen any comments until now! Thanks for forwarding this. I will huddle with Dave and submit a revised draft within the next week. > Thanks! >=20 > Spencer (D) > =20 > This document is in great shape and very well written. Most of my=20 > comments are editorial in nature aimed at helping improve readability = of=20 > the document. Please let me know if you=E2=80=99ve further questions,=20= > comments, or concerns. >=20 > - Section 3, fourth bullet: Regarding =E2=80=9C[NFSv4.1] distinguishes = two=20 > (see [RFC5661]),=E2=80=9D would it be possible to provide the two = types of=20 > trunking relationships inline? Although this document is meant to=20 > supplement existing work, I do think it would help improve readability=20= > and minimize cross-referencing. > - Section 5.1, fifth bullet: Rather than specify that addresses = =E2=80=9CMUST=20 > provide a way of connecting to a single server,=E2=80=9D could we = specify=20 > desired client behavior if this does not happen? I do not know how = often=20 > such misconfigurations occur, though it seems prudent to provide=20 > guidance in case it does. > - Section 5.2, sixth bullet: It might be worth pointing to the amended=20= > Security Considerations section, which contains relevant text = regarding=20 > DNSSEC validation for host name entries. I left a note here while=20 > reading only to discover it was addressed later on. > - Section 5.2.3: Are clients allowed to race connection attempts = across=20 > all types available? The text implies that this must be done=20 > sequentially, which seems unnecessarily prohibitive. > - Section 5.2.5, third paragraph, first sentence: Perhaps a simpler = way=20 > to write this is something akin to =E2=80=9Cfs_locations cannot point = to=20 > alternate locations until data propagation occurs=E2=80=9D? >=20 > Best, > Chris >=20 -- Chuck Lever From nobody Thu Dec 20 10:48:11 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF482130E6C for ; Thu, 20 Dec 2018 10:48:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154533168890.19132.3689338712754326984.idtracker@ietfa.amsl.com> Date: Thu, 20 Dec 2018 10:48:08 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 18:48:09 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-12-20 Reviewer LC end Draft Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-08 For telechat 2019-01-10 Reviewer LC end Draft Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-13 Steve Hanna 2018-12-18 draft-ietf-extra-sieve-fcc-08 Last calls: Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-10 Daniel Gillmor 2018-03-19 draft-gutmann-scep-11 Phillip Hallam-Baker 2018-12-18 draft-ietf-rtgwg-spf-uloop-pb-statement-08 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Charlie Kaufman 2018-12-24 draft-ietf-6lo-deadline-time-03 Scott Kelly 2018-12-21 draft-ietf-sipcore-sip-push-21 Tero Kivinen 2018-12-28 draft-ietf-jmap-core-12 Watson Ladd 2018-12-27 draft-ietf-pce-wson-rwa-ext-10 Barry Leiba 2018-12-27 draft-ietf-lisp-rfc8113bis-01 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-10 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-19 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Derek Atkins 2018-12-05 draft-ietf-dnssd-mdns-relay-01 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-02 Christopher Wood 2018-12-04 draft-ietf-tsvwg-transport-encrypt-03 Next in the reviewer rotation: Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Kathleen Moriarty Russ Mundy From nobody Thu Dec 20 11:13:04 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3EC130F05; Thu, 20 Dec 2018 11:12:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba To: Cc: ietf@ietf.org, draft-ietf-lisp-rfc8113bis.all@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154533317061.19019.3538327801383303400@ietfa.amsl.com> Date: Thu, 20 Dec 2018 11:12:50 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 19:12:51 -0000 Reviewer: Barry Leiba Review result: Ready Nothing to see here: this document is straightforward and well done, and is ready to publish. It's a simple change from Experimental to Standards Track with some minor updates along the way. From nobody Fri Dec 21 08:56:49 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE1F12894E; Fri, 21 Dec 2018 08:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 2qhaaDkjn0Al; Fri, 21 Dec 2018 08:56:38 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE3D130DFE; Fri, 21 Dec 2018 08:56:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1F4E0E2047; Fri, 21 Dec 2018 11:56:34 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 21636-09; Fri, 21 Dec 2018 11:56:33 -0500 (EST) Received: from securerf.ihtfp.org (unknown [8.46.76.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 703BBE2044; Fri, 21 Dec 2018 11:56:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1545411393; bh=QfHInGnY3E9j90ypGdCkHmcQGT6slvqB/WihuRXeK54=; h=From:To:Cc:Subject:Date; b=metB0QUrXMEXG3NbWbpgNdKc+Wvmed8DlUphxQrptP5qFQX93OB5xZ0I3GFkvDDgP IXYocQ/BEhWztFZHrNL2YUdaSJ0m+QRTQCcicCQyqBaUgUo8Ra0aByVUl14ZihteSJ N/JWbAjMw+PcBqndCty3x2vNfGvC9AHkzl1RyEL0= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id wBLGuFO9006576; Fri, 21 Dec 2018 11:56:15 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Cc: dnssd-chairs@ietf.org, mellon@fugue.com, cheshire@apple.com Date: Fri, 21 Dec 2018 11:56:12 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [secdir] sec-dir review of draft-ietf-dnssd-mdns-relay-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 16:56:41 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to publish, but nits remain Details: * The specific authorization details between the Client and Relay is elided. Specifically, how does a proxy get configured for specific client connections? The spec does say it needs to get configured (section 9), and talks at length about configuring the relay for the available networks, but doesn't say much else about how to authorize clients. * Can a Relay be a client to another Relay? It's unclear what would happen if someone tried to configure it that way; the specification does not talk to that possibility (or prohibit it), as far as I can tell. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Dec 21 10:37:07 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6EF12875B for ; Fri, 21 Dec 2018 10:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 lgh-FeRJ74ek for ; Fri, 21 Dec 2018 10:36:59 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A3B1277BB for ; Fri, 21 Dec 2018 10:36:57 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id t33so6753601qtt.4 for ; Fri, 21 Dec 2018 10:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vScUtWcO63Kk6fgzR6OtX5YktEufXekPMkVqsre7SbE=; b=qUzg4LKu5skBWBYuMSdw7l7foBfk9i4wMTTfoohaNkv0/TELme+lnpFqLUo/VLziH2 WgXDBNu6j3v8nnJx/NxV04VAI1rWm0TCWubiUwEt5A7m7J7n3kLxeHe9Ls9/lfmHEmtE svEUJ7XZoO4UTSOpK7cVsMcVV4lFjG4ApTDlmOXWYA6hLB2AXz8rlW9DQWtGBr3XSXkc K0KtoyBqWMFdCa4reVxGYKKMV3wMJS9sb67IVuqWndZJGc0JwvEywIg03owT5bOJxRui ohlNb5GSdXhVwX/ZLfe5I2Yl9c+HFS97oBCWkK7tTj/MTJOA6cZhHYAi0VmVD/Q1aNX+ X1Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vScUtWcO63Kk6fgzR6OtX5YktEufXekPMkVqsre7SbE=; b=aAIj7oe7hXuk6GH6nmNgvK8w8xEISF6bVv7aMZSKvHYelGvhI8XdkgZ9H42o9p2awb UgGDMfJXbRyy65wtVfiPTp0Y63CqWsVmPosqZFiDPNvnqNKlkGxTAi2t9Ho1EpuriJ5t +KFUpkNI0h1lWrQnXpsvmPiHLNPxkr+3d391IEZTCYCfVPmOgr3DOpPo+z2H4/OdGyK3 Ik97J+GEhul/YtkoEIDENQLaVzZCpNsDp/tc/NpQkW+dEBVpxTRVMaR2gw4yJKtV7Seo lQ/8m1PAHnOcWlyh0kXIqxd1zNSGci8S6gdYdwvBq+V59j8ALK/hFMSSPNMzXgTt7hqP 0FSw== X-Gm-Message-State: AJcUukfpnkTPBEzjaKMXrcQ8pXwNHQh7xHXKnRBQscT9+5gPnXB1RzTA xWSEOLaUMhjWIt/pJ5T2+WS7nV6MPVyHFVq8fcclQQ== X-Google-Smtp-Source: ALg8bN55KRLl38VW5jUVOA9MaF2CjyMW2SEP0pIeS3ZLYLU4cgGbEbu0nLsbpeTMKzN7Kdv7wHPMVGJxXjzjsjad8Mo= X-Received: by 2002:aed:2be7:: with SMTP id e94mr2871309qtd.203.1545417416298; Fri, 21 Dec 2018 10:36:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Fri, 21 Dec 2018 13:36:20 -0500 Message-ID: To: Derek Atkins Cc: The IESG , Security Directorate , dnssd-chairs@ietf.org, Stuart Cheshire Content-Type: multipart/alternative; boundary="00000000000020e765057d8c8893" Archived-At: Subject: Re: [secdir] sec-dir review of draft-ietf-dnssd-mdns-relay-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 18:37:01 -0000 --00000000000020e765057d8c8893 Content-Type: text/plain; charset="UTF-8" Thanks, Derek! These are both good points. I think that the authorization question is a bit hard to answer because it depends on how this is used, but we have a clearer picture of that now than we did when the document was last updated, so I'll see if I can address this in a useful way. I think it doesn't really make sense for a relay client to also be a relay server for the same link(s). You could argue that there might be a case where a single host could be both a relay client and a relay server, but I am not coming up with any use cases for that off the top of my head. So I think some clarification might be in order. I would be inclined to say that it's possible for a relay client and relay server to coexist on the same host, but that it doesn't make sense for a relay server to serve links for which it's a client. I guess the one use case that is now occurring to me is that it might be useful when there isn't end-to-end connectivity from the client of this server to the server it's a client of. On Fri, Dec 21, 2018 at 11:56 AM Derek Atkins wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written with the intent of improving > security requirements and considerations in IETF drafts. Comments > not addressed in last call may be included in AD reviews during the > IESG review. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Summary: > > * Ready to publish, but nits remain > > Details: > > * The specific authorization details between the Client and Relay is > elided. Specifically, how does a proxy get configured for specific > client connections? The spec does say it needs to get configured > (section 9), and talks at length about configuring the relay for the > available networks, but doesn't say much else about how to authorize > clients. > > * Can a Relay be a client to another Relay? It's unclear what would > happen if someone tried to configure it that way; the specification > does not talk to that possibility (or prohibit it), as far as I can > tell. > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > --00000000000020e765057d8c8893 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Derek!=C2=A0 =C2=A0These are both good points.=C2= =A0 =C2=A0I think that the authorization question is a bit hard to answer b= ecause it depends on how this is used, but we have a clearer picture of tha= t now than we did when the document was last updated, so I'll see if I = can address this in a useful way.=C2=A0 =C2=A0I think it doesn't really= make sense for a relay client to also be a relay server for the same link(= s).=C2=A0 =C2=A0You could argue that there might be a case where a single h= ost could be both a relay client and a relay server, but I am not coming up= with any use cases for that off the top of my head.=C2=A0 =C2=A0So I think= some clarification might be in order.=C2=A0 =C2=A0I would be inclined to s= ay that it's possible for a relay client and relay server to coexist on= the same host, but that it doesn't make sense for a relay server to se= rve links for which it's a client.=C2=A0 =C2=A0I guess the one use case= that is now occurring to me is that it might be useful when there isn'= t end-to-end connectivity from the client of this server to the server it&#= 39;s a client of.

On F= ri, Dec 21, 2018 at 11:56 AM Derek Atkins <derek@ihtfp.com> wrote:
Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written with the intent of improving
security requirements and considerations in IETF drafts.=C2=A0 Comments
not addressed in last call may be included in AD reviews during the
IESG review.=C2=A0 Document editors and WG chairs should treat these
comments just like any other last call comments.

Summary:

* Ready to publish, but nits remain

Details:

* The specific authorization details between the Client and Relay is
=C2=A0 elided.=C2=A0 Specifically, how does a proxy get configured for spec= ific
=C2=A0 client connections?=C2=A0 The spec does say it needs to get configur= ed
=C2=A0 (section 9), and talks at length about configuring the relay for the=
=C2=A0 available networks, but doesn't say much else about how to autho= rize
=C2=A0 clients.

* Can a Relay be a client to another Relay?=C2=A0 It's unclear what wou= ld
=C2=A0 happen if someone tried to configure it that way; the specification<= br> =C2=A0 does not talk to that possibility (or prohibit it), as far as I can<= br> =C2=A0 tell.

-derek

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtf= p.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant
--00000000000020e765057d8c8893-- From nobody Sun Dec 23 20:08:14 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B882A130E7A; Sun, 23 Dec 2018 20:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com 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 ecCpLIuxUXfH; Sun, 23 Dec 2018 20:08:03 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001018.outbound.protection.outlook.com [40.92.1.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0D7130E78; Sun, 23 Dec 2018 20:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/PfbyMMKXCqhW5ZXXC4AmMkxu+uFrmOHhcdqScnA2NI=; b=qSUH0l1uT2nKBYWZOMQYnyeWfsOHDE+biwDpibiLq7cJ8iLQ8HzcaEk115uVVY31R9/sPIvo7peBYhk2rzveLvkGUXJfyHhjEC4IAUp0HLAiPuoxnOd2Hl+EdeKcbzUORiE2zpPupM5fMhI3WTA8SFRspL8vmBtCzmxY8QyZatqbl5nh7cyTg37TQ5cipvfCJBVtVzu/O2yJuZlTgAA0iOTiEE4quSuu5RHVw0L1AXxdDKhNv7M4r52+zp2J058d6MWiv1XvheUSeefiHi7EUvsew2z+X6e+isJwEFm3aHz4UoBYOV6HTHeD/srx/U4HA82ES5ctMu+6XTyZits8xQ== Received: from SN1NAM01FT013.eop-nam01.prod.protection.outlook.com (10.152.64.52) by SN1NAM01HT121.eop-nam01.prod.protection.outlook.com (10.152.64.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13; Mon, 24 Dec 2018 04:08:02 +0000 Received: from DM6PR04MB5099.namprd04.prod.outlook.com (10.152.64.58) by SN1NAM01FT013.mail.protection.outlook.com (10.152.64.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Mon, 24 Dec 2018 04:08:02 +0000 Received: from DM6PR04MB5099.namprd04.prod.outlook.com ([fe80::d542:8c2e:1af9:563f]) by DM6PR04MB5099.namprd04.prod.outlook.com ([fe80::d542:8c2e:1af9:563f%4]) with mapi id 15.20.1446.026; Mon, 24 Dec 2018 04:08:02 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6lo-deadline-time.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-6lo-deadline-time-03 Thread-Index: AQHUmz3wn28DKZa1QE+QITpNT8nKbQ== Date: Mon, 24 Dec 2018 04:08:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:CE572986C295EA9B3C1EFCC128D6B15CBEBFA731D35AB28F58AAC5AB4D0F7D8E; UpperCasedChecksum:D66C5A5398C209A11A4E3E57E65D0AE7037EE74861081D51476571B137AD0058; SizeAsReceived:7112; Count:43 x-tmn: [dcjZenGzw/VahaTZpOn23WUGBJyxL0IeQczsYBnspn5MYUMl8tS4MrRW741RAjz3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM01HT121; 6:DSUpremx5Or7wGQZ3VA0WLirfbpA3btWZEAvsWQumYAxctWXuLiVBLy5Mcmxix+9v/ep6clXJvJ8buxYVXbwz/f4dHAMeboXe7ih6dLnpOCjFjaa5HEUg3fW1kSs4dH18pNbibc83tWTR9Y5D19R0hjbseU6lgQplSeL5QZM4TbZRgGn0za3mzDaAvLBPgv5hF5OfJOHlfnthL5wxhsq6J0gxyN5eFyOSbqThwm4I4QFTsVBIUL2pTPRQFsMO6L3m9/PszEoVogUCobzBdaCwNKyV4d+2qUGMBael2+EDGaMyj9T33SfJ8dAnr6OaHrTcDhwKqOIErgqQDaSK+k50eyP/KSuVqZSreUVwqOPxOn7eczQQR464xdoudHezo9tCb2YshsxBHEhkSnBcyK0sBJ/tpF7C847WaJ/RMqU5zLfwWxyRgihSHe6oe/x9lMYT9XwoKSRHtaAjAEVfuoA7g==; 5:wNEE1TpBNQthOC99s73qS8TFtjv75dsDewkPaLqTl9n4pFdBp+RGmfihi6w47AbZNRFPZGOUDzegm7nWcPCUMYuKyE9A2aZn5fzLbx7rfgyUiypJYhbUWkCmQkqVhYJJEnVeQlQRB3pVbxWm38UEQI7ww7csqZLpw9oE/E8nBQY=; 7:iedQ6Upnctd/yn+Yc36G6n3QQiE3febUhnCJdV9tzfK2IXfO1qnIFNPu5LhW/90gowD16zN8gP0/0hMA2cScc6MymIqP08AHyxDOje3tptzUgXxmGqKExwiv3717uSp09vQncJ7X9+5D1ZbNL5os6Q== x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM01HT121; x-ms-traffictypediagnostic: SN1NAM01HT121: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM01HT121; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT121; x-microsoft-antispam-message-info: fUE9p9e5MK0cUPh1k5JgB0atDjrMqw8DdZjjxshep6VkkoStIoM1ZOvhMMX7/cm8 Content-Type: multipart/alternative; boundary="_000_DM6PR04MB5099527AC26CD484D373FA09DFBB0DM6PR04MB5099namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 9a4e3081-9524-43cf-bfc3-dcaef82d5da1 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c766fa8-ef47-4039-d8d3-08d6695565cf X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 9a4e3081-9524-43cf-bfc3-dcaef82d5da1 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2018 04:08:01.9489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT121 Archived-At: Subject: [secdir] Secdir review of draft-ietf-6lo-deadline-time-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2018 04:08:06 -0000 --_000_DM6PR04MB5099527AC26CD484D373FA09DFBB0DM6PR04MB5099namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document specifies a new optional extension in 6LoRHE headers to be us= ed to do fine grained time tracking of packets traversing a network. It sup= ports two functions: tracking the timing of transiting packets for the purp= ose of performance analysis and diagnostics, and delivery deadline enforcem= ent where the source instructs the network to drop a packet if it cannot be= delivered within a specified time bound. This avoids network congestion by= quickly discarding packets that are going to be useless by the time they a= re delivered. One of the challenges facing this design is maintaining tight clock synchro= nization between packet forwarding devices. The design assumes that sets of= such devices are held in tight synchronization through unspecified mechani= sms. These groupings are called "time zones". It also calls for the origina= tion time and delivery deadline fields be updated when a packet transitions= between "time zones" (which assumes that packet forwarding devices on sepa= rating two time zones be aware of the time difference between them so that = it can update those fields). The issues raised below may be covered in companion documents, but they are= what occurred to me while reviewing this one. Security issues: Section 6 specifies that when one of these packets is encapsulated and sent= through an IPv6 in IPv6 tunnel, and tunnel exit the time fields must be co= pied from the outer header to the inner header before the packet is forward= ed on. This would be true of any form of encapsulation, in particular inclu= ding IPsec tunnelling. Many time synchronization protocols - particularly those that target subsec= ond synchronization - assume they are running on a secure network (or that = attackers would not be motivated to mess up time synchronization). If the t= ime synchronization between the packet forwarding devices were to be broken= such that there was substantial drift between the devices, that could be u= sed as a denial of service attack if that could be used to cause most or al= l data packets to be discarded as expired. Non-security issues: The length of the time fields is specified in the OTL and DTL headers to ha= ve a length of between 1 and 8 octets. I could not tell from the spec wheth= er it was intended that the sender was supposed to pick a size big enough t= o represent the entire time field or whether it was OK to pick a smaller si= ze and place the low order bits of the time in the field. Placing the low o= rder bits there would normally work, though it makes size comparisons more = complex (particularly in cases where there are just barely enough bits to a= void wrapping before the packet expires). I was initially confused by the presence of two fields OT and DT when one s= hould be sufficient to enforce packet expiration. Reading between the lines= of the spec, I eventually concluded that only the DT field was intended to= be used for this purpose and the OT field was intended to be used to track= delivery performance and is not used in the calculation of packet lifetime= . Assuming I have that right, it would be good if it were more explicit in = the document. The bit bummer in me was offended by the fact that the TU and EXP fields ha= d two different ways of representing 1 second time granularity (TU=3D00/EXP= =3D110 and TU=3D01/EXP=3D000). Given that time granularity greater than 10 = seconds is never likely to be needed, the need for the TU=3D01 code point i= s questionable, but at the least perhaps the spec should say which is the p= referred encoding. I also could not tell whether the encoding was expected = to be constant within a Time Zone (in which case the fields would not be ne= cessary in every packet) or whether packet relay nodes were expected to can= onicalize the time representation whenever it parses a packet. But this is = only a matter of taste. --_000_DM6PR04MB5099527AC26CD484D373FA09DFBB0DM6PR04MB5099namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's ongo= ing effort to review all IETF documents being processed by the IESG.  = These comments were written primarily for the benefit of the security area = directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


This document specifies a new optional extension in 6LoRHE headers to be= used to do fine grained time tracking of packets traversing a network. It = supports two functions: tracking the timing of transiting packets for the p= urpose of performance analysis and diagnostics, and delivery deadline enforcement where the source instructs = the network to drop a packet if it cannot be delivered within a specified t= ime bound. This avoids network congestion by quickly discarding packets tha= t are going to be useless by the time they are delivered.


One of the challenges facing this design is maintaining tight clock sync= hronization between packet forwarding devices. The design assumes that sets= of such devices are held in tight synchronization through unspecified mech= anisms. These groupings are called "time zones". It also calls for the origination time and deliver= y deadline fields be updated when a packet transitions between "time z= ones" (which assumes that packet forwarding devices on separating two = time zones be aware of the time difference between them so that it can update those fields).


The issues raised below may be covered in companion documents, but they = are what occurred to me while reviewing this one.


Security issues:


Section 6 specifies that when one of these packets is encapsulated and s= ent through an IPv6 in IPv6 tunnel, and tunnel exit the time fields must be= copied from the outer header to the inner header before the packet is forw= arded on. This would be true of any form of encapsulation, in particular including IPsec tunnelling.


Many time synchronization protocols - particularly those that target sub= second synchronization - assume they are running on a secure network (or th= at attackers would not be motivated to mess up time synchronization). If th= e time synchronization between the packet forwarding devices were to be broken such that there was substantia= l drift between the devices, that could be used as a denial of service atta= ck if that could be used to cause most or all data packets to be discarded = as expired.


Non-security issues:


The length of the time fields is specified in the OTL and DTL headers to= have a length of between 1 and 8 octets. I could not tell from the spec wh= ether it was intended that the sender was supposed to pick a size big enoug= h to represent the entire time field or whether it was OK to pick a smaller size and place the low order bits o= f the time in the field. Placing the low order bits there would normally wo= rk, though it makes size comparisons more complex (particularly in cases wh= ere there are just barely enough bits to avoid wrapping before the packet expires).

I was initially confused by the presence of two fields OT and DT when on= e should be sufficient to enforce packet expiration. Reading between the li= nes of the spec, I eventually concluded that only the DT field was intended= to be used for this purpose and the OT field was intended to be used to track delivery performance and is = not used in the calculation of packet lifetime. Assuming I have that right,= it would be good if it were more explicit in the document.


The bit bummer in me was offended by the fact that the TU and EXP fields= had two different ways of representing 1 second time granularity (TU=3D00/= EXP=3D110 and TU=3D01/EXP=3D000). Given that time granularity greater than = 10 seconds is never likely to be needed, the need for the TU=3D01 code point is questionable, but at the least perh= aps the spec should say which is the preferred encoding. I also could not t= ell whether the encoding was expected to be constant within a Time Zone (in= which case the fields would not be necessary in every packet) or whether packet relay nodes were expected to = canonicalize the time representation whenever it parses a packet. But this = is only a matter of taste.


--_000_DM6PR04MB5099527AC26CD484D373FA09DFBB0DM6PR04MB5099namp_-- From nobody Mon Dec 24 19:43:06 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDACF12E7C1; Mon, 24 Dec 2018 19:42:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd To: Cc: draft-ietf-pce-wson-rwa-ext.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154570936991.12911.1627288364179668736@ietfa.amsl.com> Date: Mon, 24 Dec 2018 19:42:49 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pce-wson-rwa-ext-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2018 03:42:50 -0000 Reviewer: Watson Ladd Review result: Ready Dear all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. This is a document in an area I know almost nothing about. It appears to be about an internal mechanism for configuring label based routing in an optical network to minimize the number of optical to electrical transitions along the route. I am perhaps a bit confused as to why the PCC would specify the constraints on wavelengths on hops that are not the end ones: if the packets must flow from A to B, shouldn't the PCE be the one to decide how to do that using all the resources available? Merry Christmas! Sincerely, Watson Ladd From nobody Wed Dec 26 17:02:24 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E14127B4C; Wed, 26 Dec 2018 17:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Zx1cNEkEd4Us; Wed, 26 Dec 2018 17:02:18 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957971286D9; Wed, 26 Dec 2018 17:02:15 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id w18so22841305ite.1; Wed, 26 Dec 2018 17:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=M7s2xNaisXIzDaosLkRaiAcILKloixThoY4/ck4cRI0=; b=u3z703XPwfk+AZZPKj4/7zOQ6UOVzZq3LUCWE/QGK8ssNY3mf1+TMI0rNHim2idxtO Q3Vc0b4Wtoe/0XVxTd6fbLoY2e1swmjG5BHpIrxbEWa+Hwhgb66siEiZ7zZyosnG8lXX lhNiAh83LOpaonbkcTnz+p1HCgI+Ltx08r2Wi53769NFxUcUmJScnRk1EHejaDhcbJw7 aMqMUoOOwCO0t5yxlHn4yHOnwgxPDAvxa9ieK3/5phzJo8CfPnmpupgJwwXoGaEpS97Y JMe+BGbaxkrA5VsjNwN8Zm4Fw3L64ZmlbYFIGiVwgCe2MdmQK3Vx6FDBu8tCRJzSFajd +y6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=M7s2xNaisXIzDaosLkRaiAcILKloixThoY4/ck4cRI0=; b=cif/g642hEF5pEiLePkBkyb15UqmyocAh10tmKuo80esYiUUbHPC3G8T22pjvCnDhL OR3E9r3U4sgqmIPKvgzgwZeq5XdzOBNgFjFvKYHGV1Xv3GwAtJ3n1icwQCyuJmXO+eOZ cKSCp+kIlp9dKdEDStVEvvTjFeL8V3/3OoR7yqCx9PK389kgrH31RJWHQif8kKwf9NAv o3kuLx8JlxcwyW2Rch1iLaN34NBWDQl1M7sOPmCpRVz/6e+ZERrv5qjMpmV5mvTfQN76 QtuLBa2CHjCzQKNuu9cdpe0IJEecEIYEWZo3qSUyv37jYiz2DPYKxW/1Si1YoKO/yrD8 vSnQ== X-Gm-Message-State: AA+aEWa7ELdD5AIzfLAMgV/+VTJ5MmCMk9MsvhfhEOxkyU7dxInoPH+v eLESV5ujKJ2dsjBt/UzbC02I5lgcHjIR82oVgMxF9n5W X-Google-Smtp-Source: AFSGD/XzkDDooDbFC2NyxzwG2oUHwlqcl3w8zKEa0SLiVlCsJAns9RoKfBvKvDNLFvUJwaWdGrrKG6ilhrToXWuvKTs= X-Received: by 2002:a02:9d27:: with SMTP id n36mr13371058jak.30.1545872534075; Wed, 26 Dec 2018 17:02:14 -0800 (PST) MIME-Version: 1.0 From: Christopher Wood Date: Wed, 26 Dec 2018 17:02:02 -0800 Message-ID: To: secdir@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-transport-encrypt.all@ietf.org, The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [secdir] Secdir early review of draft-ietf-tsvwg-transport-encrypt-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 01:02:22 -0000 Reviewer: Christopher Wood Review result: Has issues Review of draft-ietf-tsvwg-transport-encrypt-03 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of my review is: Has issues This document lays out a comprehensive assessment of the impact of transport (header) encryption on network users and operators. Motivation for and dependencies on cleartext transport information is clear. Yet, while this information is all useful, I observe a couple issues with the document in its current state that might be worth addressing. For brevity, I=E2=80=99ve enumerated them below. 1. While the document states that discouraging encryption is not a goal, several sections seem to encourage or otherwise promote various workarounds for transport encryption that seem in conflict with the goal of encryption. For example, in Section 3.1.3, encouraged use of IPv6 Network Flow Labels as a way of marking transport flows seems in conflict with QUIC=E2=80=99s use of rotating connection identifiers (as a means of helping unlinkability). Security and privacy motivated QUIC=E2=80= =99s aggressive use of encryption, and it seems that this privacy perspective is not given enough attention. Are any transport protocol implementations setting this information at the network layer? As another example, consider Section 6.1, wherein the document discusses privacy implications of sharing data. It states that protocols which =E2=80=9Cexpose the state information used by the transport protocol in the= ir header information ... provide an incentive for the sending endpoint to provide correct information.=E2=80=9D I=E2=80=99m not sure this is accur= ate given the outcome of the QUIC Privacy Design Team and follow up work from the spin bit folks. Recall that one aspect studied by the Design Team was whether or not knowledge of RTT information was sufficient to geolocate a client. The analysis from Brian and Mirja [1] shows that this is a difficult, though possibly feasible, task, which seems contrary to the point that endpoints would have incentives to make it available. Moreover, several entities showed interest in greasing the spin bit to prevent ossification and, as a result, promote endpoint privacy. Regardless of the motives, it seems that clients do not have incentives to send accurate signaling information in all cases. 2. Parts of the document seem seemingly suggest that changes in network operator tooling is prohibitively costly and could possibly be considered a blocking factor when deciding which transport headers (if any) to encrypt. In particular, the Conclusion states that if the =E2=80=9Ccurrently deployed tools and methods are no longer relevant, then = it may no longer be possible to correctly measure performance.=E2=80=9D Perhap= s the document should also state that an alternative outcome is that mechanisms, policies, and tooling change to adapt to transport encryption. While the needs of network operators may be real, they do not seem to trump security and privacy concerns of endpoints. Relatedly, is it worth encouraging research and development into techniques that allow endpoints to voluntarily share this information? As an extreme example, it could be possible to apply differential privacy techniques to diagnostic traceroute packet traces as a way of helping operators debug network issues. (The proposed IRTF PEARG indicated some interest in this direction.) 3. A seemingly large missed opportunity in this document is the discussion of TLS 1.3 deployment obstacles [2] and their impact on QUIC=E2=80=99s design decisions [3, Section 3.3]. There are many places whe= re discussion of the TLS ossification problems would be appropriate, e.g., in Section 2 fourth paragraph describing shortcomings of integrity-only protections, Section 2 seventh paragraph describing greasing, and Section 4, first bullet. Increased encryption should help prevent invariant violation, which caused great pain when deploying TLS 1.3. Perhaps a clear statement of protocol invariants would have mitigated the deployment problems, though it happened nevertheless. That said, as stated in the document, encryption as a mitigation may not prevent ossification entirely, as network operators may come to rely on traffic patterns or other heuristics. (Related to TLS 1.3, it might be worth including TLS over TCP as a first class citizen in the document given its increase in use.) 4. The document focuses on transport header encryption and its impact on network operators. Perhaps it might be worth generalizing this to focus the impact of exposing explicit signals to the network, with encryption as one way of hiding such explicit signals. Implicit signals include those one can glean from connection metadata, e.g., traffic patterns, size, and timing information. 5. There=E2=80=99s a lot of redundant content spread across the document. A significant amount of information could be removed without loss of material, clarity, or continuity, and doing so would likely benefit the reader. Specifically, Sections 3.2.2, 3.2.3, 3.3, parts of 3.2.4 (first couple paragraphs), 5 (first two paragraphs), 6.3 (second paragraph), and 6.4 (most content) all contain redundant text that's worth trimming or removing altogether. I also have the following more specific comments about the document: - Section 2, eighth paragraph: encryption does not always prevent on-path devices from gaining knowledge of the header field. In particular, since QUIC Initial keys are public, it is possible for an on-path device to decrypt them for inspection. - Section 2, Network Operations and Research bullet: Perhaps state that observable headers permit *reliable* measurements, since methods based on implicit traffic signals exist and can be used for measurements. Also, regarding the statement that =E2=80=9Cconcealing the transport protocol header information ... leads to the deployment of alternative methods to collect or infer that data,=E2=80=9D is it possible = to cite relevant examples? In the following paragraph, it states that payload confidentiality and header integrity can provide the =E2=80=9Cmajority=E2=80=9D of privacy and security benefits. What is this m= ajority? I think being specific with concrete examples is important here. - Section 2: Network Troubleshooting and Diagnostics bullet: Should the document recent work on QUIC trace collections [4]? This tool was developed as a way to help Google debug (encrypted) QUIC connections in production, and seems relevant to this specific bullet. - Section 3.1.2: Is the itemized list supposed to capture metrics that can be derived from header information without encryption? If so, stating this explicitly would be useful. - Section 3.1.2, Variation bullet: This paragraph does not indicate why measuring delay variation is important for operators. Is it not true that only endpoints and applications are concerned with this metric? If not, perhaps describing why operators benefit from this information is useful. - Section 3.3, fourth paragraph: Is traffic injection possible with encrypted flows like TLS and QUIC? - Section 3.3, fifth paragraph: Might it be worth discussing the QUIC over satellite results from the IETF 103 MAPRG meeting [5]? Since encryption prevents traffic splitting, performance-enhancing proxies aimed at helping connections with such link diversity seem inapplicable. Nits: There are various spelling and grammatical errors in the document, though I=E2=80=99m sure they will be fixed in the final version. [1] https://link.springer.com/chapter/10.1007/978-3-319-76481-8_6 [2] https://tools.ietf.org/html/rfc8446#appendix-D.4 [3] https://static.googleusercontent.com/media/research.google.com/en//pubs= /archive/46403.pdf [4] https://github.com/google/quic-trace [5] https://datatracker.ietf.org/doc/slides-103-maprg-quic-and-satcom-nicol= as-kuhn/ From nobody Thu Dec 27 09:26:08 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B57A130E6D; Thu, 27 Dec 2018 09:25:52 -0800 (PST) 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=consulintel.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 5RwlwJzBqP5A; Thu, 27 Dec 2018 09:25:50 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679E8130DF3; Thu, 27 Dec 2018 09:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1545931546; x=1546536346; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=vCqnTrb61ZofF8b9ykCmX 6GiiURd8Jz64V7kl0oTXNQ=; b=WE2Z1xgc1L6wSbYjD5AKQqSYmvhuAy4lM/T1e JuEXGK1NrDk83TaR9IGyXTU3i12zGlq8ytFeuEV+AjQel18Um/S+loCeCDk46Gcr BfN7+Jih+Ci9DkOYO8lS+CJPiQroT9yMzLn3KwbKDAA2IL3RJ6lGYZkCwzztPKzs drqFmA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 27 Dec 2018 18:25:46 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 27 Dec 2018 18:25:46 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006087948.msg; Thu, 27 Dec 2018 18:25:44 +0100 X-MDRemoteIP: 2001:470:1f09:495:9d7f:6443:49a1:e932 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 27 Dec 2018 18:25:44 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1899b4cfc8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 27 Dec 2018 18:25:42 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations , Warren Kumari , Ron Bonica , Fred Baker CC: Dan Romascanu , , Christian Huitema , , Daniele Ceccarelli , "rtg-dir@ietf.org" , Martin Stiemerling , Message-ID: <1F8182C0-244B-4EF8-B5FD-BFA83914F2F9@consulintel.es> Thread-Topic: New Version Notification for draft-ietf-v6ops-transition-ipv4aas-12.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] New Version Notification for draft-ietf-v6ops-transition-ipv4aas-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 17:25:53 -0000 Hi all, Considering the review comments from ops, sec, rtg and tsv, we just complet= ed a new version: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: jueves, 27 de diciembre de 2018, 18:20 Para: Masanobu Kawashima , "Hans M.-H. Liu" , Jordi Palet Martinez ,= Jordi Palet , Hans Liu Asunto: New Version Notification for draft-ietf-v6ops-transition-ipv4aas-12= .txt =20 A new version of I-D, draft-ietf-v6ops-transition-ipv4aas-12.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-ietf-v6ops-transition-ipv4aas Revision: 12 Title: Requirements for IPv6 Customer Edge Routers to Support IPv4 Con= nectivity as-a-Service Document date: 2018-12-27 Group: v6ops Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-ietf-v6ops-t= ransition-ipv4aas-12.txt Status: https://datatracker.ietf.org/doc/draft-ietf-v6ops-trans= ition-ipv4aas/ Htmlized: https://tools.ietf.org/html/draft-ietf-v6ops-transition= -ipv4aas-12 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-= transition-ipv4aas Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-tr= ansition-ipv4aas-12 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or by vendors who sell through the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). Thi= s is necessary because there aren't sufficient IPv4 addresses availabl= e for every possible customer/device. However, devices or application= s in the customer LANs (Local Area Networks) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Dec 27 10:52:51 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7675C130E7B; Thu, 27 Dec 2018 10:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 s6szalskcFkI; Thu, 27 Dec 2018 10:52:40 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 8D8B0126F72; Thu, 27 Dec 2018 10:52:40 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBRIhhKi125446; Thu, 27 Dec 2018 18:52:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=Zr1vhy760I5wyT0XC6s7vHQNsiJB+vKyaCkWwY8TmK0=; b=4P1suOIzoz4cQcK9PATI0T6VVGDoJvyXH7cbAenVkiQYvK18gSY5Ayn1y6LN8VHCaztK DYlGlq8EEgR3U30VdJxR9x9VJf7Wr4UDojwdRoYdnLA1mNnSlEWHe6N58110QIABrY8D E9Wcpn4Fopeg1xgmGoYM+pxcxRfaCzqtziClbEn+fdNIavkkQnE6D9NfC9jpTYUEoDtg dBx4vWqImV6UemUs/U/gUw+uCxGerU2xpyguNSzU5OFzprueTDEZWGfn9Yel+0nRvd/6 huulEz6TfHxQc+jICOgJrTdQ5gJpcy+rJk0kaN+gVwCa50Ab9J1Ykg2DPwOTFKX1tFh+ og== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2phcptxc9t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Dec 2018 18:52:38 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wBRIqW43029876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Dec 2018 18:52:32 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wBRIqVbp029392; Thu, 27 Dec 2018 18:52:32 GMT Received: from anon-dhcp-121.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Dec 2018 10:52:31 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Chuck Lever In-Reply-To: Date: Thu, 27 Dec 2018 13:52:29 -0500 Cc: Spencer Dawkins at IETF , The IESG , secdir@ietf.org, draft-ietf-nfsv4-mv0-trunking-update@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christopher Wood X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9119 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812270165 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-nfsv4-mv0-trunking-update-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 18:52:43 -0000 > On Dec 20, 2018, at 11:14 AM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Authors, >=20 > On Tue, Dec 11, 2018 at 8:16 AM Christopher Wood = wrote: > Hello, >=20 > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the = IESG.=20 > These comments were written primarily for the benefit of the = security=20 > area directors. Document editors and WG chairs should treat these=20 > comments just like any other last call comments. >=20 > The summary of my review is: Ready with nits. >=20 > I believe these are the only Last Call comments I've seen on your = draft, and the Last Call period has ended.=20 >=20 > Could you respond to Christopher, and (if necessary) submit a revised = draft? >=20 > Thanks! >=20 > Spencer (D) > =20 > This document is in great shape and very well written. Most of my=20 > comments are editorial in nature aimed at helping improve readability = of=20 > the document. Please let me know if you=E2=80=99ve further questions,=20= > comments, or concerns. Hello Chris- Thanks for your review, and my apologies for the delayed response. > - Section 3, fourth bullet: Regarding =E2=80=9C[NFSv4.1] distinguishes = two=20 > (see [RFC5661]),=E2=80=9D would it be possible to provide the two = types of=20 > trunking relationships inline? Although this document is meant to=20 > supplement existing work, I do think it would help improve readability=20= > and minimize cross-referencing. After discussion, Dave and I removed the text that mentions NFSv4.1- specific features in this paragraph. They are an unnecessary digression. > - Section 5.1, fifth bullet: Rather than specify that addresses = =E2=80=9CMUST=20 > provide a way of connecting to a single server,=E2=80=9D could we = specify=20 > desired client behavior if this does not happen? I do not know how = often=20 > such misconfigurations occur, though it seems prudent to provide=20 > guidance in case it does. Dave and I agree that specifying client behavior here is a better approach. Dave provided new text. > - Section 5.2, sixth bullet: It might be worth pointing to the amended=20= > Security Considerations section, which contains relevant text = regarding=20 > DNSSEC validation for host name entries. I left a note here while=20 > reading only to discover it was addressed later on. We assume you meant Section 5.1, sixth bullet. A reference to Section 7 "Security Considerations" was added at the end of this paragraph. > - Section 5.2.3: Are clients allowed to race connection attempts = across=20 > all types available? The text implies that this must be done=20 > sequentially, which seems unnecessarily prohibitive. We introduced a couple of paragraphs of implementation guidance that compares sequential and parallel connection approaches. > - Section 5.2.5, third paragraph, first sentence: Perhaps a simpler = way=20 > to write this is something akin to =E2=80=9Cfs_locations cannot point = to=20 > alternate locations until data propagation occurs=E2=80=9D? We updated the text to clarify the ordering requirements. Because you feel the document is "ready with nits" I've taken the liberty of submitting draft-ietf-nfsv4-mv0-trunking-update-03 with these changes. rfcdiff will show the exact text that has changed. Let us know if any further changes are necessary. -- Chuck Lever From nobody Thu Dec 27 11:49:04 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CFE130E6A for ; Thu, 27 Dec 2018 11:49:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154594014221.12005.6790045150483260451.idtracker@ietfa.amsl.com> Date: Thu, 27 Dec 2018 11:49:02 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 19:49:02 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-01-10 Reviewer LC end Draft Phillip Hallam-Baker 2018-12-18 draft-ietf-rtgwg-spf-uloop-pb-statement-09 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-13 Steve Hanna 2018-12-18 draft-ietf-extra-sieve-fcc-08 Scott Kelly 2018-12-21 draft-ietf-sipcore-sip-push-21 Last calls: Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-11 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Tero Kivinen 2018-12-28 draft-ietf-jmap-core-12 Chris Lonvick 2019-01-16 draft-ietf-dime-doic-rate-control-10 Aanchal Malhotra 2019-01-09 draft-ietf-curdle-rc4-die-die-die-14 David Mandelberg 2019-01-08 draft-ietf-curdle-gss-keyex-sha2-07 Catherine Meadows 2019-01-04 draft-ietf-curdle-ssh-ed25519-ed448-07 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-08 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-10 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-02 Next in the reviewer rotation: Daniel Migault Matthew Miller Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman From nobody Fri Dec 28 07:19:52 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2F12F1AC; Fri, 28 Dec 2018 07:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mHENnIg4Hchk; Fri, 28 Dec 2018 07:19:46 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7499212E043; Fri, 28 Dec 2018 07:19:46 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D20A61B0012D; Fri, 28 Dec 2018 15:19:37 +0000 (GMT) Message-ID: <5C263F08.5010501@erg.abdn.ac.uk> Date: Fri, 28 Dec 2018 15:19:36 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christopher Wood CC: secdir@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-transport-encrypt.all@ietf.org, The IESG References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-tsvwg-transport-encrypt-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 15:19:50 -0000 Thanks Christopher for taking the time to do this recview. The editors will discuss and propose updates for the document, gorry On 27/12/2018, 01:02, Christopher Wood wrote: > Reviewer: Christopher Wood > Review result: Has issues > > Review of draft-ietf-tsvwg-transport-encrypt-03 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of my review is: Has issues > > This document lays out a comprehensive assessment of the impact of > transport (header) encryption on network users and operators. > Motivation for and dependencies on cleartext transport information is > clear. Yet, while this information is all useful, I observe a couple > issues with the document in its current state that might be worth > addressing. For brevity, I’ve enumerated them below. > > 1. While the document states that discouraging encryption is not a > goal, several sections seem to encourage or otherwise promote various > workarounds for transport encryption that seem in conflict with the > goal of encryption. For example, in Section 3.1.3, encouraged use of > IPv6 Network Flow Labels as a way of marking transport flows seems in > conflict with QUIC’s use of rotating connection identifiers (as a > means of helping unlinkability). Security and privacy motivated QUIC’s > aggressive use of encryption, and it seems that this privacy > perspective is not given enough attention. Are any transport protocol > implementations setting this information at the network layer? As > another example, consider Section 6.1, wherein the document discusses > privacy implications of sharing data. It states that protocols which > “expose the state information used by the transport protocol in their > header information ... provide an incentive for the sending endpoint > to provide correct information.” I’m not sure this is accurate given > the outcome of the QUIC Privacy Design Team and follow up work from > the spin bit folks. Recall that one aspect studied by the Design Team > was whether or not knowledge of RTT information was sufficient to > geolocate a client. The analysis from Brian and Mirja [1] shows that > this is a difficult, though possibly feasible, task, which seems > contrary to the point that endpoints would have incentives to make it > available. Moreover, several entities showed interest in greasing the > spin bit to prevent ossification and, as a result, promote endpoint > privacy. Regardless of the motives, it seems that clients do not have > incentives to send accurate signaling information in all cases. > 2. Parts of the document seem seemingly suggest that changes in > network operator tooling is prohibitively costly and could possibly be > considered a blocking factor when deciding which transport headers (if > any) to encrypt. In particular, the Conclusion states that if the > “currently deployed tools and methods are no longer relevant, then it > may no longer be possible to correctly measure performance.” Perhaps > the document should also state that an alternative outcome is that > mechanisms, policies, and tooling change to adapt to transport > encryption. While the needs of network operators may be real, they do > not seem to trump security and privacy concerns of endpoints. > Relatedly, is it worth encouraging research and development into > techniques that allow endpoints to voluntarily share this information? > As an extreme example, it could be possible to apply differential > privacy techniques to diagnostic traceroute packet traces as a way of > helping operators debug network issues. (The proposed IRTF PEARG > indicated some interest in this direction.) > 3. A seemingly large missed opportunity in this document is the > discussion of TLS 1.3 deployment obstacles [2] and their impact on > QUIC’s design decisions [3, Section 3.3]. There are many places where > discussion of the TLS ossification problems would be appropriate, > e.g., in Section 2 fourth paragraph describing shortcomings of > integrity-only protections, Section 2 seventh paragraph describing > greasing, and Section > 4, first bullet. Increased encryption should help prevent invariant > violation, which caused great pain when deploying TLS 1.3. Perhaps a > clear statement of protocol invariants would have mitigated the > deployment problems, though it happened nevertheless. That said, as > stated in the document, encryption as a mitigation may not prevent > ossification entirely, as network operators may come to rely on > traffic patterns or other heuristics. (Related to TLS 1.3, it might be > worth including TLS over TCP as a first class citizen in the document > given its increase in use.) > 4. The document focuses on transport header encryption and its impact > on network operators. Perhaps it might be worth generalizing this to > focus the impact of exposing explicit signals to the network, with > encryption as one way of hiding such explicit signals. Implicit > signals include those one can glean from connection metadata, e.g., > traffic patterns, size, and timing information. > 5. There’s a lot of redundant content spread across the document. A > significant amount of information could be removed without loss of > material, clarity, or continuity, and doing so would likely benefit > the reader. Specifically, Sections 3.2.2, 3.2.3, 3.3, parts of 3.2.4 > (first couple paragraphs), 5 (first two paragraphs), 6.3 (second > paragraph), and 6.4 (most content) all contain redundant text that's > worth trimming or removing altogether. > > I also have the following more specific comments about the document: > > - Section 2, eighth paragraph: encryption does not always prevent > on-path devices from gaining knowledge of the header field. In > particular, since QUIC Initial keys are public, it is possible for an > on-path device to decrypt them for inspection. > - Section 2, Network Operations and Research bullet: Perhaps state > that observable headers permit *reliable* measurements, since methods > based on implicit traffic signals exist and can be used for > measurements. Also, regarding the statement that “concealing the > transport protocol header information ... leads to the deployment of > alternative methods to collect or infer that data,” is it possible to > cite relevant examples? In the following paragraph, it states that > payload confidentiality and header integrity can provide the > “majority” of privacy and security benefits. What is this majority? I > think being specific with concrete examples is important here. > - Section 2: Network Troubleshooting and Diagnostics bullet: Should > the document recent work on QUIC trace collections [4]? This tool was > developed as a way to help Google debug (encrypted) QUIC connections > in production, and seems relevant to this specific bullet. > - Section 3.1.2: Is the itemized list supposed to capture metrics that > can be derived from header information without encryption? If so, > stating this explicitly would be useful. > - Section 3.1.2, Variation bullet: This paragraph does not indicate > why measuring delay variation is important for operators. Is it not > true that only endpoints and applications are concerned with this > metric? If not, perhaps describing why operators benefit from this > information is useful. > - Section 3.3, fourth paragraph: Is traffic injection possible with > encrypted flows like TLS and QUIC? > - Section 3.3, fifth paragraph: Might it be worth discussing the QUIC > over satellite results from the IETF 103 MAPRG meeting [5]? Since > encryption prevents traffic splitting, performance-enhancing proxies > aimed at helping connections with such link diversity seem > inapplicable. > > Nits: > > There are various spelling and grammatical errors in the document, > though I’m sure they will be fixed in the final version. > > [1] https://link.springer.com/chapter/10.1007/978-3-319-76481-8_6 > [2] https://tools.ietf.org/html/rfc8446#appendix-D.4 > [3] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46403.pdf > [4] https://github.com/google/quic-trace > [5] https://datatracker.ietf.org/doc/slides-103-maprg-quic-and-satcom-nicolas-kuhn/ From nobody Fri Dec 28 09:35:50 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFD313100F; Fri, 28 Dec 2018 09:35:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Catherine Meadows To: Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org, curdle@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154601853411.21528.4173984200093785499@ietfa.amsl.com> Date: Fri, 28 Dec 2018 09:35:34 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 17:35:35 -0000 Reviewer: Catherine Meadows Review result: Has Nits This draft specifies the use of the digital signature algorithms Ed25519 and Ed448 in the SSH protocol. Most of this, except for syntactic features such as formats and names, can be found in other RFC’s, and the appropriate references are given. The Security Considerations are also given by reference to RFC4241 (security considerations for SSH) and RFC8032 and RFC7479 (for Ed25519 and Ed448). These security considerations sections are very thorough and I don’t see any need for any additions. A nit: The paragraph This document describes the method implemented by OpenSSH and others, and formalizes its use of the name "ssh-ed25519". Additionally, it also describes the use of Ed448 and formalizes its use of the name "ssh-ed448". Would be clearer as This document describes the Ed25519 method implemented by OpenSSH and others, and formalizes its use of the name "ssh-ed25519". Additionally, it also describes the use of Ed448 and formalizes its use of the name "ssh-ed448”. From nobody Mon Dec 31 06:37:24 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3447F1200D7 for ; Mon, 31 Dec 2018 06:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.366 X-Spam-Level: X-Spam-Status: No, score=-4.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=WPnaxKdu; dkim=pass (1024-bit key) header.d=ericsson.com header.b=FKtxTn/d 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 ngYgFayAr1ZF for ; Mon, 31 Dec 2018 06:37:13 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 7494512870E for ; Mon, 31 Dec 2018 06:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546267028; x=1548859028; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bImTzoD+s1kc7hZU97vre0UcipmAvJjdgi+l7b7NTA4=; b=WPnaxKduFRHq+w51sc3h+ZqSV1kPWbB//wot3O7gWfCOj2VdMKGLgCOczXJBfcG9 0EV+lYASK0WihDZY7t3nV5OSyioOmh6jgyjDSZ4w+gVR48AaLuJ044lI9GJ8/LI1 aHYkVOHWaeccBk173ghAJ8epEYT4EIieqpO0s2iVyhE=; X-AuditID: c1b4fb30-41b3a9e00000355c-9f-5c2a2994c8c7 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.AA.13660.4992A2C5; Mon, 31 Dec 2018 15:37:08 +0100 (CET) Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 31 Dec 2018 15:37:05 +0100 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 31 Dec 2018 15:37:05 +0100 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 31 Dec 2018 15:37:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bImTzoD+s1kc7hZU97vre0UcipmAvJjdgi+l7b7NTA4=; b=FKtxTn/dhkxTV/KdhoVBcyRDLmomDI8hov7snxLfba7A5nCrtkTOw0KFOs1Oym2vctOtXZmqR3UcKao3XGyQ0bDfBLC1rSIFbce/F/c1czeC8RVNKFTn0msXaV5voKaU17+78l1Zn1HkUaW+b1Fauf7Jh04mxeG0Kcbl6cHQ65s= Received: from BL2PR15MB0947.namprd15.prod.outlook.com (10.167.116.21) by BL2PR15MB0946.namprd15.prod.outlook.com (10.167.116.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.20; Mon, 31 Dec 2018 14:37:00 +0000 Received: from BL2PR15MB0947.namprd15.prod.outlook.com ([fe80::7504:fcc:895b:b5cf]) by BL2PR15MB0947.namprd15.prod.outlook.com ([fe80::7504:fcc:895b:b5cf%2]) with mapi id 15.20.1471.019; Mon, 31 Dec 2018 14:36:59 +0000 From: Daniel Migault To: Catherine Meadows , "secdir@ietf.org" CC: "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07 Thread-Index: AQHUntPLv+O6457FtEm30XmZ9+2xIqWY7ptw Date: Mon, 31 Dec 2018 14:36:58 +0000 Message-ID: References: <154601853411.21528.4173984200093785499@ietfa.amsl.com> In-Reply-To: <154601853411.21528.4173984200093785499@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [70.80.131.240] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL2PR15MB0946; 6:daNplUx8d/M7mXf01ztdjnrpN0y6eF479cc4pfXtSD2lKjai6l8z/Bu56u0xdtzsms1JrY3XiKJ+BTnG18ODzXWxTWrygjNltEgFPXy1tZNYzHAkHabwbF02Xpx4IomkKXYt1CH8iUv9NwfOq0cTmgOSOfMaf2ATmbxRRqsxqyousitnaTECpU3z7InE5VFSS9pNweKMWv80Lt31ru5J3Nv3gVaiQy5ZvoUr2ekiV6bDcMgq776+J97RMVPUxZMGqzTz8OkmJ8lRoeDqjlrd2hOsgfE7ea2upQ0U223p67mlk4OWKUrAYFE8zszQtrXvoSinMagQaZKp5ZRCPkDy5Tz3JzQ/centy8mUVPgEk5TQ5iZSru1bqMuLkK3B4mKQpMVeao287+1e9EZsbrPlEbRkJI4hdvqY/6UoB4/yj0tA7SBFnx+5D3ixZxpf9pCPZ2APboKIlNI43zWz3/wjsg==; 5:X0cWCqr+EcPAMn794LfxV/5C1T+vb1VZwsaPfaW/o/oaivfQOS+e8Zc2EQkzu6KyWLdsJPZXf2DkVguDJxhQJbYVuJa2zP9wpXG38NWhmjpkmdDHki1o9f6KnUIt1bskYSjw57+I1ky0oCyKj2M1OxGLuv24s7rkhLFJXNJXnLo=; 7:zIrprwQYKba4IC3IdrV3iuiQzYlbJ6Z8zirSqxQcmWHETraZ2vta9XkqJvy0ziNtl8h3Qo0QDjqGcpCiusJuM2DF/o93unDSs5AnebHrZyt39rQVD8uz2JnG3Bu/OJzox/6iTv+4ThAUAUzs07mf6w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e74fd2d2-08e4-4c01-a140-08d66f2d6c0c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL2PR15MB0946; x-ms-traffictypediagnostic: BL2PR15MB0946: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220055)(2401047)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231475)(944501520)(52105112)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BL2PR15MB0946; BCL:0; PCL:0; RULEID:; SRVR:BL2PR15MB0946; x-forefront-prvs: 0903DD1D85 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(39860400002)(136003)(376002)(51914003)(199004)(189003)(13464003)(25786009)(478600001)(106356001)(76176011)(105586002)(53546011)(26005)(74316002)(6506007)(186003)(71200400001)(5660300001)(71190400001)(66066001)(229853002)(4326008)(6246003)(53936002)(68736007)(97736004)(99286004)(305945005)(55016002)(2501003)(9686003)(102836004)(2906002)(54906003)(33656002)(14444005)(7696005)(7736002)(3846002)(6116002)(316002)(256004)(8936002)(44832011)(81156014)(86362001)(14454004)(11346002)(8676002)(6436002)(446003)(81166006)(110136005)(476003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR15MB0946; H:BL2PR15MB0947.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DkyH9TX2hyq6+h+tap8/SlNecmbZ87sZhXjs1ozfjBcLgqb/yV9hy4fv8lLWIWIxGRm6ODsuYIRIe7lBdDg5RTa6xUXv5c5SzDL/b75jF2SKVAJuUCVQsZDEVzqnUBAd8fhDgpaUu8oiOCbmkFVB3t11gVVSk4Wz63d1QoW3F5KBBYsRmEThrJIU+c7BqxOEW9ixN4P3AEAxvvC0Hj4ySYKKr8BEXk47y1TtQ5XoXTEsHbc6xvycSRv6qzscE/5ftPpkDXwJTMzqw2LqkK33VxoS0L6CPaubEMYv25QFVdlRYJ5uebDayoM27/OM+o2f spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e74fd2d2-08e4-4c01-a140-08d66f2d6c0c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2018 14:36:59.4720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR15MB0946 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85m8fl8HXeHjQhB36Y4G1UzAq1G0hZWFBZLW3qQUWdcs6y FAw1zLyVeCk1agqTTA3NtKktyGWgUloGIkFiOm9dwBSdpWUez6K+/S+/5+V54KVJWbnIg07S 6hhWq0mRiyVUTZSR9atU+KoDrfeVqrvV2arO+lpS1dq7RKhmHusp1UL9JypMFG4w/CDCn+U/ oiKJc5J98UxKUgbDBoRclCQON94j002OV/LeLJE56IZjEaJpwDthsFFbhCS0DPchqG4cIgSz gmDNsPTPrOibScEYCOj6NiPmDYXLSFg0j4mEpoIA6502JJgJBOuff21i9rQYK+G6+ZYdr13w Behsq9h6mMRPEPS/rqf4VZzxccjtUwvMCRhYHRfxscvm7CsLy0sK+4B1EfOEFKuhYNRC8lqG D0JD7xjBI/b4EPRMsHyMsBtYB1sIXpPYHT5Y9FsaMAaDaZgUtCvMT/0WCXw0rHwvseXe8LW7 RSRoLxjRF29dBXhUDMbSm3ZC4QcLVVW2gWPwoLzBBr1FYGkz2gpfKMxrtQ0kQ+mSQSxA70gw XfsiLkNBtf9tWLt5BIkV0NoTIMTeUFn8ya5262YnGKixUHWIakKuHMPFpiYolf4MmxTHcWla fy2ja0ebP6W3Yy2wC83P7jcjTCO5g/TpDl+1TKTJ4DJTzQhoUu4iPR2jUMuk8ZrMLIZNi2Ev pTCcGXnSlNxdui5zUstwgkbHJDNMOsP+bQna3iMH7VWezJ9ynA5WGApD9aExYabB4NiOjcnL h9nyufHbp7KiHV6MBG7nHn7MFYdktzDcNuv8kbMHvIYidAt73i/PTu8e/lkStpxeYty12t0e 0VXcvD5aMPd8MaWjK90t7mg/GOsUPt305HnPKO+rhGS+JG45evGl88aZYWVkU2QeNMkpLlET 5EuynOYPZPlgWSUDAAA= Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2018 14:37:14 -0000 VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiBDYXRoZXJpbmUuDQoNCllvdXJzLCANCkRhbmll bA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2F0aGVyaW5lIE1lYWRvd3Mg PGNhdGhlcmluZS5tZWFkb3dzQG5ybC5uYXZ5Lm1pbD4gDQpTZW50OiBGcmlkYXksIERlY2VtYmVy IDI4LCAyMDE4IDEyOjM2IFBNDQpUbzogc2VjZGlyQGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1j dXJkbGUtc3NoLWVkMjU1MTktZWQ0NDguYWxsQGlldGYub3JnOyBjdXJkbGVAaWV0Zi5vcmc7IGll dGZAaWV0Zi5vcmcNClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWll dGYtY3VyZGxlLXNzaC1lZDI1NTE5LWVkNDQ4LTA3DQoNClJldmlld2VyOiBDYXRoZXJpbmUgTWVh ZG93cw0KUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCg0KVGhpcyBkcmFmdCBzcGVjaWZpZXMgdGhl IHVzZSBvZiB0aGUgZGlnaXRhbCBzaWduYXR1cmUgYWxnb3JpdGhtcyBFZDI1NTE5IGFuZA0KRWQ0 NDggaW4gdGhlIFNTSCBwcm90b2NvbC4gIE1vc3Qgb2YgdGhpcywgIGV4Y2VwdCBmb3Igc3ludGFj dGljIGZlYXR1cmVzIHN1Y2ggYXMgZm9ybWF0cyBhbmQgbmFtZXMsIGNhbiBiZSBmb3VuZCBpbiBv dGhlciBSRkPigJlzLCBhbmQgdGhlIGFwcHJvcHJpYXRlIHJlZmVyZW5jZXMgYXJlIGdpdmVuLiAg VGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGFyZSBhbHNvIGdpdmVuIGJ5IHJlZmVyZW5jZSB0 byBSRkM0MjQxIChzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgU1NIKSBhbmQgUkZDODAzMiBh bmQgUkZDNzQ3OSAoZm9yDQpFZDI1NTE5IGFuZCBFZDQ0OCkuICBUaGVzZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBzZWN0aW9ucyBhcmUgdmVyeSB0aG9yb3VnaCBhbmQgSSBkb27igJl0IHNlZSBh bnkgbmVlZCBmb3IgYW55IGFkZGl0aW9ucy4NCg0KQSBuaXQ6DQpUaGUgcGFyYWdyYXBoDQoNClRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBtZXRob2QgaW1wbGVtZW50ZWQgYnkgT3BlblNTSCBh bmQgb3RoZXJzLCAgYW5kIGZvcm1hbGl6ZXMgaXRzIHVzZSBvZiB0aGUgbmFtZSAic3NoLWVkMjU1 MTkiLiBBZGRpdGlvbmFsbHksIGl0ICBhbHNvIGRlc2NyaWJlcyB0aGUgdXNlIG9mIEVkNDQ4IGFu ZCBmb3JtYWxpemVzIGl0cyB1c2Ugb2YgdGhlIG5hbWUgICJzc2gtZWQ0NDgiLg0KDQpXb3VsZCBi ZSBjbGVhcmVyIGFzDQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBFZDI1NTE5IG1ldGhv ZCBpbXBsZW1lbnRlZCBieSBPcGVuU1NIIGFuZCBvdGhlcnMsICBhbmQgZm9ybWFsaXplcyBpdHMg dXNlIG9mIHRoZSBuYW1lICJzc2gtZWQyNTUxOSIuIEFkZGl0aW9uYWxseSwgaXQgIGFsc28gZGVz Y3JpYmVzIHRoZSB1c2Ugb2YgRWQ0NDggYW5kIGZvcm1hbGl6ZXMgaXRzIHVzZSBvZiB0aGUgbmFt ZSAgInNzaC1lZDQ0OOKAnS4NCg0K From nobody Mon Dec 31 11:45:55 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98977130EF3 for ; Mon, 31 Dec 2018 11:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no 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 E_jlPGDJIDXL for ; Mon, 31 Dec 2018 11:45:40 -0800 (PST) Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (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 A5A31130E4B for ; Mon, 31 Dec 2018 11:45:40 -0800 (PST) Received: from smtp24.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A4A4924A71; Mon, 31 Dec 2018 14:45:39 -0500 (EST) Received: from app46.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8E64B21170; Mon, 31 Dec 2018 14:45:39 -0500 (EST) X-Sender-Id: scott@hyperthought.com Received: from app46.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 31 Dec 2018 14:45:39 -0500 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app46.wa-webapps.iad3a (Postfix) with ESMTP id 6C5804008C; Mon, 31 Dec 2018 14:45:39 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 31 Dec 2018 11:45:39 -0800 (PST) X-Auth-ID: scott@hyperthought.com Date: Mon, 31 Dec 2018 11:45:39 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-sipcore-sip-push.all@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1546285539.44113084@apps.rackspace.com> X-Mailer: webmail/15.4.8-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-sipcore-sip-push-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2018 19:45:45 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments.=0A=0AThe summary of the review is ready with issu= es.=0A=0AThe document describes how to enable a push notification service (= PNS) to wake a suspended SIP user agent.=0A=0ADue to the writing style, I f= ound the document very difficult to understand. Maybe the RFC editor can he= lp with this, but it might be better if someone from the working group help= ed out with word-smithing.=0A=0AFor security considerations, there are 3 en= tities involved in the communications defined by this document: the user ag= ent (UA), the PNS server, and the application server (in this case, a SIP p= roxy). The basic idea is that the UA registers with the PNS, obtaining a Pu= sh Resource ID (PRID). The UA provides the PRID to the SIP proxy, and then = the SIP proxy presents the PRID to the PNS along with a message for the UA,= and the PNS uses the PRID to route the message to the right UA.=0A=0AThe s= ecurity considerations section mostly punts. With respect to UA-PNS interac= tions, it says "The mechanisms for authorizing and authenticating the users= are PNS-specific, and are outside the scope of this document." It says not= hing about how the UA authenticates the PNS. =0A=0AFor application server (= SIP proxy) to PNS interactions, it mentions the fact that a PNS may require= s some sort of authz/authn for the SIP proxy, but it gives no requirements/= recommendations here. It later mentions a JWT mechanism for this purposes d= escribed in RFC8292, but again, no requirement, no recommendation.=0A=0AAls= o, it says=0A=0A Operators MUST ensure that the SIP signalling is properl= y secured,=0A e.g., using encryption, from malicious middlemen. TLS MUST= be used,=0A unless the operators know that the signalling is secured usi= ng some=0A other mechanism.=0A=0AI don't think there is a clear requireme= nt stated here. If an operator chooses a proprietary scheme with weak crypt= o and claims that is "properly secured", have they met this requirement? = =0A=0AFinally, I think RFC8030 has a good description of the security consi= derations for this use case, and should be referenced here.=0A From nobody Mon Dec 31 11:57:38 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25487130EF3 for ; Mon, 31 Dec 2018 11:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 NHIRWvoX6OQk for ; Mon, 31 Dec 2018 11:57:28 -0800 (PST) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 28914130F0A for ; Mon, 31 Dec 2018 11:57:27 -0800 (PST) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=GI9KKaFK c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=2ur7OfE09M0A:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=TPLd9O6Y13ttJ8cbTIcA:9 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:58108] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 94/32-44058-2A47A2C5; Mon, 31 Dec 2018 14:57:22 -0500 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 6EB4A1C6060; Mon, 31 Dec 2018 14:57:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201809; t=1546286241; bh=9cyBzV2T4S6n9S3Rx7FEp87+2rZxd9Rd4NqHnUuDOTQ=; h=To:From:Subject:Date:From; b=c0XgSBn669JTZ1xWgCdOgGzE4Zc2AfMomXOaxSbVcLHYhXUme7+Lenzqub4/J7pEX waLj6jv2B/vj8z4fYr5H/+OxswU5ICfTeFheRm+UXkV/f5rXiRpCw2zpI0vvqIpcAp MDXmKtXMRreXJhE7PHeT1TdioiSfv4Ew7T0ALR9TlTRO1IxShPUJxATkJeXfnylIm8 tWHUnM+YuzbQ10RaVGGWpAijopzAsHqNRAVNotBohpocAiBvyONBVB31erKjbskwJ/ /Rxc6awNAVJe5e8PxvLS+cl4apbYRlu+re3Tklw6h4gf6KmyjaV3nKmgqu63ufXA7w JRKZNTWB/EtJw== To: draft-ietf-curdle-gss-keyex-sha2.all@ietf.org, iesg@ietf.org, secdir@ietf.org From: David Mandelberg Message-ID: Date: Mon, 31 Dec 2018 14:57:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2018 19:57:30 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. I have a few questions below about the security of this document, but each area I have a question about seems to be mostly copied from an established RFC rather than new to this draft. Sections 4 and 5.2: Are you relying on MD5 for any security properties? Can anything bad happen if an attacker finds a collision? Section 5.1: When calculating H, are the boundaries between each concatenated thing clear? E.g., would V_C = "1.21" V_S = "0.1" and V_C = "1.2" V_S = "10.1" result in the same value for H? Section 5.1: I assume H or mic_token is used elsewhere to thwart an active MITM? From what I see here, everything hashed into H other than K is public, so an active MITM could generate different H values for different K values for the two sides. -- https://david.mandelberg.org/