From nobody Sat Aug 2 13:23:57 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029111B2986 for ; Sat, 2 Aug 2014 13:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 xwsd3oqll-03 for ; Sat, 2 Aug 2014 13:23:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335C71B2983 for ; Sat, 2 Aug 2014 13:23:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 199D320012; Sat, 2 Aug 2014 16:26:09 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 80867638D9; Sat, 2 Aug 2014 16:23:52 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 68CF5638D7; Sat, 2 Aug 2014 16:23:52 -0400 (EDT) From: Michael Richardson To: Simon Perreault In-Reply-To: <53D6559B.2090300@jive.com> References: <11190.1406240244@sandelman.ca> <3B647D53-0E22-43C3-892D-319C9109248C@nominum.com> <53D6559B.2090300@jive.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/sjjzLwVXBHGNK07HJu4oF_PEGhs Cc: sunset4@ietf.org Subject: Re: [sunset4] to summarize Lorzeno's "drive-by" attack on draft-ietf-sunset4-noipv4 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 20:23:56 -0000 --=-=-= Simon Perreault wrote: >> On Jul 25, 2014, at 9:05 PM, Dan Wing wrote: >>> Specifically, the network has to allow an arbitrary host to send an >>> IPv6 RA. Doesn't that open the network to a pile of attacks, >>> including an attacker-controlled IPv6 DNS server (RFC6106) and >>> attacker-controlled IPv6 default route? >> >> It does, but if the network provides DHCP service and the attacker >> either fails to answer faster, or is prevented from acting as a DHCP >> server, then happy eyeballs will take care of the broken IPv6 service. > Dan didn't say "broken", he said "attacker-controlled", possibly (my > guess) thinking of the infamous "SLAAC attack" [*]. Happy eyeballs is > useless here. > The new vulnerability introduced by No-IPv4 over RA is the "drive by" > nature of the attack: contrary to the SLAAC attack, the attacker > doesn't need to remain on the network. It can shut off the victim's > IPv4 access quickly then drive away. If the No-IPv4 is defined to mean: "reduce the frequency of your DISCOVER" it seems that the attacker has to retransmit regularly... It seems to me that if the machine has *no* network connectivity at all yet (no IPv6 either, which the IPv6 process listening to the No-IPV4 message would know), then the node should be skeptical about the NoIP4 flag anyway. My understanding of the goal is to reduce the amount of *broadcast* DHCPv4 traffic that cloggs up some networks' infrastructure, because nodes that don't get IPv4, ask more and more often as they can't find it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU91I1YCLcPvd0N1lAQK4AggAtxetuYbul/aSE/Xg31MSJQjJR44hsqFJ JbrdHy+cxQeN/qosoEt39TgvSRe7I+JfpZBdhIse3t+/B8Uw0pwqeh4rymKnfOgX UhqsfpVSJhUFivo3CDfNVz/fRpMFCIViDQKndcOMJuMshX6INji8Seyyo5QKxd8v JZFrczuWE6EEPNL2hS0D46mNhZvhaCfTKbsxqZs0JU9HxH+ZKE+Z66FnysNEukFQ W2EmuvGJs+b9SOM6ZLoa5PaY5Q1zRzRvtwGIQsZKOAoRMtenv5iLEsEHqKwjSIGr pQzrBuE3TwHtOg+77CmOaBf4kuQiGyPbMHrZ8ise+XA1IpdzhYEBtw== =7E1u -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 4 05:47:58 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C9E1B2ABA for ; Mon, 4 Aug 2014 05:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 k3222TiW-EIM for ; Mon, 4 Aug 2014 05:47:52 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99CF1B2AAF for ; Mon, 4 Aug 2014 05:47:52 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so4908612oag.14 for ; Mon, 04 Aug 2014 05:47:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5pW/ZN6NqGDS46Ve/+gGzvIAfrW/YB/HAcxDX4uDIWY=; b=gFDWvsX9UOdMElZfMcz74M93BjNb8FZlcfpOksEqPmU7GAPGWgL9ZkaDYIouPJT8qt 6v6NRen5ka+lmYhA2ZRl1Hb/Kn1y1vOU1KCqJZTsKcxdE+h2Bh3YKKhsrwRRkfoXUCZt 4yR/CkZS4cjBG2cDidi7p9wlnfMbHu0PXpR1+CguMBlZScPqVi/MCZqD9J0slg60mZUe i/ZtkHqSFEDCvyQLQqSsUtuGGiaRbq4TEJHNLBNgbR7HJjOhyDkPaPkYWmSFS5dNlNK3 9scf92dCPQ0gi1WYaHUB7auiEHbROcDtqHpzaPQwTg0B+yvCyjAlfJ4EpXSh7iMz59O4 HALg== X-Gm-Message-State: ALoCoQlb8vGKVsNuFK6ZiI0+9A7koFs5kIgmgVbCgDpBOcnOKees1yTgyENRe30zCv6KcfOwVTXc X-Received: by 10.182.125.8 with SMTP id mm8mr31416243obb.11.1407156469563; Mon, 04 Aug 2014 05:47:49 -0700 (PDT) Received: from [192.168.1.96] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id s6sm38900869obf.4.2014.08.04.05.47.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 05:47:48 -0700 (PDT) Message-ID: <53DF80F2.2060503@jive.com> Date: Mon, 04 Aug 2014 08:47:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Michael Richardson References: <11190.1406240244@sandelman.ca> <3B647D53-0E22-43C3-892D-319C9109248C@nominum.com> <53D6559B.2090300@jive.com> <19625.1407011032@sandelman.ca> In-Reply-To: <19625.1407011032@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/4puIXj7Y_MLt76uiKkSoVTyEcR0 Cc: sunset4@ietf.org Subject: Re: [sunset4] to summarize Lorzeno's "drive-by" attack on draft-ietf-sunset4-noipv4 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 12:47:57 -0000 Le 2014-08-02 16:23, Michael Richardson a écrit : > If the No-IPv4 is defined to mean: "reduce the frequency of your DISCOVER" > it seems that the attacker has to retransmit regularly... It seems to me > that if the machine has *no* network connectivity at all yet (no IPv6 > either, which the IPv6 process listening to the No-IPV4 message would know), > then the node should be skeptical about the NoIP4 flag anyway. Note that the equivalent for DHCPv6 has been published recently: http://tools.ietf.org/html/rfc7083#section-4 That RFC's security considerations section says: This document introduces one security consideration beyond those described in RFC 3315. A malicious DHCPv6 server might cause a client to set its SOL_MAX_RT and INF_MAX_RT parameters to an unreasonably high value with the SOL_MAX_RT and INF_MAX_RT options, which may cause an undue delay in a client completing its DHCPv6 protocol transaction in the case no other valid response is received. Assuming the client also receives a response from a valid DHCPv6 server, large values for SOL_MAX_RT and INF_MAX_RT will not have any effect. I suppose that a SOL_MAX_RT for DHCPv4 would have the exact same considerations. > My understanding of the goal is to reduce the amount of *broadcast* DHCPv4 > traffic that cloggs up some networks' infrastructure, because nodes that > don't get IPv4, ask more and more often as they can't find it. That's one of the goals. See here: http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00#section-3 Simon From nobody Wed Aug 13 04:38:28 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D155F1A8702 for ; Wed, 13 Aug 2014 04:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Ugl12TMFCiJE for ; Wed, 13 Aug 2014 04:38:24 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928111A8703 for ; Wed, 13 Aug 2014 04:38:23 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id c1so9841182igq.13 for ; Wed, 13 Aug 2014 04:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qHrXUXCwAdCGqDuy68P50kHHHatCepxRgCht4WUDeCo=; b=ult5+FOy6PA8zA2vrF+23lYO6jJe5EVJ5sgsQFg9MLr/G+MLjYz3TNLPaQLjo4YB5G jMXUj9GqZc5oFm3RGyKiu+7zRjN2Po9NL0USNsEDdZS0mdK1eJ0ANNz9sU30peeb3Zyc HYuhwJbLmzrBnqtx+PzzOubozrFACwOMmkrGh4JVx8GJ994Ut9vSRK+jpzcu8JlB2psu vX1ZmlIIc5WST9sEQ6zMzCdu3YfAdH4Nn7Pgj3idwm9TrTbABJnxucybiEWVATRHk8YV dL6IG8pL743BxDRMui7Iqq0KQIIS9tYiIx9G494+FJQk3saEHsLgBYlc+UcDKapjAzAg FBAA== X-Received: by 10.50.111.225 with SMTP id il1mr6868861igb.28.1407929902899; Wed, 13 Aug 2014 04:38:22 -0700 (PDT) Received: from [192.168.97.87] ([67.210.160.130]) by mx.google.com with ESMTPSA id lq10sm7807526igb.22.2014.08.13.04.38.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 04:38:22 -0700 (PDT) Message-ID: <53EB4E2E.9000506@gmail.com> Date: Wed, 13 Aug 2014 07:38:22 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lee Howard , sunset4@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/5ZnSYRSkws0Dk_yt5BhaADV-zd0 Subject: Re: [sunset4] review of draft-chen-sunset4-cgn-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 11:38:27 -0000 Lee, thank you for the time you put into this. I won't be able to deal with a lot of it personally because it requires my co-authors' knowledge. However, based on the IPR discussion at the meeting, I think we will split out deterministic CGN and let it go on its way as an individual draft. I can do that step and respond to as much of your review as I can. My co-authors can take the next step or advise me on the remaining issues. Tom Taylor On 24/07/2014 4:02 PM, Lee Howard wrote: > Doing my homework before the WG meeting this afternoon (and re-sending from > the correct email address). . . > > This document needs significant work and reorganization. > > 1. Introduction > You say: > provide transparent routing to end hosts > I think it should say: > provide connectivity to end hosts > > Is it worth adding a sentence that these methods are only useful for address > sharing methods, not NPT, and not encapsulation mechanisms? It may not be > necessary. > But, for instance, this sentence: > The CGN may not do Network Address Port Translation (NAPT), but only > Network Address Translation (NAT) [RFC3022 > ]. > > THat's not an rfc2119 "may not," it's a description of one scenario. I had > to read it four times to figure that out; maybe it would be clearer as: >> The CGN might do Network Address Port Translation >> (NAPT) without Network Address Translation (NAT) [RFC3022 >> ]. In >> this scenario, there is no concern about port assignment. When NAPT is >> involved, Š > Then you can enumerate the "does" and "does not" cases. > > independently of the particular flavour should be independent of the > particular flavour > Section 2.1 Port Consumption on NAT64 > > This editorializing is unnecessary: >> Thanks to its simplicity and efficiency, NAT64 will likely be >> deployed widely. > > Also, > That is, a NAT44 will be deployed in an > IPv4-only environment. > NAT44 + Native IPv6 is a perfectly reasonable and likely scenario, so this > is untrue. But this whole paragraph reads like a sales pitch for NAT64: cut > it out. > Second paragraph: > One of the authors did a test comparison of port consumption on NAT64 > and NAT44. > Can you just cite the study? Can you say, "A study of port consumption > [portstudy]. . ." Though again, this whole study is only true to a point in > time (though what version of the Alexa100 includes 43 sites with AAAA I > don't know). > > NAT64 "provides everyone with incentives to use IPv6," > What incentives? Does it buy ice cream for everyone who uses IPv6? Either > explain, or, since defending the use of NAT64 is out of place in this > document, remove. > > [as v6 transition progresses,] it will be possible to relax the > multiplexing ratio of IPv4 address sharing. > This is a good point. > > change of IPv4 address will cause > renumbering of IPv6 addresses. > I don't see how. But again, I don't think this is intended as a NAT > discussion document, I thought it was just evaluating port allocation > methods. Clean up that paragraph. > > It has been learned from subscribers' > behaviors that the average number of sessions consumed by one > user's device is around 200 to 300 ports. Several devices may > appear behind a CPE. Administrators may configure a range > with 1000 ports to each CPE in fixed networks. > Avoid the passive voice. Can you cite the 200-300 number? Is that true in > 2014, or for as long as this document is intended to be useful? Yes, > administators may configure 1000 ports. Or 1001. Or 999. Maybe what you > mean is: > 1000 ports per subscriber household will provide enough room for multiple > active users. Administrators should monitor usage to adjust this number if > users are being limited by this number, or if usage is so low that fewer > ports would be sufficient. > > non-contiguous port range for the > sake of attack defense. > I think you explain this later in the document, but a reference to what you > mean here would help. > A+P style [citation needed] > > 2.3.1 Use of the word "older" sounds perjorative. Do you mean to imply > that NAT64 is obsolete? Both in the title and text. > Stepping outside > the boundaries of NAT64 for the moment, DS-Lite [RFC6333 > ] refers to > the cautions in [RFC6269 ] but does > not specify any port allocation > method. > First, that's pretty informal language. Second, why point to DS-Lite > pointing to RFC6269; why not just point to RFC6269? > 2.3.2 Current Work on Stateless Transition Technologies > The proposals made in Section 3 > n-3> and Section 4 > n-4> do not apply > to the current work in progress because that work has gone in another > direction. That work includes: > Do we need to enumerate protocols that this work doesn't apply to? If so, > then I think this document is making normative references to those protocols > (since their port allocation methods could, potentially, change until they > are published), which will delay publication until lw4over6, MAP-T, MAP-E, > 4rd have all been published. Having said that, this may be a useful > comparison of possible methods, but I would try to limit it to that. > Sections 2.4.1 and 2.4.2 are excellent. > 2.4.3 s/alllocation/allocation > 3.1 US means U.S.? Americans have higher traffic profiles? > 3.2 Remove sentence "Here is how dynamic allocation of port-ranges would > work in greater detail. " > 3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12. Is > this section supposed to be a privacy considerations section? > Discoverability? I think in the era of Pervasive Surveillance, reference to > other IETF work is needed. Also, please refer to RFC6302. > I'm not sure, though, that the discussion of server port logging is > appropriate in a document about how to allocate ports in CGN. A mention of > it makes sense, but evaluating the capability of different web servers, with > a config guide, seems out of place. > These "traceability" issues apply equally to all port allocation methods, > right? Maybe a Privacy Considerations section at the end. > I didn't review section 4, because I've reviewed it before. And I ran out > of time. > 5. Security Considerations needs a rewrite‹it completely ignores Section 4. > That's all I have on this round. > Lee > > > > > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 >